Application Insights can collect telemetry from your application at any stage in its development, from debugging to live production. By default, all these different streams will go into the same bucket and interfere with each other. For example, if you run heavy stress tests, they could give a false impression of the number of visitors you’ve had at your live site. To avoid this problem, you can create separate application resources in Application Insights to receive the data from each lifecycle stage.
The destination of the telemetry is determined by the instrumentation key (iKey), which is sent along with every telemetry message. In the Application Insights portal, similar events and metrics with the same iKey are aggregated to give you charts of average durations, event counts, the sum of users, and so on. The iKey appears in two places in your project. One is in ApplicationInsights.config: <InstrumentationKey>94843456-2345-3456-4567-324562759284InstrumentationKey>
If your application has web pages, the iKey also appears in a script in the head of every web page. Usually it’s only coded once in a master page such as Views\Shared\_Layout.cshtml.
To direct telemetry to different application resources, we can create several resources with different iKeys. Then we only have to change the iKeys in the application at each transition in its lifecycle – along with other configuration data such as connection strings, certificates, and subscriptions.
Microsoft Azure provides a convenient way to group related resources, so we’ll create groups Dev, Staging and Production.
Set up several App Insights resources for each app
1) When you add Application Insights to your project, set the Resource Group to DEV: 
2) Create two additional Application Insights resources for each application, and place them in resource groups named STAGING and PRODUCTION. 
3) Obtain the iKey for each resource for your application. To find it in the Application Insights portal, open Properties. 
Now you have three resources for each Application, one in each resource group. And you have the iKeys: to switch the telemetry stream to one resource or another, you only have to change the iKeys wherever they occur in the application code.
The benefit of grouping the apps like this is that you can manage all the alerts, billing, permissions and other Azure resources like websites, storage, SQL etc. for DEV as one group, all the STAGING as another, and so on.
Switching target resource reliably
Changing the iKey in several parts of the application is error-prone, so let’s arrange things so we only have to update the key in one place.
1) Add iKey as a property in Web.config:
2) Instead of using the iKey from ApplicationInsights.config, we’ll set it in the code. In global.asax.cs:
To avoid confusion, remove the
3) Configure the web pages to pick up same iKey configuration. This is the script usually found in View\Shared\_Layout.cshtml.
4) Don’t forget to update your Web.config with appropriate iKey configuration during the deployment process. You might devise a way of setting it appropriately as part of your build, but I’ll leave that to you.
Multi stamp support
While the above solution completely separates the telemetry from different environments, which is good for dev|test|production environments, it doesn’t work if you want to compare the telemetry between them. For example, you might be running the same app on multiple clusters and want to compare their performance; or you might build an on-prem app and want every telemetry item from each on-prem installation to be tagged with CustomerID.
The Application Insights SDK lets you do this by tagging all the telemetry sent from a particular environment with arbitrary tags. Then in Metrics Explorer or Diagnostic Search, you can choose to see the data either aggregated all-up, or segmented or filtered by tag value.
Here is how to do it:
1) Create a new “tag” setting in web.config. Again, you’ll change this value from one environment to another.
2) Create a telemetry initializer class.
As you can see I’m adding to a context property bag key “tags” with value from web.config.
3) Hook up our initializer:
This would add property “tags” to every telemetry sent by the AI components. In Debug mode, you can see it in the Visual Studio Output window:
Or in search results, for example, in Failed Request details by clicking on “…” you can see it in the list of attributes
In upcoming releases of Metrics Explorer and Search you will be able to segment and/or filter your data by “tags”.
Version to Version comparisons
When running multiple version at the same time, for example in A/B testing scenario, it’s good to be able to compare and slice and dice telemetry based on app version. To support this scenario, Application Insights SDK lets you to provide your version id as a standard telemetry attribute.
For example:
1) In AssemblyInfo.cs set the version information
2) Add to Context Initializer class ability to set the version
Now you can search or slice by Application version field:
With the support of segmentation in Metrics Explorer you can now compare two version like this:
Note: You can get source code for this demo app here. Please, remember to replace iKey in web.config with your app iKey.
Summary
As you’ve seen Application Insight provides rather flexible model. It allow you to segregate telemetry by instrumentation key. It enables you to further segment telemetry within a key by adding custom attributes as well as application version. In this article I’ve used those features to show how to implement multi-environment and multi-stamp support.
Support for multiple environments, stamps and app version is rather broad area. There are multiple ways you can implement that for your particular project. I’m very interested in the feedback on the scenarios you have for multi-environment support and how you manage your telemetry now. Also, if you have ideas on how Application Insight could help you do that better, please, do not hesitate to share them with us. It is up to all of us to make Application Insights better!