How to selectively filter HttpClient Instrumentation?

[pbolduc]

When adding HttpClient Instrumentation, we can use the HttpClientTraceInstrumentationOptions.FilterHttpRequestMessage to filter based on the request. Our app has a number of out going requests that I dont about the trace IF they complete successfully (ie status code = 200). These requests are either background ping, logging to Splunk via HEC, or fetching access tokens for various authenticated services. Is the approach to add a processor like this?

public sealed class SplunkEventCollectorFilteringProcessor(string _address, string _method, string _statusCode) : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        bool address = false;
        bool method = false;
        bool statusCode = false;

        foreach (var tag in activity.Tags)
        {
            switch (tag.Key)
            {
                case "server.address": address = tag.Value == _address; break;
                case "http.request.method": method = tag.Value == _method; break;
                case "http.response.status_code": statusCode = tag.Value == _statusCode; break;
            }
        }

        if (address && method && statusCode)
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded; // drop the activity
        }
    }
}

However that will run on all activities, so should this work?

.AddHttpClientInstrumentation(options =>
{
    options.EnrichWithHttpResponseMessage = (activity, response) =>
    {
        if (!response.IsSuccessStatusCode)
        {
            var request = response.RequestMessage;
            if (request?.RequestUri?.Host == "splunk.host.name" && request.Method == HttpMethod.Post)
            {
                activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded; // drop the activity
            }
        }
    };
})

[cijothomas]

https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Instrumentation.Http#filter-httpclient-api

Enrich is intended for enrichment, not filtering (though, it can technically be used as your example demonstrated.)
For you use-case, use the filtering capability provided by the instrumentation itself, as it'll likely be faster than the general purpose ActivityProcessor approach!

[pbolduc]

The filtering capability is only on the request so the response status code is unknown when the filter is executed. It does feel dirty to be using the EnrichWithHttpResponseMessage method to filter traces. However, if that is the only facility at this point, I guess I will either have to use it, or live with the extra trace messages. Our traces are not going to a cloud service, so not a cost concern. The concern is more of "noise" when looking at more important traces. Thanks for the quick reply.

[cijothomas]

Got it! Sorry I forgot that filter cannot be used for anything not known early! (like status code!)

If your goal is to eliminate/drop activity based on certain activity tags, then ActivityProcessor is good for that. Instrumentation library gives easy access to things like HttpRequest raw object, so use that, if you need easy access to those raw objects!