在分布式系統(tǒng)中，多個(gè)服務(wù)之間的交互涉及到復(fù)雜的網(wǎng)絡(luò)通信和數(shù)據(jù)傳輸，其中每個(gè)服務(wù)可能由不同的團(tuán)隊(duì)或組織負(fù)責(zé)維護(hù)和開(kāi)發(fā)。因此，在這樣的環(huán)境下，當(dāng)一個(gè)請(qǐng)求被發(fā)出并經(jīng)過(guò)多個(gè)服務(wù)的處理后，如果出現(xiàn)了問(wèn)題或錯(cuò)誤，很難快速定位到根因。分布式全鏈路追蹤技術(shù)則可以幫助我們解決這個(gè)問(wèn)題，它能夠跟蹤和記錄請(qǐng)求在系統(tǒng)中的傳輸過(guò)程，并提供詳細(xì)的性能和日志信息，使得開(kāi)發(fā)人員能夠快速診斷和定位問(wèn)題。對(duì)于分布式系統(tǒng)的可靠性、性能和可維護(hù)性起到了非常重要的作用。

RocketMQ?5.0 與分布式全鏈路追蹤

Apache RocketMQ 5.0 版本作為近幾年來(lái)最大的一次迭代，在整個(gè)可觀測(cè)性上也進(jìn)行了諸多改進(jìn)。其中，支持標(biāo)準(zhǔn)化的分布式全鏈路追蹤就是一個(gè)重要的特性。

而由 Google、Microsoft、Uber 和 LightStep 聯(lián)合發(fā)起的 CNCF OpenTelemetry 作為 OpenTracing 和 OpenCensus 的官方繼任者，已經(jīng)成為可觀測(cè)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，RocketMQ 的分布式全鏈路追蹤也圍繞 OpenTelemetry 進(jìn)行展開(kāi)。

分布式鏈路追蹤系統(tǒng)的起源可以追溯到 2007 年 Google 發(fā)布的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》論文。這篇論文詳細(xì)介紹了 Google 內(nèi)部使用的鏈路追蹤系統(tǒng) Dapper，其中使用的 span 概念被廣泛采用，并成為后來(lái)開(kāi)源鏈路追蹤系統(tǒng)中的基礎(chǔ)概念之一。

在 Dapper 中，每個(gè)請(qǐng)求或事務(wù)被追蹤時(shí)都會(huì)創(chuàng)建一個(gè) span，記錄整個(gè)請(qǐng)求或事務(wù)處理過(guò)程中的各個(gè)組件和操作的時(shí)間和狀態(tài)信息。這些 span 可以嵌套，形成一個(gè)樹(shù)形結(jié)構(gòu)，用于表示整個(gè)請(qǐng)求或事務(wù)處理過(guò)程中各個(gè)組件之間的依賴關(guān)系和調(diào)用關(guān)系。后來(lái)，很多開(kāi)源鏈路追蹤系統(tǒng)，如 Zipkin 和 OpenTracing，也采用了類似的 span 概念來(lái)描述分布式系統(tǒng)中的鏈路追蹤信息?，F(xiàn)在，合并了 OpenTracing 和 OpenCensus 的 CNCF OpenTelemetry 自然也一樣采用了 span 概念，并在此基礎(chǔ)上進(jìn)行了進(jìn)一步發(fā)展。

OpenTelemetry 為 messaging 相關(guān)的 span 定義了一組語(yǔ)義約定（semantic convention），旨在制定一套與特定消息系統(tǒng)無(wú)關(guān)的 specification，而 OpenTelmetry 自身的開(kāi)發(fā)其實(shí)也都是由 specification 驅(qū)動(dòng)進(jìn)行展開(kāi)。

Messaging Span 定義

Specifaition 中描述了 messaging span 的拓?fù)潢P(guān)系，包括代表消息發(fā)送、接收和處理的不同 span 之間的父子和鏈接關(guān)系。

關(guān)于具體的定義可以參考：Semantic Conventions of Messaging。對(duì)應(yīng)到 RocketMQ 中，有三種不同的 span：

特別地，默認(rèn)情況下，receive span 是不啟用的。在 receive span 啟用和不啟用的兩種情況下，span 之間的組織關(guān)系是不同的：

在沒(méi)有啟用 receive span 的情況下，process span 會(huì)作為 send span 的 child；而當(dāng) receive span 啟用的情況下，process span 會(huì)作為 receive span 的 child，同時(shí) link 到 send span。

Messaging Attributes 定義

語(yǔ)義約定中規(guī)定了隨 span 攜帶的通用屬性的統(tǒng)一名稱，這包括但不限于：

• messaging.message.id: 消息的唯一標(biāo)識(shí)符。

• messaging.destination：消息發(fā)送的目的地，通常是一個(gè)隊(duì)列或主題名稱。

• messaging.operation：對(duì)消息的操作類型，例如發(fā)送、接收、確認(rèn)等。

具體可以查看?Messaging Attributes?的部分。

特別地，不同的消息系統(tǒng)可能會(huì)有自己特定的行為和屬性，RocketMQ 也和 Kafka 以及 RabbitMQ 一起，將自己特有的屬性推進(jìn)了社區(qū)規(guī)范中，這包括：

快速開(kāi)始

在 OpenTelemetry 中有兩種不同的方式可以為應(yīng)用程序添加可觀測(cè)信息：

• Automatic Instrumentation：無(wú)需編寫任何代碼，只需進(jìn)行簡(jiǎn)單的配置即可自動(dòng)生成可觀測(cè)信息，包括應(yīng)用程序中使用的類庫(kù)和框架，這樣可以更方便地獲取基本的性能和行為數(shù)據(jù)。

• Manual Instrumentation：需要編寫代碼來(lái)創(chuàng)建和管理可觀測(cè)數(shù)據(jù)，并通過(guò) exporter 導(dǎo)出到指定的目標(biāo)。這樣可以更靈活自由地控制用戶想要觀測(cè)的邏輯和功能。

在 Java 類庫(kù)中，前者是一種更為常見(jiàn)的使用形式。RocketMQ 5.0 客戶端的 trace 也依托于 automatic instrumentation 進(jìn)行實(shí)現(xiàn)。在 Java 程序中，automatic instrumentation 的表現(xiàn)形式為掛載 Java agent。在過(guò)去的一年里，我們將基于 RocketMQ 5.0?客戶端的 instrumentation推入了 OpenTelemetry 官方社區(qū)?，F(xiàn)在，只需要在 Java 程序運(yùn)行時(shí)掛載上 OpenTelemetry agent，即可實(shí)現(xiàn)對(duì)應(yīng)用程序透明的分布式全鏈路追蹤。

除此之外，Automatic Instrumentation 和 Manual Instrumentation 并不沖突，Automatic Instrumentation 中所使用的關(guān)鍵對(duì)象會(huì)被注冊(cè)成全局對(duì)象，在 Manual Instrumentation 的使用方式中也可以非常方便的獲取。實(shí)現(xiàn)兩個(gè) Instrumentation 共用一套配置，非常靈活和方便。

首先準(zhǔn)備好 RocketMQ 5.0 Java 客戶端，可以參考?example進(jìn)行消息的收發(fā)。關(guān)于 RocketMQ 5.0 的更多細(xì)節(jié)，歡迎大家參考和關(guān)注?rocketmq-clients 倉(cāng)庫(kù)和?RocketMQ 官網(wǎng)。

然后準(zhǔn)備好 OpenTelemetry agent jar，可以從 OpenTelemetry 官方下載最新 agent，在應(yīng)用程序啟動(dòng)時(shí)增加 -javaagent:yourpath/opentelemetry-javaagent.jar 即可。

可以通過(guò)設(shè)置 OTEL_EXPORTER_OTLP_ENDPOINT 環(huán)境變量來(lái)設(shè)置 OpenTelemetry collector 的接入點(diǎn)。

默認(rèn)情況下，按照 OpenTelemetry 中關(guān)于 messaging 的規(guī)范，只有 send 和 process 的 span 會(huì)被啟用，receive 的 span 是默認(rèn)不啟用的，如果想要啟用 receive span，需要手動(dòng)設(shè)置 -Dotel.instrumentation.messaging.experimental.receive-telemetry.enabled=true。

場(chǎng)景最佳實(shí)踐

目前，主流的云服務(wù)供應(yīng)商都為 OpenTelemetry 提供了良好的支持，阿里云上的 SLS 和 ARMS 兩款可觀測(cè)產(chǎn)品都提供了基于 OpenTelemetry 的分布式全鏈路追蹤服務(wù)。

為了更好地展示分布式全鏈路追蹤的過(guò)程，這里提供了一個(gè)代碼示例：rocketmq-opentelemetry?。在這個(gè)代碼示例中，會(huì)啟動(dòng)三個(gè)不同的進(jìn)程，涉及三種不同類庫(kù)和業(yè)務(wù)邏輯之間的相互調(diào)用，展示了一個(gè)在分布式環(huán)境較復(fù)雜中間件之間進(jìn)行交互的典型案例。

請(qǐng)求首先會(huì)從 gRPC 客戶端發(fā)往 gRPC 服務(wù)端，在 gRPC 服務(wù)端收到請(qǐng)求之后，會(huì)向 RocketMQ 5.0 的 Producer 往服務(wù)端發(fā)送一條消息，然后再回復(fù)對(duì)應(yīng)的 response 給客戶端。

在 RocketMQ 5.0 的 PushConsumer 接受到消息之后，會(huì)在 MessageListener 中使用 Apache HttpClient 往淘寶網(wǎng)發(fā)送一條 GET 請(qǐng)求。

特別地，gRPC 客戶端在發(fā)起具體的調(diào)用是在一個(gè)上游業(yè)務(wù) span 的生命周期之內(nèi)進(jìn)行的，這個(gè) span 我們稱之為 ExampleUpstreamSpan。

RocketMQ 5.0 PushConsumer 在收到消息之后，也會(huì)在 MessageListener 里執(zhí)行其他的業(yè)務(wù)操作，也會(huì)有對(duì)應(yīng)的 span，我們稱之為 ExampleDownstreamSpan。那么默認(rèn)在 receive span 沒(méi)有啟用的情況下，按照開(kāi)始時(shí)間的順序，會(huì)先后存在 7 個(gè) span。分別是：

• ExampleUpstreamSpan。

• gRPC 客戶端請(qǐng)求 span。

• gRPC 服務(wù)端響應(yīng) span。

• RocketMQ 5.0 Producer 的 send span。

• RocketMQ 5.0 Producer 的 process span。

• HTTP 請(qǐng)求 span。

• ExampleDownstreamSpan。

RocketMQ 5.0 對(duì)接 SLS Trace 服務(wù)

首先在阿里云日志服務(wù)中創(chuàng)建 Trace 服務(wù)。然后獲取接入點(diǎn)，項(xiàng)目和實(shí)例名稱等信息，具體可以參考使用 OpenTelemetry 接入 SLS Trace 服務(wù)。

在補(bǔ)充好信息之后完成接入之后，稍等一會(huì)就可以看到對(duì)應(yīng)的 Trace 信息已經(jīng)被上傳到 SLS trace 服務(wù)中：

Trace 服務(wù)其實(shí)是將相關(guān)數(shù)據(jù)存儲(chǔ)到日志中，因此這些數(shù)據(jù)也可以通過(guò) SLS 的 SQL 語(yǔ)法查詢得到。

通過(guò) Trace 數(shù)據(jù)，我們可以很方便知道用戶的操作系統(tǒng)環(huán)境，Java 版本等一系列基礎(chǔ)信息。消息的發(fā)送延時(shí)，失敗與否，消息是否準(zhǔn)時(shí)投遞到了客戶端，以及客戶端本地消費(fèi)耗時(shí)，消費(fèi)失敗與否等一系列有效信息，可以幫助我們十分有效地進(jìn)行問(wèn)題排查。

除此之外，SLS Trace 服務(wù)的 demo 頁(yè)也提供了基于 RocketMQ 5.0 定制的消息中間件大盤，生動(dòng)展示了利用 Trace 數(shù)據(jù)得到的發(fā)送成功率，端到端延時(shí)等一系列指標(biāo)。

• 消息中間件分析 Tab：展示利用 Trace 數(shù)據(jù)得到的包括發(fā)送延時(shí)、發(fā)送成功率、消費(fèi)成功率、端到端延時(shí)在內(nèi)的一系列指標(biāo)。

• 查看 RocketMQ Trace Tab：可以根據(jù)上一步得到的差錯(cuò)長(zhǎng) message id 進(jìn)行進(jìn)一步的細(xì)粒度查詢。

RocketMQ 5.0 對(duì)接應(yīng)用實(shí)時(shí)監(jiān)控服務(wù)（ARMS）

首先進(jìn)入應(yīng)用實(shí)時(shí)監(jiān)控服務(wù) ARMS 控制臺(tái)，點(diǎn)擊接入中心中的 OpenTelemetry，選擇 java 應(yīng)用程序下的自動(dòng)探測(cè)，獲取啟動(dòng)參數(shù)并修改至自己的 java 應(yīng)用程序，具體可以參考通過(guò) OpenTelemetry 接入 ARMS。

配置好參數(shù)之后，啟動(dòng)自己的相關(guān)應(yīng)用程序，稍等一會(huì)兒，就可以在 ARMS Trace Explorer 里看到對(duì)應(yīng)的數(shù)據(jù)了。

還可以查看 span 之間的時(shí)序關(guān)系。

具體地，可以點(diǎn)進(jìn)每個(gè) span 查看詳細(xì)的 attributes/resources/events 等信息。除此之外，ARMS 還支持通過(guò)使用 OpenTelemetry Collector 轉(zhuǎn)發(fā)的形式來(lái)收集應(yīng)用程序的 Trace 數(shù)據(jù)。

趨勢(shì)與思考

隨著現(xiàn)代應(yīng)用程序架構(gòu)的不斷演進(jìn)，可觀測(cè)性的重要性日益凸顯。它不僅可以幫助我們快速發(fā)現(xiàn)和解決系統(tǒng)中的問(wèn)題，還提高應(yīng)用程序的可靠性和性能，同時(shí)也是實(shí)現(xiàn) DevOps 的關(guān)鍵部分。在相關(guān)領(lǐng)域，也陸續(xù)誕生了像 DataDog 和 Dynatrace 這樣的明星公司。

近年來(lái)涌現(xiàn)了一些新興技術(shù)，如 eBPF（Extended Berkeley Packet Filter）和 Service Mesh 也為可觀測(cè)領(lǐng)域提供了一些新的思路：

eBPF 可以在內(nèi)核層面運(yùn)行，通過(guò)動(dòng)態(tài)注入代碼來(lái)監(jiān)控系統(tǒng)的行為。它被廣泛應(yīng)用于實(shí)時(shí)網(wǎng)絡(luò)和系統(tǒng)性能監(jiān)控、安全審計(jì)和調(diào)試等任務(wù)，并且性能影響很小，未來(lái)也可以作為 continuous profiling 的一種選擇。Service Mesh 則通過(guò)在應(yīng)用程序之間注入代理層實(shí)現(xiàn)流量管理、安全和可觀測(cè)性等功能。代理層可以收集和報(bào)告有關(guān)流量的各種指標(biāo)和元數(shù)據(jù)，從而幫助我們了解系統(tǒng)中各個(gè)組件的行為和性能。

Service Mesh 中反映出的技術(shù)趨勢(shì)很大一部分已經(jīng)在 RocketMQ 5.0 proxy 中得到了應(yīng)用，我們也在更多地將可觀測(cè)指標(biāo)往 proxy 進(jìn)行收斂。當(dāng)前的 Trace 鏈路未來(lái)也在考慮和服務(wù)端一起進(jìn)行關(guān)聯(lián)，并打造用戶側(cè)，運(yùn)維側(cè)，跨多應(yīng)用的全方位鏈路追蹤體系。除此之外還可以將 Trace 數(shù)據(jù)與 Metrics 數(shù)據(jù)通過(guò) Exemplars 等技術(shù)進(jìn)行聯(lián)動(dòng)。實(shí)現(xiàn)面到線，線到點(diǎn)的終極排查效果。

在可觀測(cè)領(lǐng)域，RocketMQ 也在不斷探索和摸索更加領(lǐng)先的可觀測(cè)手段，以幫助開(kāi)發(fā)者和客戶更快更省心地發(fā)現(xiàn)系統(tǒng)中的隱患。