Finding Telemetremo - steps to diagnose why your data is not showing in AppInsights

  • Article

The steps in this blog entry is pretty much how a significant part of my daily life is spent these days and most of it is actually not for customers' application, but for the ones we write ourselves. Hey, where's that telemetry item I just sent? No, I sent it really, let me show you a Fiddler trace... Hmm.. or did I?

Decision Tree

When you see no data you can use this handy decision tree to know what things to try:

 

Now I will try to explain some of the nodes of this tree.

Are you seeing no data at all or just specific data types missing?

This is the first thing we ask the customers - let's identify if you are seeing no data at all just some types.

The best place to check is using search on the portal. Search is showing what we call "raw data".  Please note that aggregated data can be missing because there is about 5 minutes delay before it arrives. However telemetry items can be found in search very shortly after they are sent in most cases:

What telemetry types should I expect (and not expect) to see?

Here's a brief overview:

What if I don't see ANY telemetry?

Can you reproduce the issue locally? That is, can you do F5 in Visual Studio or at least login to the machine where web app is running to do diagnostics? If you can, then we are good - we will most likely be able to diagnose and understand what's going wrong. 

Check telemetry items in VS debug output window

If you can run your application under debugger the first step to check what telemetry is being sent in VS debug output window:

Check Application Insights references and configuration

If you don't see any telemetry in VS debug ouput window, chances are you haven't properly referenced AI assemblies or web.config entries are missing or ApplicationInsights.config has incorrect entries. At the time of this writing latest stable Web SDK (version 1.2.3) and its dependencies would include the following assemblies:

  • Microsoft.ApplicationInsights
  • Microsoft.AI.Web
  • Microsoft.AI.WindowsServer
  • Microsoft.AI.ServerTelemetryChannel
  • Microsoft.AI.PerfCounterCollector
  • Microsoft.AI.DependencyCollector
  • Microsoft.AI.Agent.Intercept.

In web.config, there should be an entry for ApplicationInsightsWebTracking HTTP module. And finally ApplicationInsights.config should be present with instrumentation key specified, unless you are specifying instrumentation key programmatically. To enable client-side telemetry there should be Application Insights JavaScript SDK snippet in your master page, for example in Layout.cshtml for MVC applications

A few times I saw the problem with ApplicationInsights.config which contained some entries from the old SDK after it was updated. The easiest way to verify is to create a new web application and compare the configs line by line using a diff tool.

Check with Fiddler that telemetry is sent successfully

Fiddler is super useful for this kind of investigations. Look for requests sent to Application Insights data collection endpoint (dc.services.visualstudio.com). Client side telemetry will be sent from your browser process. Checking server side telemetry can be a bit more tricky. First you need to have your application run under IIS process (enabling it for IIS express is even more complex). Then you should either change IIS application pool to run under your name or add proxy instructions to web.config. Either approach should do the trick, but somehow I often found myself doing both.

Once you get Fiddler working you can verify what you are sending from both client and server and also check the response back from data collection endpoint.

 

Check ETW traces

 Here's an excellent blog post by Anastasia Baranchenkova on how to enable ETW tracing for Application Insights.

Check latency issues with Application Insights backend

When there's a prolonged outage we post it in this blog. Please check if there are any ongoing incidents.

Contact us!

If you're stuck, please let us know and we'll try to help. There are numerous ways you can reach us. And by the way, responding to forums is one of our weekly on-call engineer responsibilities, so in the priority list it is just below service incidents, which means if we are not getting back to you quickly, there's a likely a service incident :) Well, not always, but quite often.