After great feedback from the community, we have invested in a new feature: Telemetry Processor. You can now inspect, filter and modify telemetry generated by the Application Insights SDK before it is sent to the backend service. Telemetry Processor is included in the new version of the SDK.
Now that you can initialize, filter, and sample your data before sending it to the backend you can, for example, filter out telemetry about requests from robots, or successful dependency calls. This means you can reduce the volume of data collected which allows you to focus more on the telemetry of interest to you.
To create a filter, implement ITelemetryProcessor. This is another extensibility point like telemetry module, telemetry initializer and telemetry channel.
Create a Telemetry Processor
- Update your SDK to the latest version. Note: This version is in prerelease, actual API may change in the future.
- Create a filter by implementing ITelemetryProcessor. This is another extensibility point like telemetry module, telemetry initializer and telemetry channel.
Notice that Telemetry Processors construct a chain of processing. When you instantiate a telemetry processor, you pass a link to the next processor in the chain. When a telemetry data point is passed to the Process method, it does its work and then calls the next Telemetry Processor in the chain. - Create a new TelemetryConfiguration in your main source file, typically Global.asax.cs.
For implementation details please see the documentation page.
Filtering
Many customers have asked for a filtering feature, for example, filtering of sensitive information. Application Insights is proud to now offer this functionality. Here are some examples of useful filters.
Filter out synthetic requests
Metrics explorer gives you the option to filter out requests from search engines and web tests. You can reduce traffic and improve your quota of data points by not sending them from the SDK.
public void Process(ITelemetry item) { if (!string.IsNullOrEmpty(item.Context.Operation.SyntheticSource)) { return; } this.Next.Process(item); }
Note: SyntheticSource is set by TelemetryInitialzier.
Filter out requests where authentication failed
This filters out requests with a “401” response. 401 responses: authentication failed – bad name in many cases means “negotiation” response and you don’t want to track it as separate request item. You may have more complicated logic in place that distinguishes between negotiation response and actual failure.
public void Process(ITelemetry item) { var request = item as RequestTelemetry; if (request != null && request.ResponseCode.Equals("401", StringComparison.OrdinalIgnoreCase)) { // To filter out an item, just terminate the chain: return; } // Send everything else: this.Next.Process(item); }
Filter out “fast” remote dependency calls
This filters out a dependency call that is under 100 milliseconds. In many cases, fast queries are not interesting to diagnose.
public void Process(ITelemetry item) { var request = item as DependencyTelemetry; if (request != null && request.Duration.Milliseconds < 100) { return; } this.Next.Process(item); }
Now you can filter out whatever telemetry you desire. With Telemetry Processor you have more control regarding what data is collected.
Future plans
The Application Insights team is committed to providing quality tools for developers. Our APIs will likely change as we develop new features and as such, we would greatly appreciate any feedback or recommendation for new features.