Distinguish Applications by a user defined Environment
Right now, Application Insights seems to only distinguish between the Debug and Release version of an application. At my company. we have several "downstream" environments DEV/MAIN/QA/POST that an application might run in before it is deployed to production. In the QA and POST environment, the application will run the Release version of the code.
So, I would like to see a way where I can record the Environment an application is running in. Preferably it would be something in the web.config so the correct value can be set at deployment time.
The dashboard would let me either look at results for a single environment, or roll up the values across all environments.
Application Insights team considers this feature request addressed.
Please take a look at the blog post describing how to use AppInsights for environment support and A/B testing: http://blogs.msdn.com/b/visualstudioalm/archive/2015/01/07/application-insights-support-for-multiple-environments-stamps-and-app-versions.aspx
Please try it and let us know what you think.
Marking this item as Completed and returning your votes back to you.
Michael Paterson commented
@Victor, that does it for me.
Victor Mushkatin commented
I just published an article on this subject here http://blogs.msdn.com/b/visualstudioalm/archive/2015/01/07/application-insights-support-for-multiple-environments-stamps-and-app-versions.aspx.
Please, let me know if this addresses your ask and we should consider this item closed. Like with everything, there are multiple ways you can achieve the result. I'm curious what scenarios you have and how you're addressing those challenges now.
There is a way to set instrumentation key programmatically using recent SDKs. While it might not address this feature request completely it might unblock some users.
You can find more info in this blogpost written by one of AppInsights team member: http://www.apmtips.com/blog/2014/11/17/programmatically-set-instrumenttion-key/
Michael Paterson commented
How are you changing the component name?
we used a different component name and ignore the ApplicationInsights.config file during deployments meaning the files i copied to a webserver then never modified.
we keep a copy of each environments config file in source control for safe keeping. seems to work well but would like to see a better solution on this as well.
Noel Anderton commented
Not only do we need to be able to set up and view environments but we need to be able to promote code from Dev to QA for example, with out a lot of hacks to change the configuration.
Maybe we could use the same Guid across each environment but get a choice on where to add a server into an environment based on IP or server name.
Prasanna Narayanasamy commented
1. I'd like to use multiple components within the same subscription/account, one component per environment.
2. There should be a simple documented way to set Component Id and Component Name through Azure configuration
3. Better still, do away with one of them! We don't need to keep track of which component id matches with a component name - AI should do that for us. So should be specifying only one of them, preferably component id.
4. Provide a way to programmatically set the component id/name in global.asax. Currently I'm doing this by calling ServerAnalytics.Start("<component-id>"); within Application_Start but it is an undocumented feature.
Sudhindra Kovalam commented
I Second Kurt C's Idea.
We need control to specify application ID and the instrumentation Keys via code in C#. Makes our live much more simpler.
I believe it is so for Server analytics. It should be extended to diagnostics and performance too.
Kurt C commented
I would also like a way to distinguish per environment that is not creating yet another application.
I do not like web.config or applicationinsights.config though. It is not testable and not transparent. I would like the ability to configuire application insights in C# code somewhere during application_start, that way I can load my settings the way we store settings and at runtime decide what the correct Application Guid or other variables are to use.