Skip to content

[QUERY] Unable to override or customize internal filtering logic in AzureMonitorOpenTelemetryExporter (App Insights integration) #52980

@StefanOstergaard

Description

@StefanOstergaard

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    ClientThis issue is related to a non-management packageMonitor - ExporterMonitor OpenTelemetry ExporterService AttentionWorkflow: This issue is responsible by Azure service team.customer-reportedIssues that are reported by GitHub users external to the Azure organization.needs-team-attentionWorkflow: This issue needs attention from Azure service team or SDK teamquestionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions