-
Notifications
You must be signed in to change notification settings - Fork 5k
Description
Library name and version
Azure.Monitor.OpenTelemetry.AspNetCore V. 1.3.0
Query/Question
Hi Microsoft team,
We are experiencing a significant limitation when using the AzureMonitorOpenTelemetryExporter (and the related Azure.Monitor.OpenTelemetry.AspNetCore integration) in our .NET solution. Specifically, we are unable to override, disable, or customize the filtering logic that determines which telemetry data is sent to Application Insights.
Problem description:
The exporter automatically filters certain activities, traces, and dependencies, and the internal logic is not exposed or configurable.
This means that some data we explicitly want excluded or included cannot be controlled, even with custom OpenTelemetry filters or processors in our application code.
Attempts to filter (e.g. using options.Filter, custom processors, or span processors) only affect spans created before exporter logic.
However, the exporter’s own filtering still applies invisibly in the background.
For example, we cannot reliably prevent Hangfire or Azure Storage noise (background jobs, blob operations) from showing up in Application Insights if the exporter itself processes those spans.
Requested improvement:
A way to customize, override, or disable the exporter’s internal filtering logic.
Expose configuration or hooks that allow users to apply their own filtering/selection before data is sent to Application Insights.
This would enable us to tailor telemetry ingestion to our use-case and avoid unnecessary data/ingestion costs.
Why this matters:
In large distributed systems, it’s critical to have fine-grained control over what telemetry gets ingested to App Insights, especially when multiple dependencies (e.g. background processors, storage operations, service buses) are involved.
Not being able to control exporter filtering leads to unwanted “noise” and lost cost-optimizing opportunities.
References:
Azure.Monitor.OpenTelemetry.AspNetCore package
OpenTelemetry instrumentation documentation
Internal logic is described but not exposed for configuration in Microsoft's docs
Example use-case:
// We attempted to use custom filter logic: .AddSqlClientInstrumentation(options => { options.Filter = (obj) => { /* ... */ }; }) .AddProcessor(new FilteringProcessor(...)); // Layers of filtering still do not prevent all unwanted traces from reaching Insights due to exporter’s own filter.
We would greatly appreciate support for more flexible, user-defined filtering in the Azure Monitor exporter pipeline. Thank you!
Environment
No response