Application Performance Monitors provide you with a lot of data, but some of that data may not be relevant. Specifically, in Umbraco there is a page at `\umbraco\ping.aspx` that is being called frequently to keep the site alive. This is very useful to prevent the site from "dying" (?), but the data for this request isn't that relevant and could skew your statistics. Using Application Insights ITelemetryProcessor, we can prevent ping request from being sent to Azure Application Insights.

Filtering Application Insights metrics using ITelemetryProcessor #

The Application Insight (AI) SDK contains an interface `ITelemetryProcessor` that will be called for all telemetry data before sending it off to the AI service. This gives developers the ability to intercept the telemetry and apply custom logic to it. Maybe extra data needs to be added, maybe you have to remove some confidential or sensitive data such as PII or PHI. In our case we want certain Telemetry to not be sent at all.

More specifically, whenever an HTTP request comes in requesting `/umbraco/ping.aspx`, the resulting Telemetry should be blocked. Let’s create our `ITelemetryProcessor` to meet that requirement.

using Microsoft . ApplicationInsights . Channel ; using Microsoft . ApplicationInsights . DataContracts ; using Microsoft . ApplicationInsights . Extensibility ; using System ; namespace YourApp . ApplicationInsights { public class PingFilter : ITelemetryProcessor { //next processor in the pipeline private readonly ITelemetryProcessor next ; public PingFilter ( ITelemetryProcessor next ) { //store next processor in the pipeline this . next = next ; } //our logic goes here public void Process ( ITelemetry telemetry ) { //check to see if telemetry is for a Request var request = telemetry as RequestTelemetry ; //ignore if RequestTelemetry is a ping request if ( request? . Url? . AbsolutePath . Equals ( " /umbraco/ping.aspx " , StringComparison . OrdinalIgnoreCase ) = = true ) { //stop pipeline return ; } //invoke next processor next . Process ( telemetry ) ; } } }

Let’s explain this small snippet:

The constructor receives the next `ITelemetryProcessor` that should be called after we are done with processing. That processor will follow the same guidelines and call the next processor as well. Process is the method we have to implement because we inherit from `ITelemetryProcessor`.

This is where we can add our own logic. First, we check whether the telemetry is of type `RequestTelemetry` because we want to ignore the ping request. If not a request, we pass it on to the next processor. Now that we know the Telemetry is about a request, we can check the `AbsolutePath` property and check whether the request is for `/umbraco/ping.aspx`. If it is a ping request, we can stop the pipeline by returning nothing and not invoking the next processor.

Our `PingFilter` is ready, but Application Insights isn’t aware of its existence yet. To tell AI to use the filter, we have to add a reference to the `ApplicationInsights.config`. This config file is automatically created when you install AI. Add a reference to the `PingFilter` at the beginning of the `TelemetryProcessors` node.

<? xml version = " 1.0 " encoding = " utf-8 " ?> < ApplicationInsights xmlns = " http : // schemas.microsoft.com /ApplicationInsights/2013/Settings " > ... < TelemetryProcessors > < Add Type = " YourApp.ApplicationInsights.PingFilter, YourApp " /> < Add Type = " Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector " /> ... </ TelemetryProcessors > </ ApplicationInsights >

Now that everything is wired up, you can put a breakpoint in the `PingFilter`and see it in action.



That’s all there is to it, cheers!