Filter Azure Monitor OpenTelemetry for .NET, Java, Node.js, and Python applications

06/04/2025

This guide provides instructions on filtering OpenTelemetry (OTel) data within Azure Monitor Application Insights. Implementing filters allows developers to exclude unnecessary telemetry and prevent the collection of sensitive information, ensuring optimized performance and compliance.

Reasons why you might want to filter out telemetry include:

Filtering out health check telemetry to reduce noise.
Ensuring PII and credentials aren't collected.
Filtering out low-value telemetry to optimize performance.

To learn more about OpenTelemetry concepts, see the OpenTelemetry overview or OpenTelemetry FAQ.

Note

For Azure Function Apps, see Use OpenTelemetry with Azure Functions.

Filter OpenTelemetry using instrumentation libraries

For a list of all instrumentation libraries included with the Azure Monitor OpenTelemetry Distro, see Add and modify Azure Monitor OpenTelemetry for .NET, Java, Node.js, and Python applications.

Many instrumentation libraries provide a filter option. For guidance, see the corresponding readme files:

¹ We include the SqlClient instrumentation in our package while it's still in beta. When it reaches a stable release, we include it as a standard package reference. Until then, to customize the SQLClient instrumentation, add the OpenTelemetry.Instrumentation.SqlClient package reference to your project and use its public API.

dotnet add package --prerelease OpenTelemetry.Instrumentation.SqlClient

builder.Services.AddOpenTelemetry().UseAzureMonitor().WithTracing(builder =>
{
    builder.AddSqlClientInstrumentation(options =>
    {
        options.SetDbStatementForStoredProcedure = false;
    });
});

Note

This example is specific to HTTP instrumentations. For other signal types, there's currently no specific mechanism available to filter out telemetry. Instead, a custom span processor is required.

The following example shows how to exclude a certain URL from being tracked by using the HTTP/HTTPS instrumentation library:

// Import the useAzureMonitor function and the ApplicationInsightsOptions class from the @azure/monitor-opentelemetry package.
const { useAzureMonitor, ApplicationInsightsOptions } = require("@azure/monitor-opentelemetry");

// Import the HttpInstrumentationConfig class from the @opentelemetry/instrumentation-http package.
const { HttpInstrumentationConfig }= require("@opentelemetry/instrumentation-http");

// Import the IncomingMessage and RequestOptions classes from the http and https packages, respectively.
const { IncomingMessage } = require("http");
const { RequestOptions } = require("https");

// Create a new HttpInstrumentationConfig object.
const httpInstrumentationConfig: HttpInstrumentationConfig = {
    enabled: true,
    ignoreIncomingRequestHook: (request: IncomingMessage) => {
    // Ignore OPTIONS incoming requests.
    if (request.method === 'OPTIONS') {
        return true;
    }
    return false;
    },
    ignoreOutgoingRequestHook: (options: RequestOptions) => {
    // Ignore outgoing requests with the /test path.
    if (options.path === '/test') {
        return true;
    }
    return false;
    }
};

// Create a new ApplicationInsightsOptions object.
const config: ApplicationInsightsOptions = {
    instrumentationOptions: {
    http: {
        httpInstrumentationConfig
    }
    }
};

// Enable Azure Monitor integration using the useAzureMonitor function and the ApplicationInsightsOptions object.
useAzureMonitor(config);

Note

This example is specific to HTTP instrumentations. For other signal types, there's currently no specific mechanism available to filter out telemetry. Instead, a custom span processor is required.

The following example shows how to exclude a certain URL from being tracked by using the OTEL_PYTHON_EXCLUDED_URLS environment variable:

export OTEL_PYTHON_EXCLUDED_URLS="http://localhost:8080/ignore"

Doing so excludes the endpoint shown in the following Flask example:

...
# Import the Flask and Azure Monitor OpenTelemetry SDK libraries.
import flask
from azure.monitor.opentelemetry import configure_azure_monitor

# Configure OpenTelemetry to use Azure Monitor with the specified connection string.
# Replace `<your-connection-string>` with the connection string to your Azure Monitor Application Insights resource.
configure_azure_monitor(
    connection_string="<your-connection-string>",
)

# Create a Flask application.
app = flask.Flask(__name__)

# Define a route. Requests sent to this endpoint will not be tracked due to
# flask_config configuration.
@app.route("/ignore")
def ignore():
    return "Request received but not tracked."
...

Filter telemetry using span processors

Use a custom processor:

Tip

Add the processor shown here before adding Azure Monitor.

// Create an ASP.NET Core application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry tracer provider to add a new processor named ActivityFilteringProcessor.
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddProcessor(new ActivityFilteringProcessor()));
// Configure the OpenTelemetry tracer provider to add a new source named "ActivitySourceName".
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddSource("ActivitySourceName"));
// Add the Azure Monitor telemetry service to the application. This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core application.
var app = builder.Build();

// Start the ASP.NET Core application.
app.Run();

Add ActivityFilteringProcessor.cs to your project with the following code:

public class ActivityFilteringProcessor : BaseProcessor<Activity>
{
    // The OnStart method is called when an activity is started. This is the ideal place to filter activities.
    public override void OnStart(Activity activity)
    {
        // prevents all exporters from exporting internal activities
        if (activity.Kind == ActivityKind.Internal)
        {
            activity.IsAllDataRequested = false;
        }
    }
}

If a particular source isn't explicitly added by using AddSource("ActivitySourceName"), then none of the activities created by using that source are exported.

Use a custom processor:

// Create an OpenTelemetry tracer provider builder.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
        .AddSource("OTel.AzureMonitor.Demo") // Add a source named "OTel.AzureMonitor.Demo".
        .AddProcessor(new ActivityFilteringProcessor()) // Add a new processor named ActivityFilteringProcessor.
        .AddAzureMonitorTraceExporter() // Add the Azure Monitor trace exporter.
        .Build();

Add ActivityFilteringProcessor.cs to your project with the following code:

public class ActivityFilteringProcessor : BaseProcessor<Activity>
{
    // The OnStart method is called when an activity is started. This is the ideal place to filter activities.
    public override void OnStart(Activity activity)
    {
        // prevents all exporters from exporting internal activities
        if (activity.Kind == ActivityKind.Internal)
        {
            activity.IsAllDataRequested = false;
        }
    }
}

If a particular source isn't explicitly added by using AddSource("ActivitySourceName"), then none of the activities created by using that source are exported.

You can use a custom span processor to exclude certain spans from being exported. To mark spans to not be exported, set TraceFlag to DEFAULT.

Use the custom property example, but replace the following lines of code:

// Import the necessary packages.
const { SpanKind, TraceFlags } = require("@opentelemetry/api");
const { ReadableSpan, Span, SpanProcessor } = require("@opentelemetry/sdk-trace-base");

// Create a new SpanEnrichingProcessor class.
class SpanEnrichingProcessor implements SpanProcessor {
    forceFlush(): Promise<void> {
        return Promise.resolve();
    }

    shutdown(): Promise<void> {
        return Promise.resolve();
    }

    onStart(_span: Span): void {}

    onEnd(span) {
        // If the span is an internal span, set the trace flags to NONE.
        if(span.kind == SpanKind.INTERNAL){
        span.spanContext().traceFlags = TraceFlags.NONE;
        }
    }
}

You can use a custom span processor to exclude certain spans from being exported. To mark spans to not be exported, set TraceFlag to DEFAULT:

...
# Import the necessary libraries.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace

# Configure OpenTelemetry to use Azure Monitor with the specified connection string.
# Replace `<your-connection-string>` with the connection string to your Azure Monitor Application Insights resource.
configure_azure_monitor(
    connection_string="<your-connection-string>",
    # Configure the custom span processors to include span filter processor.
    span_processors=[span_filter_processor],
)

...

Add SpanFilteringProcessor to your project with the following code:

# Import the necessary libraries.
from opentelemetry.trace import SpanContext, SpanKind, TraceFlags
from opentelemetry.sdk.trace import SpanProcessor

# Define a custom span processor called `SpanFilteringProcessor`.
class SpanFilteringProcessor(SpanProcessor):

    # Prevents exporting spans from internal activities.
    def on_start(self, span, parent_context):
        # Check if the span is an internal activity.
        if span._kind is SpanKind.INTERNAL:
            # Create a new span context with the following properties:
            #   * The trace ID is the same as the trace ID of the original span.
            #   * The span ID is the same as the span ID of the original span.
            #   * The is_remote property is set to `False`.
            #   * The trace flags are set to `DEFAULT`.
            #   * The trace state is the same as the trace state of the original span.
            span._context = SpanContext(
                span.context.trace_id,
                span.context.span_id,
                span.context.is_remote,
                TraceFlags(TraceFlags.DEFAULT),
                span.context.trace_state,
            )

Next steps

To further configure the OpenTelemetry distro, see Azure Monitor OpenTelemetry configuration.
To review the source code, see the Azure Monitor AspNetCore GitHub repository.
To install the NuGet package, check for updates, or view release notes, see the Azure Monitor AspNetCore NuGet Package page.
To become more familiar with Azure Monitor and OpenTelemetry, see the Azure Monitor Example Application.
To learn more about OpenTelemetry and its community, see the OpenTelemetry .NET GitHub repository.
To enable usage experiences, enable web or browser user monitoring.
To review frequently asked questions, troubleshooting steps, support options, or to provide OpenTelemetry feedback, see OpenTelemetry help, support, and feedback for Azure Monitor Application Insights.

To review the source code, see the Azure Monitor OpenTelemetry GitHub repository.
To install the npm package and check for updates, see the @azure/monitor-opentelemetry npm Package page.
To become more familiar with Azure Monitor Application Insights and OpenTelemetry, see the Azure Monitor Example Application.
To learn more about OpenTelemetry and its community, see the OpenTelemetry JavaScript GitHub repository.
To enable usage experiences, enable web or browser user monitoring.
To review frequently asked questions, troubleshooting steps, support options, or to provide OpenTelemetry feedback, see OpenTelemetry help, support, and feedback for Azure Monitor Application Insights.

Filter Azure Monitor OpenTelemetry for .NET, Java, Node.js, and Python applications

Filter OpenTelemetry using instrumentation libraries

Filter telemetry using span processors

Next steps

Additional resources