在Azure Monitor中通过OpenTelemetry过滤HTTP请求活动的问题

库名称及版本 #

Azure.Monitor.OpenTelemetry.AspNetCore 1.2.0

问题背景 #

我们使用.NET Core内置的身份验证/授权功能，配置了多个不同OpenID提供商的认证方案。每次API请求的首次调用，都会向所有OpenID提供商的.well-known端点发送请求。这一行为本身没问题，但会在Application Insights中生成大量无关的请求和依赖追踪，我们希望过滤掉这些追踪。按照官方配置指南，我做了如下配置：

builder.Services.AddOpenTelemetry().UseAzureMonitor();
builder.Services.Configure<HttpClientTraceInstrumentationOptions>(options =>
{
    options.FilterHttpRequestMessage = req =>
        !req.RequestUri.ToString().Contains(".well-known");
});

遇到的问题 #

1. 配置后仍然会生成request类型的遥测数据，尽管过滤条件逻辑是正确的。
2. UseAzureMonitor本身已经配置了HTTP检测，但我的配置会覆盖它的原有设置。

疑问 #

1. 如何完全过滤掉这些无关追踪？请给出具体方案。
2. 覆盖HTTP检测似乎违背了UseAzureMonitor的设计初衷，我希望过滤规则是叠加而非替换，是不是操作方式有误？目前是否只有覆盖这一种方法？
3. 我创建了ActivityFilteringProcessor并设置IsAllDataRequested = false，但无法完全过滤掉这些追踪。

环境信息 #

• Windows 10
• Visual Studio 2022 17.10.1
• .NET SDK：
  • 版本：8.0.300
  • Commit：326f6e68b2
  • Workload版本：8.0.300-manifests.4e5ea2d8
  • MSBuild版本：17.10.4+10fbfbf2e
• 运行时环境：
  • OS名称：Windows
  • OS版本：10.0.19045
  • OS平台：Windows
  • RID：win-x64
  • 基础路径：C:\Program Files\dotnet\sdk\8.0.300\

解决方案 #

1. 完全过滤.well-known端点的遥测数据 #

仅配置HttpClientTraceInstrumentationOptions只能过滤依赖追踪，若仍有request类型遥测，需同时通过自定义Activity处理器拦截所有相关Activity：

builder.Services.AddOpenTelemetry()
    .UseAzureMonitor()
    .WithTracing(tracingBuilder =>
    {
        // 配置HttpClient过滤规则
        tracingBuilder.AddHttpClientInstrumentation(options =>
        {
            options.FilterHttpRequestMessage = req => 
                !req.RequestUri.ToString().Contains(".well-known");
        });
        // 添加自定义处理器拦截相关Activity
        tracingBuilder.AddProcessor<WellKnownActivityProcessor>();
    });

// 自定义Activity处理器
public class WellKnownActivityProcessor : BaseProcessor<Activity>
{
    public override void OnStart(Activity activity)
    {
        // 匹配包含.well-known的Activity，标记为不收集数据
        if (activity.DisplayName.Contains(".well-known") || 
            activity.Tags.Any(t => t.Key == "http.url" && t.Value.ToString().Contains(".well-known")))
        {
            activity.IsAllDataRequested = false;
        }
        base.OnStart(activity);
    }
}

若request类型遥测来自入站请求（罕见情况），需额外添加ASP.NET Core请求过滤：

tracingBuilder.AddAspNetCoreInstrumentation(options =>
{
    options.Filter = context => 
        !context.Request.Path.ToString().Contains(".well-known");
});

2. 叠加而非覆盖HTTP检测配置 #

之前使用Configure<HttpClientTraceInstrumentationOptions>会直接覆盖默认配置，改用ConfigureAll实现规则叠加：

builder.Services.AddOpenTelemetry().UseAzureMonitor();

builder.Services.ConfigureAll<HttpClientTraceInstrumentationOptions>(options =>
{
    // 保留原有过滤逻辑，叠加自定义规则
    var originalFilter = options.FilterHttpRequestMessage;
    options.FilterHttpRequestMessage = req =>
    {
        // 先执行原有过滤，再应用自定义规则
        return originalFilter?.Invoke(req) != false && !req.RequestUri.ToString().Contains(".well-known");
    };
});

或在WithTracing中直接修改HttpClientInstrumentation配置，确保不覆盖原有设置：

builder.Services.AddOpenTelemetry()
    .UseAzureMonitor()
    .WithTracing(tracingBuilder =>
    {
        tracingBuilder.ConfigureInstrumentation<HttpClientInstrumentationOptions>(options =>
        {
            var originalFilter = options.FilterHttpRequestMessage;
            options.FilterHttpRequestMessage = req =>
                originalFilter?.Invoke(req) != false && !req.RequestUri.ToString().Contains(".well-known");
        });
    });

3. 修复Activity处理器过滤失效问题 #

之前的处理器未生效，可能是未正确关联到OpenTelemetry追踪构建器，或拦截时机不对。上面的WellKnownActivityProcessor在OnStart阶段（Activity创建初期）就标记不收集数据，能确保OpenTelemetry不会生成对应的遥测。同时要保证处理器通过tracingBuilder.AddProcessor()注册，而非仅依赖DI容器注册。

内容的提问来源于stack exchange，提问作者jaceks2106