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.
- First, we check whether the telemetry is of type
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!
Top comments (0)