Telemetry processor

In the classic .NET SDK (2.x) a processor implements ITelemetryProcessor. Each one holds a reference to the next, and its Process(ITelemetry item) method either calls the next processor or returns without calling it, which drops the item. Adaptive sampling (AdaptiveSamplingTelemetryProcessor) and fixed-rate sampling (SamplingTelemetryProcessor) are processors in the same chain.

The usual hand-written processor drops noise, such as health probes:

public class DropHealthChecks : ITelemetryProcessor
{
    private readonly ITelemetryProcessor _next;
    public DropHealthChecks(ITelemetryProcessor next) => _next = next;

    public void Process(ITelemetry item)
    {
        if (item is RequestTelemetry r && r.Url?.AbsolutePath == "/health") return;
        _next.Process(item);
    }
}

Dropping is filtering, not sampling. A dropped item leaves no itemCount behind, so request counts and failure rates fall with it; keep filters for items you never want counted. Where a processor sits matters too: one placed after sampling only sees the items sampling kept.

A telemetry initializer is the other classic hook: it runs on every item to add values and can’t drop anything. The .NET SDK 3.x and the OpenTelemetry distros run neither; Microsoft’s migration guidance moves custom processors to OpenTelemetry processors. Java 2.x processors don’t run under the 3.x agent, which has its own telemetry processors in preview.