As telemetry became a part of engineering process I hear one question more and more often - how can I separate events reported during development from data collected from production deployment? How can I limit access to data and integrate telemetry into my continues integration infrastructure? How can I separate events from staging and production, from different versions of application, from different components inside the application?
Well, nobody knows the answer better then you. Application Telemetry SDK is flexible and gives you full controls over data and configure data collection the way you need it. There are couple ways to slice your data. In this article I’ll explain how to separate telemetry data by sending it to different components.
Every component in Application Insights is represented by a single Instrumentation Key. You can get it in “properties” section of your component:
Easiest way to configure instrumentation key is to set it in ApplicationInsights.config. Whenever Application Insights will need to send data for the first time it will attempt to read instrumentation key from this config file. You can use
TransformXml msbuild task to automate the release pipeline. Here is config snippet you need to modify:
However this approach is not working well with some deployments. You may already have distributed configuration management system in place. One example may be Azure Cloud Services where you may prefer to store instrumentation key in cscfg file. In this case you can leave InstrumentationKey section of ApplicationInsights.config file blank and set it programmatically:
1 2 3
The best place to do it for web application is Global.asax before any telemetry data items were tracked. Note, that if you’ll attempt to send telemetry data item before instrumentation key was set
TelemetryClient.Track[Foo] method will throw an exception.
In both cases - using config or setting key programmatically you’ll see data reported into the same component. This key will be used as default for all telemetry clients you’ll instantiate.
There are situations when one default key is not enough. Scenarios I can imagine are:
- reporting data from payment processing library separately from other telemetry
- split telemetry information by tenants of your application and grant them access to their data only
- library developer wants to collect telemetry from his library, not send it to application that uses this library
For all this scenarios you’ll need to configure your own custom telemetry client and set it’s instrumentation key:
1 2 3
Sometimes you might want even more fine grained control over data. You may want to decide where to send telemetry data item based on it’s properties. For instance, you can have a library that decides where to send telemetry item based on current thread identity. In this case you’ll create and populate telemetry item and then pass it to this library so it will set the correct Instrumentation Key on this item:
1 2 3 4
Both code examples will send trace message to your custom application even though configuration file defines another instrumentation key.
Application Insights SDK gives you a flexible way to configure data collection. You have full programmatic control over where data will be reported to and it is very easy to integrate Application Insights into any continues deployment process with the minimal coding.