Previous arcticle: Install Application Insights
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?
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:
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.
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:
var guid = Guid.create(); // Guid-class implemented else-where ;-) window.appInsights.context.operation.id = guid; window.appInsights.startTrackEvent("checkout");
var guid = Guid.create(); // Guid-class implemented else-where ;-) window.appInsights.context.operation.id = guid; window.appInsights.startPage("statistic");
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:
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.
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:
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:
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:
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:
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?
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