Microsoft's Application Insights is a great service to monitor the performance of a website hosted on Azure. It allows you to monitor the average response times, see when errors occur and see the exceptions in full detail (including what the visitor did just before the error occurred, which is useful to track down the cause). All this information is available within the Azure portal and it has got extensive filtering and search options to drill down into the data.
It's very easy to setup Application Insights using Visual Studio 2015, as it's just a button in the IDE to it add to the ASP.NET web project. This will include all the necessary DLLs and configuration files.
But the trouble with it being so easy to setup is that it also starts tracking requests from your local development machine. And other test or staging servers you might deploy your code to before it goes live. Which means that you start seeing exceptions being logged in the Application Insights portal which might have happened while you were developing some new functionality, and aren't relevant if you just want to monitor the exceptions on your live site.
Although it's possible to filter results from specific servers or domain names out of the Application Insights data, it would be better if that data doesn't get logged at all.
When I first started looking at ways of turning off Application Insights for my dev environment, the only suggestions were to use conditional debug constraints and disable the telemetry capture inside it. I don't really like this approach because I'm not a fan of debug constraints in code, and I'd rather control it through a configuration file.
However, the same Stack Overflow question had another answer which suggested that if you leave the InstrumentationKey element in the ApplicationInsights.config file empty it will not send the application telemetry events across. The instrumentation key is the unique key that Application Insights uses to identify your application.
I tried this out and quickly confirmed it was no longer showing the events on the dashboard, so that suggestion was indeed working. But while that is fine for my development environment, I still need to get the instrumentation key back in the configuration file when deploying it to live.
When creating an ASP.NET application in Visual Studio it will have a number of build configurations. By default there is a Debug and Release configuration, but you can add your own. Most often these are used to create different application configurations for different environments. So you might use the Release configuration for your live website, create a Staging configuration for your test server and use Debug for your development environment.
If you use different build configurations, by default Visual Studio will create a web.config transformation file. These transformation files use XML Document Transform (XDT) methods to replace or remove sections from the original web.config when it's built in the corresponding build configuration. So for example, the web.Release.config file will be used when the current build configuration is Release.
So since this works for the web.config file I thought it would be worth exploring to see if the same method can be used for the ApplicationInsights.config file (which is also an XML configuration file).
Unfortunately you cannot just right-click on the config file in Visual Studio and add a new transform, which you can for the web.config file. But if you open the project file (.csproj) in a text editor it allows you to add those transform files manually:
<Content Include="ApplicationInsights.config" /> <None Include="ApplicationInsights.Debug.config"> <DependentUpon>ApplicationInsights.config</DependentUpon> </None> <None Include="ApplicationInsights.Release.config"> <DependentUpon>ApplicationInsights.config</DependentUpon> </None>
Then make sure the ApplicationInsights.Debug.config file and ApplicationInsights.Release.config file both exist in the same directory, and they will appear as related files in your Visual Studio solution.
The next step is to add the right transformations. As I mentioned before, I removed the instrumentation key value from the original configuration file. But now I want to add it back in for my release build. So I created the following ApplicationInsights.Release.config file:
<?xml version="1.0" encoding="utf-8"?> <ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <InstrumentationKey xdt:Transform="Replace">00000000-0000-0000-0000-000000000000</InstrumentationKey> </ApplicationInsights>
This puts the specified instrumentation key back into the transformed configuration file, and it will then be part of your website deployment (and therefore starts reporting your telemetry on the live server).
For the final piece in the puzzle we need to make sure that the transformation actually gets run at the right time.
The default MSBuild and MSDeploy processes that get run when building and deploying a web application will deal with the web.config transformations, but not with any custom transformations. So to make our transformation work we need to once again open our project file in a text editor and add the following lines:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" /> <Target Name="TransformConfigFiles" AfterTargets="CopyAllFilesToSingleFolderForMsdeploy"> <Message Text="Transforming config files" Importance="high" /> <TransformXml Source="ApplicationInsights.config" Transform="ApplicationInsights.$(Configuration).config" Destination="$(WebProjectOutputDir)\$(WPPAllFilesInSingleFolder)\ApplicationInsights.config" /> </Target>
These lines can go anywhere in the project file, but if you do a search for Target you will see a section near the end of the file where it would make most sense to put it.
What the above bit does is run the TransformXml task after all the files of your project have been copied to a temporary folder, ready for deployment. This will then transform the Application Insights configuration file using the current build configuration's transform file. And after it's done the next steps in the deployment process will send the files to your deployment location.
Since it relies on MSDeploy it will work when you publish your application from Visual Studio using MSDeploy/WebDeploy. And it will also work for continuous integration and deployment environments that use MSDeploy, like Visual Studio Team Services.
And so we end up with the end result we wanted; a develop environment that ignores any Application Insights telemetry logging, and a live environment where the Application Insights tracking is turned back on during the deployment.
Tracing Umbraco trace logs on Azure Web Apps
I noticed that a website hosted on Azure Web Apps was generating multiple Umbraco trace log files for the same day. I went to investigate what caused it, and also came up with a suggested change to resolve this.Read more
Updating Azure CDN files through continuous integration
My experience of setting up Azure CDN on this site and fine-tuning it to automate the deployment of static files during the build process on Visual Studio Team Services.Read more