ApplicationInsights-dotnet 自定义处理器详解Activity/Log Processor 实现遥测富集与过滤【免费下载链接】ApplicationInsights-dotnetApplicationInsights-dotnet项目地址: https://gitcode.com/gh_mirrors/ap/ApplicationInsights-dotnetApplicationInsights-dotnet 是微软 Azure 应用性能监控APM的官方 .NET SDK。从 3.x 版本起它全面转向 OpenTelemetry 架构自定义处理器Activity Processor 与 Log Processor成为过滤遥测数据和富集遥测上下文的核心手段。本文带你快速掌握如何用处理器剔除健康检查等噪声数据、为每条遥测附加自定义标签并理解 SDK 内置处理器的性能设计。为什么需要自定义处理器在实际生产环境中原始遥测数据往往又吵又杂噪声太多/health、/ready等健康检查请求每分钟几百次淹没有价值的请求数据信息不足每条遥测缺少部署环境、租户标识、业务版本等关键维度排查问题时无法过滤成本浪费无用的遥测持续上传增加流量和存储开销自定义处理器正是解决这两个问题的标准方案过滤不需要的数据直接丢弃富集给数据打上业务标签。处理器机制两条独立的管线3.x 版本基于 OpenTelemetry 构建处理器分为两类分别工作在不同的数据管线上处理器类型处理对象典型场景Activity Processor分布式追踪 Span过滤请求/依赖、附加标签Log Processor结构化日志记录日志富集、日志脱敏⚠️关键点Trace 和 Log 是两条完全独立的管线——追踪处理器永远看不到日志反之亦然。如果你的需求同时涉及两者需要注册两个处理器。快速上手过滤与富集 Trace一键过滤丢弃健康检查请求过滤的正确方式是清除Recorded标记而不是跳过base.OnEnd()调用。这样 Span 不再导出但上下文传播依然正常public class HealthCheckFilterProcessor : BaseProcessorActivity { private static readonly HashSetstring SuppressedPaths new(StringComparer.OrdinalIgnoreCase) { /health, /ready, /healthz, /liveness }; public override void OnEnd(Activity data) { var path data.GetTagItem(url.path)?.ToString(); if (path ! null SuppressedPaths.Contains(path)) { data.ActivityTraceFlags ~ActivityTraceFlags.Recorded; // 阻止导出 } } }富集标签为每条 Span 附加业务维度在OnStart中通过SetTag附加标签Span 完成前即可携带自定义信息public class EnrichmentProcessor : BaseProcessorActivity { public override void OnStart(Activity data) { data.SetTag(deployment.environment, production); data.SetTag(cloud.region, eastus); } }最简注册方法DI 场景ASP.NET Core / Worker Service通过扩展方法一行注册builder.Services.ConfigureOpenTelemetryTracerProvider(tracing tracing.AddProcessorHealthCheckFilterProcessor() .AddProcessorEnrichmentProcessor());非 DI 场景控制台 / 经典 ASP.NET则通过TelemetryConfiguration.ConfigureOpenTelemetryBuilder配置。Log Processor日志管线的富集与过滤日志处理器继承BaseProcessorLogRecord操作的是结构化日志的Attributes集合。富集时把新属性合并进data.Attributes即可而按日志级别或类别过滤时优先使用ILoggingBuilder.AddFilter比处理器更轻量、更直接builder.Services.ConfigureOpenTelemetryLoggerProvider(logging logging.AddProcessorLogEnrichmentProcessor()); builder.Logging.AddFilterOpenTelemetryLoggerProvider(Microsoft, LogLevel.Warning);常用的LogRecord属性包括LogLevel严重级别、CategoryName日志类别、Attributes结构化参数和TraceId/SpanId与父追踪关联可以基于它们编写精细的过滤逻辑。内置处理器的高性能设计预热快照机制SDK 内部自带两个上下文处理器TelemetryContextActivityProcessor.cs 和 TelemetryContextLogProcessor.cs负责把客户端级别的TelemetryContext用户 ID、会话 ID、设备信息等 12 项上下文自动附加到每条遥测上且遵循已存在则跳过的优先级规则。它们的源码值得学习因为其中包含一个精妙的预热快照优化前 10 次调用走慢路径遍历完整的 TelemetryContext 对象图逐个附加非空属性10 次调用且构造 5 秒之后把上下文固化为一个不可变的快照数组之后走快路径直接遍历快照数组无对象图导航、几乎零分配日志处理器更进一步当日志记录本身没有属性时直接复用快照数组引用实现完全零分配。这个设计基于用户通常在初始化阶段一次性设置 Context的约定是高性能遥测处理的典范。从 2.x 迁移ITelemetryProcessor 怎么办如果你从 2.x 版本升级原有的ITelemetryProcessor已被移除迁移规则很简单自定义处理器改为继承BaseProcessorActivity把原来的Process(ITelemetry)逻辑移到OnEnd中内置处理器采样、自适应采样、QuickPulse、自动指标提取无需手动迁移3.x 已自动内置直接删除手动注册即可完整的迁移对照示例可参考 processor-migration.md。常用 Activity 属性速查编写处理器时Activity上这些属性最常用DisplayName— 操作名称Kind—Server入站请求/Client出站依赖/Internal/Producer/ConsumerDuration/Status— 耗时与状态GetTagItem(key)/SetTag(key, value)— 读写任意标签TraceId/SpanId/ParentId— 关联 ID相关源码与文档自定义处理器完整指南过滤、富集、注册方式skills/applicationinsights-setup/references/custom-processors.md内置 Activity 处理器实现BASE/src/Microsoft.ApplicationInsights/Processors/TelemetryContextActivityProcessor.cs内置 Log 处理器实现BASE/src/Microsoft.ApplicationInsights/Processors/TelemetryContextLogProcessor.cs按配置开关过滤请求/依赖的实战示例NETCORE/src/Shared/ActivityFilterProcessor.cs处理器行为测试可直接参照编写测试BASE/Test/Microsoft.ApplicationInsights.Test/Microsoft.ApplicationInsights.Tests/TelemetryContextActivityProcessorTests.cs2.x 处理器迁移指南skills/applicationinsights-setup/references/processor-migration.md总结掌握 Activity Processor 和 Log Processor你就拥有了 3.x 版本中最灵活的遥测控制能力——用Recorded标记过滤噪声用SetTag和Attributes富集业务上下文并通过.AddProcessorT()一行代码完成注册。【免费下载链接】ApplicationInsights-dotnetApplicationInsights-dotnet项目地址: https://gitcode.com/gh_mirrors/ap/ApplicationInsights-dotnet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ApplicationInsights-dotnet 自定义处理器详解：Activity/Log Processor 实现遥测富集与过滤
ApplicationInsights-dotnet 自定义处理器详解Activity/Log Processor 实现遥测富集与过滤【免费下载链接】ApplicationInsights-dotnetApplicationInsights-dotnet项目地址: https://gitcode.com/gh_mirrors/ap/ApplicationInsights-dotnetApplicationInsights-dotnet 是微软 Azure 应用性能监控APM的官方 .NET SDK。从 3.x 版本起它全面转向 OpenTelemetry 架构自定义处理器Activity Processor 与 Log Processor成为过滤遥测数据和富集遥测上下文的核心手段。本文带你快速掌握如何用处理器剔除健康检查等噪声数据、为每条遥测附加自定义标签并理解 SDK 内置处理器的性能设计。为什么需要自定义处理器在实际生产环境中原始遥测数据往往又吵又杂噪声太多/health、/ready等健康检查请求每分钟几百次淹没有价值的请求数据信息不足每条遥测缺少部署环境、租户标识、业务版本等关键维度排查问题时无法过滤成本浪费无用的遥测持续上传增加流量和存储开销自定义处理器正是解决这两个问题的标准方案过滤不需要的数据直接丢弃富集给数据打上业务标签。处理器机制两条独立的管线3.x 版本基于 OpenTelemetry 构建处理器分为两类分别工作在不同的数据管线上处理器类型处理对象典型场景Activity Processor分布式追踪 Span过滤请求/依赖、附加标签Log Processor结构化日志记录日志富集、日志脱敏⚠️关键点Trace 和 Log 是两条完全独立的管线——追踪处理器永远看不到日志反之亦然。如果你的需求同时涉及两者需要注册两个处理器。快速上手过滤与富集 Trace一键过滤丢弃健康检查请求过滤的正确方式是清除Recorded标记而不是跳过base.OnEnd()调用。这样 Span 不再导出但上下文传播依然正常public class HealthCheckFilterProcessor : BaseProcessorActivity { private static readonly HashSetstring SuppressedPaths new(StringComparer.OrdinalIgnoreCase) { /health, /ready, /healthz, /liveness }; public override void OnEnd(Activity data) { var path data.GetTagItem(url.path)?.ToString(); if (path ! null SuppressedPaths.Contains(path)) { data.ActivityTraceFlags ~ActivityTraceFlags.Recorded; // 阻止导出 } } }富集标签为每条 Span 附加业务维度在OnStart中通过SetTag附加标签Span 完成前即可携带自定义信息public class EnrichmentProcessor : BaseProcessorActivity { public override void OnStart(Activity data) { data.SetTag(deployment.environment, production); data.SetTag(cloud.region, eastus); } }最简注册方法DI 场景ASP.NET Core / Worker Service通过扩展方法一行注册builder.Services.ConfigureOpenTelemetryTracerProvider(tracing tracing.AddProcessorHealthCheckFilterProcessor() .AddProcessorEnrichmentProcessor());非 DI 场景控制台 / 经典 ASP.NET则通过TelemetryConfiguration.ConfigureOpenTelemetryBuilder配置。Log Processor日志管线的富集与过滤日志处理器继承BaseProcessorLogRecord操作的是结构化日志的Attributes集合。富集时把新属性合并进data.Attributes即可而按日志级别或类别过滤时优先使用ILoggingBuilder.AddFilter比处理器更轻量、更直接builder.Services.ConfigureOpenTelemetryLoggerProvider(logging logging.AddProcessorLogEnrichmentProcessor()); builder.Logging.AddFilterOpenTelemetryLoggerProvider(Microsoft, LogLevel.Warning);常用的LogRecord属性包括LogLevel严重级别、CategoryName日志类别、Attributes结构化参数和TraceId/SpanId与父追踪关联可以基于它们编写精细的过滤逻辑。内置处理器的高性能设计预热快照机制SDK 内部自带两个上下文处理器TelemetryContextActivityProcessor.cs 和 TelemetryContextLogProcessor.cs负责把客户端级别的TelemetryContext用户 ID、会话 ID、设备信息等 12 项上下文自动附加到每条遥测上且遵循已存在则跳过的优先级规则。它们的源码值得学习因为其中包含一个精妙的预热快照优化前 10 次调用走慢路径遍历完整的 TelemetryContext 对象图逐个附加非空属性10 次调用且构造 5 秒之后把上下文固化为一个不可变的快照数组之后走快路径直接遍历快照数组无对象图导航、几乎零分配日志处理器更进一步当日志记录本身没有属性时直接复用快照数组引用实现完全零分配。这个设计基于用户通常在初始化阶段一次性设置 Context的约定是高性能遥测处理的典范。从 2.x 迁移ITelemetryProcessor 怎么办如果你从 2.x 版本升级原有的ITelemetryProcessor已被移除迁移规则很简单自定义处理器改为继承BaseProcessorActivity把原来的Process(ITelemetry)逻辑移到OnEnd中内置处理器采样、自适应采样、QuickPulse、自动指标提取无需手动迁移3.x 已自动内置直接删除手动注册即可完整的迁移对照示例可参考 processor-migration.md。常用 Activity 属性速查编写处理器时Activity上这些属性最常用DisplayName— 操作名称Kind—Server入站请求/Client出站依赖/Internal/Producer/ConsumerDuration/Status— 耗时与状态GetTagItem(key)/SetTag(key, value)— 读写任意标签TraceId/SpanId/ParentId— 关联 ID相关源码与文档自定义处理器完整指南过滤、富集、注册方式skills/applicationinsights-setup/references/custom-processors.md内置 Activity 处理器实现BASE/src/Microsoft.ApplicationInsights/Processors/TelemetryContextActivityProcessor.cs内置 Log 处理器实现BASE/src/Microsoft.ApplicationInsights/Processors/TelemetryContextLogProcessor.cs按配置开关过滤请求/依赖的实战示例NETCORE/src/Shared/ActivityFilterProcessor.cs处理器行为测试可直接参照编写测试BASE/Test/Microsoft.ApplicationInsights.Test/Microsoft.ApplicationInsights.Tests/TelemetryContextActivityProcessorTests.cs2.x 处理器迁移指南skills/applicationinsights-setup/references/processor-migration.md总结掌握 Activity Processor 和 Log Processor你就拥有了 3.x 版本中最灵活的遥测控制能力——用Recorded标记过滤噪声用SetTag和Attributes富集业务上下文并通过.AddProcessorT()一行代码完成注册。【免费下载链接】ApplicationInsights-dotnetApplicationInsights-dotnet项目地址: https://gitcode.com/gh_mirrors/ap/ApplicationInsights-dotnet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考