Azure Functions 项目中的请求遥测数据过滤方案解析

在分布式系统架构中，Azure Functions 作为后端服务常常需要与前端负载均衡组件（如 Azure Front Door）配合使用。一个典型的场景是：多个地理分布的 Function App 实例通过健康检查端点（probe endpoint）向负载均衡器报告自身状态。然而，这类高频调用的健康检查请求会产生大量不必要的 Application Insights 遥测数据，导致监控成本上升和有效数据稀释。

核心问题分析

Azure Functions 运行时默认会收集所有 HTTP 触发函数的请求遥测数据（Request Telemetry），这些数据包含响应状态码、持续时间等关键指标。虽然通过 host.json 可以控制日志级别：

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "Function.probe_endpt": "None"
    }
  }
}

但该配置仅影响日志输出，无法阻止请求级遥测数据的生成和上报。这是由 Functions 运行时的设计决定的——请求遥测属于基础设施层面的监控数据，与业务日志属于不同维度。

技术解决方案

方案一：自定义遥测处理器（推荐）

通过实现 ITelemetryProcessor 接口，可以在数据发送到 Application Insights 前进行动态过滤：

public class HealthProbeFilter : ITelemetryProcessor
{
    private readonly ITelemetryProcessor _next;

    public HealthProbeFilter(ITelemetryProcessor next)
    {
        _next = next;
    }

    public void Process(ITelemetry item)
    {
        if (item is RequestTelemetry request && 
            request.Url.AbsolutePath.Contains("/api/probe"))
        {
            return;
        }
        _next.Process(item);
    }
}

注册处理器需在 Startup.cs 中配置：

builder.Services.AddApplicationInsightsTelemetryProcessor<HealthProbeFilter>();

方案二：采样策略调整

对于需要保留部分样本的场景，可配置自适应采样：

{
  "ApplicationInsights": {
    "SamplingSettings": {
      "IsEnabled": true,
      "MaxTelemetryItemsPerSecond": 5,
      "ExcludedTypes": "Request"
    }
  }
}

架构建议

1. 端点分离设计：将健康检查端点部署为独立的 Function App，配置不同的 Application Insights 实例
2. 轻量级协议：考虑改用 TCP 健康检查替代 HTTP 检查
3. 监控分层：对业务请求和健康检查请求使用不同的监控指标

未来演进方向

Azure Functions 团队正在评估按函数粒度控制请求遥测的特性需求。可能的实现方式包括：

• 在函数绑定属性中添加遥测控制标记
• 支持基于路由模式的 host.json 配置
• 提供运行时环境变量覆盖能力

当前建议采用自定义遥测处理器的方案，该方式具有最好的灵活性和可控性，且不影响系统原有监控体系的其他维度数据收集。