关于rocketmq:RocketMQ-x-OpenTelemetry-分布式全链路追踪最佳实践

在分布式系统中，多个服务之间的交互波及到简单的网络通信和数据传输，其中每个服务可能由不同的团队或组织负责保护和开发。因而，在这样的环境下，当一个申请被收回并通过多个服务的解决后，如果呈现了问题或谬误，很难疾速定位到根因。分布式全链路追踪技术则能够帮忙咱们解决这个问题，它可能跟踪和记录申请在零碎中的传输过程，并提供具体的性能和日志信息，使得开发人员可能疾速诊断和定位问题。对于分布式系统的可靠性、性能和可维护性起到了十分重要的作用。

RocketMQ 5.0 与分布式全链路追踪

Apache RocketMQ 5.0 版本作为近几年来最大的一次迭代，在整个可观测性上也进行了诸多改良。其中，反对标准化的分布式全链路追踪就是一个重要的个性。

RocketMQ 5.0 可观测

而由 Google、Microsoft、Uber 和 LightStep 联结发动的 CNCF OpenTelemetry 作为 OpenTracing 和 OpenCensus 的官网继任者，曾经成为可观测畛域的事实标准，RocketMQ 的分布式全链路追踪也围绕 OpenTelemetry 进行开展。

分布式链路追踪零碎的起源能够追溯到 2007 年 Google 公布的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[1]论文。这篇论文具体介绍了 Google 外部应用的链路追踪零碎 Dapper，其中应用的 span 概念被宽泛采纳，并成为起初开源链路追踪零碎中的根底概念之一。

Dapper Trace Tree

在 Dapper 中，每个申请或事务被追踪时都会创立一个 span，记录整个申请或事务处理过程中的各个组件和操作的工夫和状态信息。这些 span 能够嵌套，造成一个树形构造，用于示意整个申请或事务处理过程中各个组件之间的依赖关系和调用关系。起初，很多开源链路追踪零碎，如 Zipkin 和 OpenTracing，也采纳了相似的 span 概念来形容分布式系统中的链路追踪信息。当初，合并了 OpenTracing 和 OpenCensus 的 CNCF OpenTelemetry 天然也一样采纳了 span 概念，并在此基础上进行了进一步倒退。

OpenTelemetry 为 messaging 相干的 span 定义了一组语义约定（semantic convention）[2]，旨在制订一套与特定音讯零碎无关的 specification，而 OpenTelmetry 本身的开发其实也都是由 specification 驱动进行开展。

Specification Driven Development

Messaging Span 定义

Specifaition 中形容了 messaging span 的拓扑关系，包含代表音讯发送、接管和解决的不同 span 之间的父子和链接关系。对于具体的定义能够参考：Semantic Conventions of Messaging[3]。对应到 RocketMQ 中，有三种不同的 span：

特地地，默认状况下，receive span 是不启用的。在 receive span 启用和不启用的两种状况下，span 之间的组织关系是不同的：

启用 receive span 前后的 span 关系

在没有启用 receive span 的状况下，process span 会作为 send span 的 child；而当 receive span 启用的状况下，process span 会作为 receive span 的 child，同时 link 到 send span。

Messaging Attributes 定义

语义约定中规定了随 span 携带的通用属性的对立名称，这包含但不限于：

• messaging.message.id: 音讯的惟一标识符。
• messaging.destination：音讯发送的目的地，通常是一个队列或主题名称。
• messaging.operation：对音讯的操作类型，例如发送、接管、确认等。

具体能够查看 Messaging Attributes 的局部[4]。

特地地，不同的音讯零碎可能会有本人特定的行为和属性，RocketMQ 也和 Kafka 以及 RabbitMQ 一起，将本人特有的属性推动了社区标准中[5]，这包含：

疾速开始

在 OpenTelemetry 中有两种不同的形式能够为应用程序增加可观测信息：

• Automatic Instrumentation：无需编写任何代码，只需进行简略的配置即可主动生成可观测信息，包含应用程序中应用的类库和框架，这样能够更不便地获取根本的性能和行为数据。
• Manual Instrumentation：须要编写代码来创立和治理可观测数据，并通过 exporter 导出到指定的指标。这样能够更灵便自在地管制用户想要观测的逻辑和性能。

在 Java 类库中，前者是一种更为常见的应用模式。RocketMQ 5.0 客户端的 trace 也依靠于 automatic instrumentation 进行实现。在 Java 程序中，automatic instrumentation 的表现形式为挂载 Java agent。在过来的一年里，咱们将基于 RocketMQ 5.0 客户端的 instrumentation[6]推入了 OpenTelemetry 官网社区。当初，只须要在 Java 程序运行时挂载上 OpenTelemetry agent，即可实现对应用程序通明的分布式全链路追踪。

除此之外，Automatic Instrumentation 和 Manual Instrumentation 并不抵触，Automatic Instrumentation 中所应用的要害对象会被注册成全局对象，在 Manual Instrumentation 的应用形式中也能够十分不便的获取。实现两个 Instrumentation 共用一套配置，非常灵活和不便。

首先筹备好 RocketMQ 5.0 Java 客户端，能够参考 example[7]进行音讯的收发。对于 RocketMQ 5.0 的更多细节，欢送大家参考和关注 rocketmq-clients 仓库 [8] 和 RocketMQ 官网[9]。

而后筹备好 OpenTelemetry agent jar，能够从 OpenTelemetry 官网下载最新 agent[10]，在应用程序启动时减少 -javaagent:yourpath/opentelemetry-javaagent.jar 即可。

能够通过设置 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量来设置 OpenTelemetry collector 的接入点。默认状况下，依照 OpenTelemetry 中对于 messaging 的标准，只有 send 和 process 的 span 会被启用，receive 的 span 是默认不启用的，如果想要启用 receive span，须要手动设置 -Dotel.instrumentation.messaging.experimental.receive-telemetry.enabled=true。

场景最佳实际

目前，支流的云服务供应商都为 OpenTelemetry 提供了良好的反对，阿里云上的 SLS 和 ARMS 两款可观测产品都提供了基于 OpenTelemetry 的分布式全链路追踪服务。

为了更好地展现分布式全链路追踪的过程，这里提供了一个代码示例：rocketmq-opentelemetry[11]。在这个代码示例中，会启动三个不同的过程，波及三种不同类库和业务逻辑之间的互相调用，展现了一个在分布式环境较简单中间件之间进行交互的典型案例。

申请首先会从 gRPC 客户端发往 gRPC 服务端，在 gRPC 服务端收到申请之后，会向 RocketMQ 5.0 的 Producer 往服务端发送一条音讯，而后再回复对应的 response 给客户端。

在 RocketMQ 5.0 的 PushConsumer 承受到音讯之后，会在 MessageListener 中应用 Apache HttpClient 往淘宝网发送一条 GET 申请。

示例代码调用链路特地地，gRPC 客户端在发动具体的调用是在一个上游业务 span 的生命周期之内进行的，这个 span 咱们称之为 ExampleUpstreamSpan。

RocketMQ 5.0 PushConsumer 在收到音讯之后，也会在 MessageListener 里执行其余的业务操作，也会有对应的 span，咱们称之为 ExampleDownstreamSpan。那么默认在 receive span 没有启用的状况下，依照开始工夫的程序，会先后存在 7 个 span。别离是：

• ExampleUpstreamSpan。
• gRPC 客户端申请 span。
• gRPC 服务端响应 span。
• RocketMQ 5.0 Producer 的 send span。
• RocketMQ 5.0 Producer 的 process span。
• HTTP 申请 span。
• ExampleDownstreamSpan。

RocketMQ 5.0 对接 SLS Trace 服务

首先在阿里云日志服务中创立 Trace 服务。而后获取接入点，我的项目和实例名称等信息，具体能够参考应用 OpenTelemetry 接入 SLS Trace 服务[12]。

在补充好信息之后实现接入之后，稍等一会就能够看到对应的 Trace 信息曾经被上传到 SLS trace 服务中：

SLS Trace 服务分布式全链路展现

Trace 服务其实是将相干数据存储到日志中，因而这些数据也能够通过 SLS 的 SQL 语法查问失去。

通过 Trace 数据，咱们能够很不便晓得用户的操作系统环境，Java 版本等一系列根底信息。音讯的发送延时，失败与否，音讯是否准时投递到了客户端，以及客户端本地生产耗时，生产失败与否等一系列无效信息，能够帮忙咱们非常无效地进行问题排查。

除此之外，SLS Trace 服务的 demo 页也提供了基于 RocketMQ 5.0 定制的消息中间件大盘，活泼展现了利用 Trace 数据失去的发送成功率，端到端延时等一系列指标。

• 消息中间件剖析 Tab[13]：展现利用 Trace 数据失去的包含发送延时、发送成功率、生产成功率、端到端延时在内的一系列指标。
• 查看 RocketMQ Trace Tab[14]：能够依据上一步失去的过错长 message id 进行进一步的细粒度查问。

消息中间件剖析

RocketMQ 5.0 对接利用实时监控服务（ARMS）

首先进入利用实时监控服务 ARMS 控制台，点击接入核心中的 OpenTelemetry，抉择 java 应用程序下的主动探测，获取启动参数并批改至本人的 java 应用程序，具体能够参考通过 OpenTelemetry 接入 ARMS[15]。

配置好参数之后，启动本人的相干应用程序，稍等一会儿，就能够在 ARMS Trace Explorer 里看到对应的数据了。

Trace Explorer

还能够查看 span 之间的时序关系。

ARMS Trace Explorer 分布式全链路追踪展现

具体地，能够点进每个 span 查看具体的 attributes/resources/events 等信息。除此之外，ARMS 还反对通过应用 OpenTelemetry Collector 转发的模式来收集应用程序的 Trace 数据。

趋势与思考

随着古代应用程序架构的一直演进，可观测性的重要性日益凸显。它不仅能够帮忙咱们疾速发现和解决零碎中的问题，还进步应用程序的可靠性和性能，同时也是实现 DevOps 的要害局部。在相干畛域，也陆续诞生了像 DataDog 和 Dynatrace 这样的明星公司。

近年来涌现了一些新兴技术，如 eBPF（Extended Berkeley Packet Filter）和 Service Mesh 也为可观测畛域提供了一些新的思路：

eBPF 能够在内核层面运行，通过动静注入代码来监控零碎的行为。它被广泛应用于实时网络和零碎性能监控、平安审计和调试等工作，并且性能影响很小，将来也能够作为 continuous profiling 的一种抉择。Service Mesh 则通过在应用程序之间注入代理层实现流量治理、平安和可观测性等性能。代理层能够收集和报告无关流量的各种指标和元数据，从而帮忙咱们理解零碎中各个组件的行为和性能。

Service Mesh 中反映出的技术趋势很大一部分曾经在 RocketMQ 5.0 proxy 中失去了利用，咱们也在更多地将可观测指标往 proxy 进行收敛。以后的 Trace 链路将来也在思考和服务端一起进行关联，并打造用户侧，运维侧，跨多利用的全方位链路追踪体系。除此之外还能够将 Trace 数据与 Metrics 数据通过 Exemplars 等技术进行联动。实现面到线，线到点的终极排查成果。

在可观测畛域，RocketMQ 也在一直摸索和摸索更加当先的可观测伎俩，以帮忙开发者和客户更快更省心地发现零碎中的隐患。

相干链接：

[1]《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》https://storage.googleapis.com/pub-tools-public-publication-d…
[2] 一组语义约定（semantic convention）https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md
[3] Semantic Conventions of Messaginghttps://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md
[4] Messaging Attributes 的局部 https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#messaging-attributes
[5] RocketMQ 也和 Kafka 以及 RabbitMQ 一起，将本人特有的属性推动了社区标准中 https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#apache-rocketmq
[6] 基于 RocketMQ 5.0 客户端的 instrumentationhttps://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/rocketmq/rocketmq-client/rocketmq-client-5.0
[7] examplehttps://github.com/apache/rocketmq-clients/tree/master/java/client/src/main/java/org/apache/rocketmq/client/java/example
[8] rocketmq-clients 仓库 https://github.com/apache/rocketmq-clients
[9] RocketMQ 官网 https://rocketmq.apache.org/
[10] 下载最新 agenthttps://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar
[11] rocketmq-opentelemetryhttps://github.com/aaron-ai/rocketmq-opentelemetry
[12] 应用 OpenTelemetry 接入 SLS Trace 服务 https://help.aliyun.com/document_detail/208894.html?spm=a2c4g…
[13] 消息中间件剖析 Tabhttps://1340796328858956.cn-shanghai.fc.aliyuncs.com/2016-08-…
[14] 查看 RocketMQ Trace Tabhttps://1340796328858956.cn-shanghai.fc.aliyuncs.com/2016-08-…
[15] 通过 OpenTelemetry 接入 ARMShttps://help.aliyun.com/document_detail/407604.html

参考链接：

RocketMQ 5.0 客户端：https://github.com/apache/rocketmq-clients

OpenTelemetry Instrumentation for RocketMQ 5.0：https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/rocketmq/rocketmq-client/rocketmq-client-5.0

RocketMQ OpenTelemetry 示例：https://github.com/aaron-ai/rocketmq-opentelemetry

作者简介：艾阳坤，Apache RocketMQ PMC Member/Committer，CNCF OpenTelemetry Member，CNCF Envoy contributor。

原文链接

本文为阿里云原创内容，未经容许不得转载。