后端消息队列微服务消息路由【免费下载链接】CAPDistributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern项目地址https://gitcode.com/gh_mirrors/ca/CAP点击查看免费下载CAP 内置了面向 OpenTelemetry 的仪器化Instrumentation支持通过DotNetCore.CAP.OpenTelemetry包即可将消息发布、持久化、消费与订阅者调用等关键环节的跟踪数据自动接入 OpenTelemetry并配合 Zipkin 等后端完成可视化。本文以当前仓库中的官方中文指南为主体结合源码实现细节说明如何安装与配置 CAP Instrumentation、理解其底层数据来源Diagnostics与 Span 结构以及如何利用 Context Propagation 在消息传递过程中保持分布式上下文的连续性帮助你在微服务场景中快速搭建出可观测的消息链路。什么是 OpenTelemetryOpenTelemetry 是工具、API 与 SDK 的集合用于对软件进行插桩Instrument从而生成、收集并导出遥测数据度量 Metrics、日志 Logs 与跟踪 Traces帮助你分析软件的性能与行为。它提供了统一的跨语言标准使不同服务、不同技术栈产生的可观测数据可以被一致地采集和展示。在 .NET 场景下OpenTelemetry 提供了成熟的 .NET SDK你可以在官方入门文档中找到如何在控制台应用或 ASP.NET Core 中使用它。本文将聚焦于如何把 CAP 集成进 OpenTelemetry而不是重复介绍 OpenTelemetry 本身的基础用法。CAP 与 OpenTelemetry 的集成原理CAP 对 OpenTelemetry 的跟踪数据支持不是独立实现的而是建立在其已有的 诊断Diagnostics 机制之上CAP 在运行的关键节点会通过 .NETDiagnosticSource发出诊断事件OpenTelemetry 的 CAP Instrumentation 订阅这些事件并将其转换为标准Activity即 Span供 OpenTelemetry 采集。诊断监听器名称为CapDiagnosticListener定义于 CapDiagnosticListenerNames.csCAP 对外提供的事件包括消息持久化之前/之后/异常、消息向 MQ 发送之前/之后/异常、消息从 MQ 消费保存之前/之后、订阅者方法执行之前/之后/异常共 11 类事件名均以DotNetCore.CAP.前缀定义在同一个文件CapDiagnosticListenerNames.cs这些事件由 IMessageSender.Default.cs 等内部组件在真实的消息发送流程中写入事件负载EventData则定义于 EventData.Cap.P.cs 与 EventData.Cap.S.cs。因此只要在 OpenTelemetry 的扩展配置中添加 CAP Instrumentation它便会自动订阅上述诊断事件并完成跟踪数据的收集无需在业务代码中手动埋点。安装 CAP 的 OpenTelemetry 包首先在你的项目中安装DotNetCore.CAP.OpenTelemetry包dotnet add package DotNetCore.CAP.OpenTelemetry从项目文件可以看出该包以net8.0为目标框架并依赖OpenTelemetry 1.16.0与核心库DotNetCore.CAP见 DotNetCore.CAP.OpenTelemetry.csproj其包描述即为 CAP instrumentation for OpenTelemetry .NET。配置 OpenTelemetry 与 CAP Instrumentation安装完成后在Startup或Program.cs的依赖注入配置中添加如下代码即可启用 CAP 的跟踪数据采集services.AddOpenTelemetryTracing((builder) builder .AddAspNetCoreInstrumentation() .AddCapInstrumentation() // -- 添加这行 .AddZipkinExporter() );其中AddAspNetCoreInstrumentation()采集 ASP.NET Core 自身的请求跟踪数据用于建立从 HTTP 请求到消息事件的根 SpanAddCapInstrumentation()启用 CAP 的消息事件数据采集即本篇文章的核心扩展方法AddZipkinExporter()将跟踪数据导出到 Zipkin你也可以根据实际选型替换为 Jaeger、OTLP 等其他 Exporter。从源码实现看AddCapInstrumentation()定义在 TracerProviderBuilder.Extension.cs它的工作流程分为三步调用builder.AddSource(DiagnosticListener.SourceName)把 CAP 的 ActivitySource 名称DotNetCore.CAP.OpenTelemetry见 DiagnosticListener.cs注册进 TracerProvider使 OpenTelemetry 能够采集该 Source 产生的所有 Activity创建CapInstrumentation实例其内部通过DiagnosticSourceSubscriber订阅 CAP 的诊断源CapInstrumentation.cs通过builder.AddInstrumentation将实例注册到 Provider 生命周期中应用关闭时会自动调用Dispose清理订阅。非 ASP.NET Core 环境下的 ActivityListenerAddOpenTelemetryTracing会自动启用必要的监听器但如果你所在的环境没有这样的框架处理例如纯控制台应用则需要手动注册一个ActivityListener来接收 Activity 事件例如ActivitySource.AddActivityListener(new ActivityListener() { ShouldListenTo _ true, Sample (ref ActivityCreationOptionsActivityContext _) ActivitySamplingResult.AllData, ActivityStarted activity Console.WriteLine(${activity.ParentId}:{activity.Id} - Start), ActivityStopped activity Console.WriteLine(${activity.ParentId}:{activity.Id} - Stop) });这样即使没有完整的 OpenTelemetry Provider也可以观察到 CAP 产生的 Activity 生命周期。CAP 跟踪数据的 Span 结构与语义订阅到诊断事件后DiagnosticListener.cs 会把不同阶段的事件映射为不同命名的 Activity构成一条完整的消息链路阶段事件CapDiagnosticListenerNames生成的 Span 名称ActivityKind消息持久化Before/After/ErrorPublishMessageStoreEvent Persistence: {operation}Internal消息发送Before/After/ErrorPublishCAP/{operation}/PublisherProducer消息消费存储Before/After/ErrorConsumeCAP/{operation}/SubscriberConsumer订阅者调用Before/After/ErrorSubscriberInvokeSubscriber Invoke: {methodName}Internal对应的命名规则定义在 DiagnosticListener.cs操作名前缀为CAP/生产者后缀为/Publisher消费者后缀为/Subscriber。每个 Span 还携带丰富的语义化标签Tag便于在 Zipkin 等后端中检索和定位消息发送与消费阶段会标记messaging.system消息中间件名称、messaging.message.id、messaging.message.body.size、messaging.destination.name、server.address与server.port等DiagnosticListener.cs消费阶段额外标记messaging.operation.type、messaging.client.id、messaging.consumer.group.nameDiagnosticListener.cs订阅者调用阶段标记code.function.name即被调用的订阅方法名DiagnosticListener.cs每个阶段结束都会写入带耗时的 ActivityEvent如cap.send.duration、cap.receive.duration、cap.invoke.duration失败时则通过SetStatus(ActivityStatusCode.Error, ...)与AddException记录异常DiagnosticListener.cs。下图是 CAP 的跟踪数据在 Zipkin 中的一个实际展示整个 Trace 由根 SpanHTTP 处理串起消息持久化、CAP/xxx/Publisher生产者发送、CAP/xxx/Subscriber消费者接收以及Subscriber Invoke订阅者调用等多个嵌套 Span清晰呈现了一次跨进程消息投递的完整耗时分布Context Propagation跨进程传递跟踪上下文在分布式消息场景中生产者与消费者往往位于不同进程要让一条消息的 Trace 在上下游之间保持连续就必须在发送时把跟踪上下文注入消息头在接收时再从中恢复。CAP 通过注入traceparent与baggage两个头来完成这一过程发送时在发布消息前CAP 会把当前 Activity 上下文与 Baggage 通过Propagator.Inject写入消息的 Headers见 DiagnosticListener.cs接收时在消费与订阅者调用前通过Propagator.Extract从消息头还原父级 ActivityContext 与 Baggage并以它作为父上下文创建新的 Span见 DiagnosticListener.cs 与 DiagnosticListener.cs。CAP 使用Propagators.DefaultTextMapPropagator见 DiagnosticListener.cs默认情况下它同时包含TraceContextPropagator与BaggagePropagator。如果你希望关闭 Baggage 的传播可以在客户端程序中显式覆盖默认传播器例如OpenTelemetry.Sdk.SetDefaultTextMapPropagator( new TraceContextPropagator());这样消息头中将只保留traceparent不再传递baggage适用于对传递数据敏感度有要求的场景。小结与延伸阅读通过DotNetCore.CAP.OpenTelemetry包与一行AddCapInstrumentation()CAP 即可把消息生命周期中的持久化、发送、消费与订阅者调用等关键节点自动接入 OpenTelemetry配合 Zipkin 等后端实现跨进程的消息链路追踪其数据源头是 CAP 的 Diagnostics 诊断事件上下文则通过traceparent/baggage头跨进程传播。关于诊断事件与度量指标的更完整说明可进一步阅读 CAP 诊断Diagnostics指南若需了解各存储与传输组件的配置方式可参阅 用户指南目录。赞分享后端消息队列微服务消息路由【免费下载链接】CAPDistributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern项目地址https://gitcode.com/gh_mirrors/ca/CAP点击查看免费下载相关推荐Laya 预测链路追踪实战基于 run_id 与 Hook 的 Span 关联、错误追踪与 OpenTelemetry 集成Laya 预测链路追踪实战基于 run_id 与 Hook 的 Span 关联、错误追踪与 OpenTelemetry 集成 导读 Laya 是一个非自回归的人工智能NLP强化学习minikube 遥测Telemetry实战基于 OpenTelemetry 追踪 minikube start 全链路minikube 遥测Telemetry实战基于 OpenTelemetry 追踪 minikube start 全链路 minikube 内置了基于 O云原生容器编排CLI开发工具微服务链路追踪实战基于nerdctl部署Jaeger与OpenTelemetry全链路监控微服务链路追踪实战基于nerdctl部署Jaeger与OpenTelemetry全链路监控 在微服务架构中全链路监控是排查分布式系统问题的关键。但传统部署方CLI云原生上一篇Shell命令别名导出gh_mirrors/sh1/sh中的别名共享机制下一篇Jukebox模型剪枝通道剪枝与权重稀疏化优化实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考