HomeBlogTexas Ranger

Previous arcticle: Install Application Insights

This is the End (-to-End)

Monitoring and analyzing modern web-applications purely from the server-perspective ist clearly not enough in times of single page apps. They have basically become rich clients with a convenient deployment-mechanism (the web). Important parts of the UI-logic are handled on the client. Depending on the service-architecture, the client is the only good starting point for identifiying an end user's or business-transaction. Just think of more generic service layers that do not mirror the UI logic exactly but provide fine grained or "query-like" service calls. Good examples of generic service-layers are for instance Facebook's GraphQL or OData. In proactive APM as well as in problem-diagnostics it is good practice to focus on business relevant user actions, e.g. viewing the product catalog, putting something in the basket, checking out etc. It will cost you money if they are slow. In order to focus, we need to know exactly what was part of the "checkout" action. Which ajax-requests, service-calls and datastore-calls belong to it? Which users triggered it?

Transaction Tagging

In a later blog post we will cover the various technologies used for monitoring and measuring performance metrics. One of the is transaction tagging.

Classic Monitoring looks like this:

"Classic Monitoring"

Probes are placed in variuos layers of the system: hardware, network, application etc. They gather telemetry data and send it to a central monitoring server which stores, analyzes and visualizes it. The data can be statistically correlated, e.g. by time frame or machine id. Statistical correlations are important to get an overview but they don't allow for focussing on single actions like the "checkout" of a particular user.

Transaction tagging puts a transaction tag/id on each single transaction, from the UI to the server to the database.

"Transaction Tagging"

The transaction id is sent to the monitoring server along with the other telemetry data. Through the correlation of the of the data by the transaction id, the server can anser questions like:

  • Which user action caused the problem?
  • Which user caused the problem?
  • What ajax-requests were triggered by the "checkout" user action?
  • What REST-services were triggered by this user action?
  • Why did a certain user action trigger 150 database calls, whereas others triggered only 10?

Transaction tagging in Application insights

In APM - Overview - what does it mean for DevOps? we mentioned the AI SDK and the telemetry API. The telemetry API is used to place transaction ids. The following snippet is taken from a JavaScript application:

    var guid = Guid.create();  // Guid-class implemented else-where ;-)
    window.appInsights.context.operation.id = guid;


    var guid = Guid.create();  // Guid-class implemented else-where ;-)
    window.appInsights.context.operation.id = guid;

In AI the transaction tag is passed as operation.id.

In the overview blog-post we also pointed out the application insights config snippet you have to add to each page:

  <script type="text/javascript">
    var appInsights = window.appInsights || function (config) {
      instrumentationKey: "<your AI instrumentation key - taken from the AI instance in the azure portal>",
      disableCorrelationHeaders: false
    window.appInsights = appInsights;

It is important to set disableCorrelationHeaders to false because only then AI will add the transaction id as an html header. And of course, set the instrumentationKey to the value you find in the AI instance in the azure portal.

Walk the Talk - Analyze end user pages views

To analyze the end users' page views, open the AI instance in azure and select Search in the top menu bar of the overview blade. This will take you to following blade:

"AI page views"

As you can see, we get the single page views here, no statistical aggregations. Throught the filter on the right-hand side, we have selected the page views. Remember, we instrumendted our JS code by


Later we will analyze so called custom events. Let us drill down to the page view statistic at 19:50:35:

"Page view 'statistics'"

In the lower part of the blade we can choose various information on the page view itself but since we want to focus on an end-to-end transaction, we will select

All available telemetry for this root operation

root operation means that we want to se the complete "tree" caused by our page view: ajax requests, REST-calls, database-calls etc. If we only chose for this operation we would get the direct dependencies only. By dependency Microsoft means "services or calls that the currently selected page view/event/action/call depends on". Let's see the dependencies for our page view:

"Dependencies of page view 'statistics'"

It seems strange: A single page view (see the red bordered operation ID) caused 152 dependencies? We see ajax and REST depencies but also a lot of database calls. We pick one of them and see:

"DB-call of page view 'statistics'"

This is quite useful: For the single page view, we can drill down to the plain SQL-text of single db-calls.

So what have we learned from that brief drill down?

  • We can analyze various user actions not only from a statistical correlation perspective
  • This will help us diagnose problems, for instance if only certain users or parameters cause problems
  • We can reveal the plain text DB statements

Note: The plain text for DB statements as well as the correlation between the operation id is only done if you have installed the Status Monitor or the AI App Extension, see: APM - Overview - what does it mean for DevOps?

Another note: Depending on the AI edition (Basic or Enterprise), AI will start to sample data if there is too much telemetry data sent to AI. See Sampling in Application Insights