Azure Application Insights without noise from health checks and swagger in ASP.NET Core 3.1

Azure Application Insights without noise from health checks and swagger in ASP.NET Core 3.1

Today when using the cloud it's so easy to set up some basic monitoring. I've been using Application Insights (AI) in Azure the last couple of years, and find it extremely useful considering the shockigly low amount of effort required to get it up and running.

Below I will guide you step by step. Normally I would recommend you to create the AI resource with some scripting tool, and not do it manually - however that's not the goal with this post - so we'll keep it simple.

How to get up and running from scratch

  1. Create the AI resource in the Azure portal. Just search for "Application Insights".
  2. Copy the instrumentation key from the newly created AI resource in the portal.
  3. Add the instrumentation key to your appsettings.json with the key ApplicationInsights: { InstrumentationKey: <InstrumentationKey> }.
  4. Add the Microsoft.ApplicationInsights.AspNetCore nuget.
  5. Call  services.AddApplicationInsightsTelemetry(Configuration); from your Startup.cs.
    At this point you have all the basics and it should work. Start your app and start sending telemetry to AI in Azure. This will include every request to your app, which is great - however we do not want telemetry for /hc and /swagger endpoints because this will blur our "real" endpoints that customers are using.
  6. Create a class that implements ITelemetryProcessor. I will call mine IgnoreRequestPathsTelemetryProcessor (you can see the code below). This will be your "filter" if you will.
  7. Add your new class to the container with services.AddApplicationInsightsTelemetryProcessor<IgnoreRequestPathsTelemetryProcessor>();.

That's it.

Now when you start your application, requests for any of the paths defined in your custom telemetry processor won't be sent to AI. This can be very useful for when looking at average request duration for your API in total, or the number of requests during a time.

From the perspective of "getting to know your API", I call these /hc and /swagger endpoints for noise. They add no real value. You want to learn about the experience your customers has, not how fast Swagger is. I've also decided to ignore static content since static content is served too fast to bother analyze.

Here's the code:

Personally I love Application Insights - because it's so easy to get up and running, and gives you such good metrics to start to know about your apps behaviour rather than guessing.