作者简介:艾阳坤,Apache RocketMQ PMC Member/Committer,CNCF OpenTelemetry Member,CNCF Envoy contributor。
在分布式体系中,多个服务之间的交互涉及到杂乱的网络通信和数据传输,其间每个服务或许由不同的团队或组织负责保护和开发。因而,在这样的环境下,当一个恳求被宣布并经过多个服务的处理后,假如呈现了问题或过错,很难快速定位到根因。分布式全链路追寻技能则能够协助咱们处理这个问题,它能够盯梢和记载恳求在体系中的传输进程,并供给详细的功能和日志信息,使得开发人员能够快速确诊和定位问题。对于分布式体系的可靠性、功能和可保护性起到了十分重要的作用。
RocketMQ5.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:
Span | Description |
---|---|
send | 音讯的发送进程。span 以一次发送行为开端,成功或许失利/抛反常完毕。音讯发送的内部重试会被记载成多条 span。 |
receive | 顾客中接纳音讯的长轮询进程,与长轮询的生命周期保持一致。 |
process | 对应 PushConsumer 里 MessageListener 中对音讯的处理进程,span 以进入 MessageListener 为开端,离开 MessageListener 为完毕。 |
特别地,默许情况下,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] **,这包含:
Attribute | Type | Description |
---|---|---|
messaging.rocketmq.namespace | string | RocketMQ 资源命名空间,暂未启用 |
messaging.rocketmq.client_group | string | RocketMQ producer/consumer 负载均衡组,5.0 只对 consumer 收效 |
messaging.rocketmq.client_id | string | 客户端仅有标识符 |
messaging.rocketmq.message.delivery_timestamp | int | 守时音讯守时时刻,只对 5.0 收效 |
messaging.rocketmq.message.delay_time_level | int | 守时音讯守时等级,只对 4.0 收效 |
messaging.rocketmq.message.group | string | 次序音讯分组,只对 5.0 收效 |
messaging.rocketmq.message.type | string | 音讯类型,或许为 normal/fifo/delay/transaction,只对 5.0 收效 |
messaging.rocketmq.message.tag | string | 音讯 tag |
messaging.rocketmq.message.keys | string[] | 音讯 keys,能够有多个 |
messaging.rocketmq.consumption_model | string | 音讯消费模型,或许为 clustering/broadcasting,5.0broadcasting 被废弃 |
快速开端
在 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 也在不断探索和探索更加领先的可观测手法,以协助开发者和客户更快更省心肠发现体系中的危险。
春招发动
阿里云云原生 RocketMQ 研制团队实习生春招敞开啦,欢迎 24 年结业的同学积极投递。 一同参加 Apache 顶级项目 RocketMQ 研制,技能方向有分布式、Log存储、事情驱动、Serverless、音讯计算、可观测等等。是很难得的能够一边做商业化一边一同做开源的团队。团队内部十分重视我们的技能生长,高效作业,从不内卷。
欢迎我们投递简历到我的邮箱:
yangkun.ayk@alibaba-inc.com。
相关链接:
[1]《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》storage.googleapis.com/pub-tools-p…
[2]一组语义约好(semantic convention)
github.com/open-teleme…
[3]Semantic Conventions of Messaging
github.com/open-teleme…
[4]Messaging Attributes的部分
github.com/open-teleme…
[5]RocketMQ 也和 Kafka 以及 RabbitMQ 一同,将自己特有的特点推进了社区标准中
github.com/open-teleme…
[6]根据 RocketMQ 5.0客户端的 instrumentation
github.com/open-teleme…
[7]example
github.com/apache/rock…
[8]rocketmq-clients 库房
github.com/apache/rock…
[9]RocketMQ 官网
rocketmq.apache.org/
[10]下载最新 agent
github.com/open-teleme…
[11]rocketmq-opentelemetry
github.com/aaron-ai/ro…
[12]运用 OpenTelemetry 接入 SLS Trace 服务
help.aliyun.com/document_de…
[13]音讯中间件剖析 Tab
1340796328858956.cn-shanghai.fc.aliyuncs.com/2016-08-15/…
[14]检查 RocketMQ Trace Tab
1340796328858956.cn-shanghai.fc.aliyuncs.com/2016-08-15/…
[15]经过 OpenTelemetry 接入 ARMS
help.aliyun.com/document_de…
参阅链接:
RocketMQ 5.0 客户端:
github.com/apache/rock…
OpenTelemetry Instrumentation for RocketMQ 5.0:
github.com/open-teleme…
RocketMQ OpenTelemetry 示例:
github.com/aaron-ai/ro…
点击此处进入官网了解更多详情