This week I’m on duty answering forums so I decided to start my own collection of links on different Application Insights resources: apmtips.com/ai-links.
Cool article on how to install Status Monitor on your web role. Don’t forget to install Microsoft.ApplicationInsights.Web NuGet package for your web project.
Now in order to track dependencies on worker roles you need to do the same and one additional step - set environment variables to tell worker role where those new components are:
1 2 3 4 5 6 7 8 9 10 11
More on how to set environment variables for your worker role is here.
Don’t forget to install NuGet package Microsoft.ApplicationInsights.RuntimeTelemetry on your worker role and instantiate TelemetryClient at least once on worker role startup.
Once you’ve started using Application Insights it is essential to install Status Monitor. Status Monitor will enable dependencies tracking as mentioned in one of the previous posts. We use Status Monitor to track dependencies for our own internal services. As Brian Harry wrote about Visual Studio Online services “smaller services are better” we have quite a few interconnected services. Knowing that service you depend on became slower or started failing at a glance is very important.
As we monitor our own services with Application Insights - for some of our services we have startup task that installs Status Monitor. Month ago a small bug in Status Monitor was one of the reasons of quite a serious outage.
Status Monitor in a nutshell is just an installer of Application Insights components and UI to see status of monitoring (as name suggests). By itself it doesn’t collect any application telemetry or running any background services. So you may ask - why I’m saying that Status Monitor caused the outage?
And the answer is simple. We are committed to dog food. So we try to run the latest bits of Application Insights SDK and every service restart we are trying to download the latest components. Unfortunately, Status Monitor 5.0 has an issue - when it uninstalls it leaves some registry settings in bad state. Specifically, it make Environment string empty for these three services:
1 2 3
So after uninstall IIS will try to start and will fail as it doesn’t expect Environment string to be empty. Here is how it surfaced when you run iisreset /start command:
And these messages you’ll see in Event Log:
1 2 3 4 5 6 7 8 9 10 11
1 2 3 4 5 6 7 8 9 10 11 12
1 2 3 4 5 6 7 8 9 10 11 12
Solution is simple - right after uninstall of Status Monitor 5.0 - install the new one or delete “Environment” string from registry keys mentioned above.
There will be some excited features coming in Status Monitor in future and I hope you will never run into issue upgrading it.
In my previous post on web requests tracking http module I mentioned that Application Insights http module has some smart logic to collect request name. This logic is needed to make meaningful aggregation on UI side. In the screenshot below you see that requests are grouped by request name. Aggregations like number of requests and average execution time for requests were calculated for some pages. And those aggregations completely unusable for requests to “__browserLink”:
Here is how request name calculation logic works today:
- ASP.NET MVC support. Request name is calculated as “VERB controller/action”.
- ASP.NET MVC Web API support. Following the logic above both requests “/api/movies/” and “/api/movies/5” will be resulted in “GET movies”. So to support Web API request name includes the list of all names of routing parameters in case if “action” parameter wasn’t found. In example above you’ll see requests “GET movies” and “GET movies[id]”.
- If routing table is empty or doesn’t have “controller” - HttpRequest.Path will be used as a request name. This property doesn’t include domain name and query string.
Application Insights web SDK will send request name “as is” with regards to letter case. Grouping on UI will be case sensitive so “GET Home/Index” will be counted separately from “GET home/INDEX” even though in many cases they will result in the same controller and action execution. The reason for that is that urls in general are case sensitive (http://www.w3.org/TR/WD-html40-970708/htmlweb.html) and you may want to see if all 404 happened when customer were requesting the page in certain case.
- There is no smart request name calculation for attributes-based routing today
- Custom implementation of routing is not supported out of the box. You’ll need to implement your own WebOperationNameTelemetryInitializer implementation to override standard behavior.
If you were using my instructions on proxying Application Insights data - please note that format of configuration file has changed and you should not use tag “InProcess” when specifying an endpoint. I updated that post and want to explain how ApplicationInsights.config instantiates objects. This applies to every object you can configure in this configuration file - be it TelemetryInitializer, ContextInitializer, TelemetryModule or Channel.
Main idea behind ApplicationInsights.config file is that this config file should not be required. In ideal world all aspects of monitoring should be coded into your application. That’s why we try to avoid any dependencies on file format or schema for SDK objects.
Every object you can configure in ApplicationInsights.config can define “Type”. It also may have any number of child xml nodes which will be used to initiate corresponding properties of constructed object. For instance the following configuration snippet will construct object of type “ApmTips.Tools.PropertiesContextInitializer, ApmTips.Tools” and assign value “Bar” to property “Foo”. Since this object is defined in ContextInitializers section Application Insights SDK will ensure that class implements “IContextInitializer” interface.
1 2 3 4 5
Corresponding class should look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
And when you run a program it will add additional property “Foo” with the value “Bar” to every telemetry data item:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
This will apply to TelemetryChannel node as well. You can override the Type attribute of this node to specify your own channel. “DeveloperMode” and “EndpointAddress” are just public properties of the InProcessTelemetryChannel class that is assumed when Type is not specified.
Application Insights is truly integrated into Visual Studio development experience. It is easy to add telemetry to your project and see how it works on very early stages of development. There should be no surprises in production.
To enable the best development experience in Visual Studio, Application Insights SDK has a special mode called “Developer Mode”. When in Developer Mode Application Insights SDK behavior changes comparing to production environment:
- you’ll see application insights data items in Debug Output window
- data items will be sent immediately without buffering (default buffering interval on production is 1 minute)
- “Track” method of SDK will throw exception if Instrumentation Key is not set (Application Insights SDK wouldn’t throw exceptions in production)
There are also nice integration in Visual Studio - popup window showing that data is flowing to Application Insights and with the direct link to application blade on the portal.
Developer Mode will be turned on automatically in Visual Studio. When you import Application Insights NuGet to your project the following targets file will be added:
This target will enable Developer Mode by creating the following setting in ApplicationInsights.config file:
1 2 3
However it will not modify the file you have in source control - it will copy modified file to output directory of the application. And because of configuration file search order SDK will be using this modified configuration file when running in Visual Studio.
You’ll typically deploy Release version of your application to production. So Developer Mode will not be turned on. However if for some reason you want to deploy Debug version - don’t forget to remove this file or just set DeveloperMode to false in ApplicationInsights.config yourself.
Update (11/17/2015): package RuntimeTelemetry was renamed to Microsoft.ApplicationInsights.DependencyCollector and some class names and namespaces were changed correspondingly.
Dependencies tracking in Application Insights is powerful feature that allows to see what SQL and Http calls your application makes. I’ve mentioned that you need to install Status Monitor or Azure WebSites extension to enable it for your web application. I don’t like magic and tools that configures something that I don’t quite understand. I think most of developers and especially devops thinks the same way. Hopefully after this post you can better understand how this feature works and will trust it more.
The main purpose of Status Monitor and Azure WebSites extension is to simplify Application Insights enablement for web applications. When you host your ASP.NET application in IIS or as Azure WebSite it has very predictable structure. So most of enablement steps can be automated. In this post I’ll show how to enable dependencies tracking feature for console application manually so you know what Status Monitor and Azure WebSites extensions automation makes under the hood. You can apply similar steps for any other application type - be it Windows Service, Worker Role or anything else.
Let’s assume you just created a simple console application called “TestDependency.exe” in Visual Studio. As it tests dependencies tracking - I make a simple http call in a Main method of this application:
1 2 3 4 5 6 7
Now you need to include and configure Application Insights for this application and then enable dependencies tracking feature.
Install Application Insights
Every big feature in Application Insights is implemented in a separate nuget so you can choose what kind of monitoring you want to enable for your application. Dependencies tracking feature implemented in RuntimeTelemetry nuget package. So let’s install it:
Once installed new telemetry module will appear in ApplicationInsights.config. This telemetry module is responsible for dependencies tracking. We call it remote dependencies module:
Lastly, as it is a console application, you need to set instrumentation key manually:
When you compile your application plenty of new files will appear in bin/Debug folder. You’ll need to carry these files alongside with your application’s binary when you’ll deploying it. Here are the list of files you’ll need for 0.12 version of Application Insights SDK.
Application Insights configuration:
Application Insights Core and dependencies:
1 2 3 4 5
Files responsible for dependencies tracking:
1 2 3 4
Small note here - you may notice that RuntimeTelemetry nuget has a dependency to another nuget that is hidden in nuget.org: “Microsoft.Diagnostics.Instrumentation.Extensions.Intercept”. The only reason why it is hidden is that there is no reason to install it by itself, it only has utility features used by other Application Insights nugets.
Enable dependencies tracking feature
Dependencies tracking feature is based on code instrumentation in runtime. Application Insights decorates every call to http or SQL with prefix and postfix callbacks. Timer starts in prefix callback and on postfix - all information regarding dependency call like url and duration being send to Application Insights service. The only way today to notify CLR (common language runtime) to allow code instrumentation is to set certain environment variables before you run your application.
To enable dependencies tracking feature you should set these environment variables:
1 2 3
These variables tells CLR to load certain COM object as a “profiler”. We call this object Runtime Instrumentation Agent as it’s main purpose is to enable code instrumentation in runtime, without application re-compilation. Settings above will only work on machine where Status Monitor installed as GUIDs points to COM objects that should be registered on computer.
If you are not a big fun of registering COM object (like me) - you can copy content of folder “%ProgramFiles%\Microsoft Application Insights\Runtime Instrumentation Agent” to any other folder, for instance output folder of your application:
Surely you should tell CLR where to look for COM objects by specifying path to corresponding dlls:
1 2 3 4 5
That’s it. Just start console window, set environment variables and run your application. In my case I see this dependency event being sent to Application Insights:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Looking at this JSON you see that we now send two versions - sdk version (0.12.0.17386) and agent version (0.12.0). Agent version here is a version of Runtime Instrumentation Agent.
Web applications and dependencies tracking
So what exactly Status Monitor and Azure WebSites extension are doing.
- Installs Runtime Instrumentation Agent binaries to %ProgramFiles%\Microsoft Application Insights\Runtime Instrumentation Agent
- Registers binaries as COM objects. COM registration ensures that CLR will pick dll of the correct bittness as IIS may run in either.
- Sets environment variables for IIS by setting registry keys HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W3SVC\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WAS\Environment
- Suggest to restart IIS to apply those environment variables
Azure WebSites extension:
- Unpack Runtime Instrumentation Agent binaries to extension folder
- Detects site bittness to set proper environment variables
- Set environment variables for IIS by modifying applicationhost.config
Note, in both cases environment variables are set globally for all applications. So Runtime Instrumentation Agent may work with different versions of Application Insight SDK even if they are loaded in a single process. Basically, the only purpose of it is to enable code injection by SDK. You can enable runtime instrumentation agent for any application and if this application is not using Application Insights - Runtime Instrumentation Agent will do nothing.
I’ve already mentioned that Application Insights using http modules to track requests data. Tracking requests is actually quite straightforward task and can be easily implemented in couple lines of code on begin of request:
1 2 3 4 5 6
and simple code on end of request:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: we actually send request start time as a timestamp. In the code example above I simplified code a little bit and send end time as a timestamp.
You can track requests from console application, worker role or OWIN middleware. It is easy and straightforward. However Application Insights Web nuget has more logic. Here is the list of ApplicationInsights.config settings controlling additional data collection (on the moment of this writing - version 0.12 of Application Insights SDK):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Here is a short overview of what else http module is doing under the hood and what kind of data is collected by these telemetry modules, context and telemetry initializers.
- Smart request name calculation (WebRequestTrackingTelemetryModule). Request name is used to group and correlate requests in UI. For instance, you can see average duration grouped by request name. Or search traces and exceptions for “similar” requests where similar means the same name. That’s why request name for MVC application is reported as “VERB Controller/Action” (for example “GET Home/Index”). It should not contain any unique identifiers, otherwise there will be too many groups in UI and it will be less usable. update: see new post for more information
- Track Operation ID for traces inside request(WebOperationNameTelemetryInitializer & WebOperationIdTelemetryInitializer). I’ve already mentioned default telemetry initializers that Web nuget installs. These telemetry initializers ensures that all traces, events and dependencies will be associated with request they called from.
- Exceptions collection (WebExceptionTrackingTelemetryModule). Application Insights http module attempts to collect exceptions happening in your application. I’m saying attempts as there are many cases when exceptions object will be cleared out by the moment http module’s code executes. This article shed some light on how to enhance exception collection logic for different technologies.
- Track users of your application (WebSessionTrackingTelemetryModule, WebUserTrackingTelemetryModule). Whenever Application Insights SDK get a request that doesn’t have application insights user tracking cookie (set by Application Insights JS snippet) it will set this cookie and start a new session. Application Insights SDK sets cookies carefully so cacheability of ASP.NET pages wouldn’t be broken. With user and session information you’ll see usage charts even if your application is a REST service called via AJAX by another web application.
- Get azure role name for cloud services (AzureRoleEnvironmentContextInitializer). When application initializes it attempts to get azure role name in case it is running on azure.
- Something else (WebRequestTrackingTelemetryModule, WebApplicationLifecycleModule et al). There are some logic, specific to http modules and IIS implementation that helps us ensure the best data collection. For instance, when routing happening we making sure that you will get one request data item even if multiple handlers were executed and http module received multiple notifications. We also collect some diagnostics information in case something goes wrong and send it to the portal so you can take an action.
I plan to cover some of these data collection aspects in more details going forward. Please leave a comment if you have questions or want more information on a particular aspect of data collection.
BTW, Application Insights will definitely support asp.net vNext so OWIN-based implementation of web requests tracking is on the way.
…and configuring Application Insights when you don’t have access to sources.
There is no right answer on whether Service Oriented Architecture is good or bad. Some people likes it. Some are using Azure WebSites to build applications with this paradigm in mind as Azure WebSites are cheap, easy to manage, fast to deploy and scale. With service oriented architecture for every particular web site it’s important to understand not only how this web site behaves, but also how your “dependencies” - services you are calling into - are doing.
Application Insights allows to monitor dependencies for your application. Today to track dependencies Application Insights using Profiling API to inject code into every http and sql call. You will need to use Status Monitor to enable it. However Status Monitor can’t be used for azure web site. That’s why we just released Azure WebSite extension.
This very first release of Application Insights Azure WebSite extension works in assumption that your application has Application Insights of version 0.12+ already configured. Once installed for your WebSite (go to extensions tab and click “Add”), it will enable collection of dependencies information for your Azure WebSite.
In future releases Application Insights Azure WebSite extension will enable Application Insights for any application - even if it doesn’t have Application Insights configured. I want to show you a small hack that you can use to enable Application Insights for an WebSite that you cannot recompile. This post will not have many technical details - just step-by-step instruction with the pictures.
Ok, imagine you have an application. For example it may be Orchard CMS blog from gallery:
- Create Azure WebSite from gallery. Use Orchard CMS as a template
- Configure Orchard. I’ve used Azure SQL server as Application Insights wouldn’t monitor SQL CE
- You can always connect to your web site using WebMatrix. Here magic starts. Download your web site locally
- Once downloaded I created new web site on my local IIS server
- This was a hack that I mentioned. Now as you have a web site on your local server you can use Status Monitor to add Application Insights to it
- Now when you’d attempt to upload changes - it will upload all changes Status Monitor did
- I haven’t installed extension for my Azure WebSite. So I see requests to Orchard CMS, but do not see dependencies yet
- Now you go to extensions blade and enable Application Insights extension
- Very next request to your azure web site will run a bit longer - Application Insights instrumenting your application. After this you most probably wouldn’t notice the noise created by monitoring dependencies. You can see how long your Azure WebSite spent in every dependency. You can see that Orchard has two dependency out of the box - http and sql
- You can also see what exact external calls were made for every particular request:
It is very easy to use Application Insights Azure WebSite extension. It is also easy to configure Application Insights from Visual Studio. You can also enable Application Insights to your web site even if you cannot recompile it - Status Monitor and a simple hack - registering it in local IIS - will help you.