A journey with Application Insights

Recently I have been trying to enable Application Insights (AI) on my simple SPARQL query UI on ASP.NET Core 2.1, with reference to quick-start guide on Microsoft Docs. After completing the configuation and trying out the website locally, I believe everyting worked fine. Though the SLA guarantees the delay of telemetries should be under 2 hours, actually I can see the requests in my development environment on Azure dashboard in less than 10 minutes.

Then I decided to move the instrumentation key into a separate application configuration file named appsettings._private.json, which would be excluded when submitting my files onto GitHub. What I was intending to move is the following part of appsettings._private.json:

Though exposing your instrumentation key is actually not rather dangerous, you may still take the risk of receiving spoofed telemetries from the public. Thus I added a secret appsettings file into my .gitignore list; this is how the whole ordeal begins.

I want a non-default appsettings.json path

At first, I even hadn’t noticed anything fishy; until I deployed the website on VM. After asking Gray Wing about which cats belong to ThunderClan, I waited for half an hour, only to see there are no more requests shown on AI dashboard. Then I noticed the local development instance emitting the following traces to the Output window:

Wow. So I removed the whole ApplicationInsights node from appsettings._private.json. Guess what?

Nothing changes. Then I put the node back into appsettings.json, just like what the installation wizard has done. Then I saw the output indicated AI works!

So that’s wierd. I used the following code to load my extra appsettings file:

Looking back at the situation, I have a bad feeling about this.

After digging in the source code of AI for a while, I found the following snippet is to blame

Apparently, AI loads configuration from nothing other than appsettings.json and appsettings.{Environment}.json.This class is used in the source code of ApplicationInsightsExtensions.AddApplicationInsightsTelemetry, and lead to the current situation.

Just as I’m about to submit a new issue about this situation, I was thinking “what about now?” The most important thing is, I need to figure out how to get this work, again. Then, just beside  the extension method that had brought me trouble, I found an extension method that brought me hope:

Thats it! I can use this method in my Startup.ConfigureServicesmethod.

The Configuration here is the configuration fed to the whole application, having loaded all the configuration files it is supposed to.

Voila! It works. I can deploy it to the VM now.

A Ubuntu problem

Then it just works. I can see my requests from the dashboard now. FYI, with the advent of GDPR, all the IP Address field of the requests are zeroed out by AI to conform the new rules, while the geographical information is kept. You may choose to record the IP in a custom field with telemetry initializer, at your own risk.

Aside from the requests, however, there is another trace

I don’t want to lose telemetry. So I followed the instruction, created a new folder, and used the following code to telling AI about it

About why this happens, I found aspnetcore#551 may answer your question. Basically, it’s about the inability of .NET Core BCL to chmod on Linux, to ensure the security of the storage directory…

Well, it also reminds me of the inability of .NET Core BCL to follow symlinks. Agh.

As a kind reminder: there is already a NuGet package that can follow symlinks on Windows. But no luck from Linux up till now.

Don’t mention Mono.Posix.NETStandard. It’s waaaaay to heavy.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.