> 本文作者：郭雨傑，阿里雲智慧技術專家。

Prometheus 整合的 50 多款雲產品中，RocketMQ 在可觀測方面實現了非常完善的功能，是一個特別具有代表性的雲產品。

## RocketMQ 如何接入 Prometheus

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7d9cfa4105ee4a2cb848ac91b3283f8a~tplv-k3u1fbpfcp-zoom-1.image "1.png")

RocketMQ 誕生於阿里內部的核心電商系統，是業務訊息的首選 MQ 平臺。上圖是 RocketMQ 5.0 的系統全貌，在接入層、核心元件和底層運維方面做了非常大的改進，具有功能多樣、高效能、高可靠、可觀測、易運維等眾多優勢。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8c1288f456c64496b7d3c6e091bb0167~tplv-k3u1fbpfcp-zoom-1.image "2.png")

Metrics、Tracing、Logging 是可觀測能力的三大支柱。

1. Metrics：RocketMQ 以 Prometheus+Grafana 這種在開源領域廣泛使用的產品組合為使用者提供了開箱即用的 Dashboard。指標涵蓋了訊息量、堆積量、各階段耗時等，該大盤結合 RocketMQ 團隊在訊息領域多年的研發和運維經驗打磨的最佳實踐模板，並提供了持續的迭代更新能力。

2. Tracing：RocketMQ 首次引入了 OpenTelemetry tracing 的開源標準，按照訊息的維度，重新組織了抽象的 span 拓撲。

3.  Logging：Logging 方面主要進行了一些客戶端日誌的標準化處理，能夠更簡單方便地利用日誌定位問題。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7e6a4d2db41745e18d961c2b86e12738~tplv-k3u1fbpfcp-zoom-1.image "3.png")

RocketMQ 的所有可觀測性資料都是圍繞一條訊息在生產端、服務端處理、消費階段展開。從訊息的生命週期圖上，可以看到一條訊息從 Producer 開始傳送到 MQ server 接收到的耗時；如果是定時訊息根據 Ready time 可以知道定時的時間；從 Consumer 的角度上看，可以知道訊息從開始拉取到抵達客戶端的網路耗時；從抵達客戶端的時間到開始處理訊息的等待處理資源耗時；從開始處理訊息到最後返回的 ACK 的處理耗時。訊息在生命週期的任何一個階段，都可以清晰地被定義並且被觀測到，這就是 RocketMQ 可觀測的核心理念。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1ab8b6daf5e84a7c865e1a563ea85133~tplv-k3u1fbpfcp-zoom-1.image "4.png")

RocketMQ 團隊貢獻的 RocketMQ exporter 已被 Prometheus 官方的開源 Exporter 生態所收錄，提供了 Broker、Producer、Consumer 各個階段豐富的監控指標。Exporter 基本邏輯是透過在內部啟動多個定時任務週期性地從 MQ 的叢集上拉取資料，然後將資料規範化後透過端點暴露給Prometheus。MQAdminExt 類封裝了 MQAdmin 暴露的各種介面邏輯。從結構上看，RocketMQ 的 Exporter 是站在第三方視角的觀察者角色，而所有的指標來自於 MQ 叢集的內部。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3c7be9302d9047c085b1a32156592b9a~tplv-k3u1fbpfcp-zoom-1.image "5.png")

Prometheus 在應用程式中暴露監控指標的過程需要注意以下兩點：

1. Exporter 部署模式的選擇分為將 Prometheus client 內嵌到應用程式的直接觀測模式以及應用程式之外的獨立 Exporter 模式。直接觀測模式具有主流語言支援、效能更優、免運維的優勢，劣勢為程式碼耦合。Exporter 模式具有解耦合、開源生態豐富的優勢，最大的缺點是需要單獨的運維 Exporter 元件，在雲原生微服務的應用架構模式下需要部署多個 Exporter 對運維帶來不小的負擔。對於部署模式的選擇沒有優劣之分，一般建議對應用程式碼有掌控許可權的條件下，選擇直接觀測模式，對應用程式碼無掌控許可權的條件下選擇 Exporter 模式。

2. 儘量避免指標維度發散而引起的高基數問題。由於 Prometheus 的指標模型擴充套件維度只需要新增一個 label非常的方便，很多使用者將需要的儘可能多的維度都新增到指標中，這就必然會引入一些不可列舉的維度，比如常見的 userid、url、email、ip 等。Prometheus總體的時間線數量按照指標以及維度的組合乘積關係來計算，因此高基數問題不僅帶來了巨大的儲存成本，而且會由於瞬時返回的資料過多，對查詢側帶來不小的效能挑戰，並且嚴重的維度發散使得指標本身失去了統計上的意義。因此，在使用過程中，應儘量避免指標維度發散問題。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2b99787a64184bb9b9087d1674cdca91~tplv-k3u1fbpfcp-zoom-1.image "6.png")

我們在使用 Prometheus Client 時也會遇到高基數問題，尤其是 RocketMQ 的指標，提供了賬號、例項、 topic、 消費者 Group ID 等多個維度的組合使得整體的時間線數量處於一個很高的量級。實踐過程中我們針對 Prometheus 原生的 Client 做了兩點針對性的最佳化，目的是有效地控制 Exporter 的高基數問題帶來的記憶體隱患。

RocketMQ 的生產環境中，需要做到對售賣租戶的客戶級監控。每個客戶的 RocketMQ 資源都按照租戶進行嚴格隔離。如果為每一個租戶部署一套 Exporter ，則會對產品的架構、運維等方面都帶來非常大的挑戰。因此在生產環境中，RocketMQ 選擇了另一種接入 Prometheus 的方式。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/23600b267b154e139706862794422e5d~tplv-k3u1fbpfcp-zoom-1.image "7.png")

RocketMQ 5.0 的架構方面做出了較大的改進。多語言瘦弱客戶端底層統一使用了 gRPC 協議將資料傳送到服務端，同時 MQ server 也拆分為了可拆可合的 CBroker（proxy）和 SBroker 兩個角色。架構變更的同時，RocketMQ 5.0 在客戶端和服務端同時引入了 OpenTelemetry tracing 標準埋點的規範。

### 全鏈路 Tracing

1.  客戶端嵌入了OpenTelemetry Exporter，將 Tracing 的資料批次傳送到 proxy。

2.  proxy 本身作為一個 collector 整合了客戶端上報的以及自身的 tracing 資料。

3.  tracing 的儲存支援使用者自定義 collector，商業版託管儲存，開源版本儲存上報到自己的平臺。

4.  針對訊息的生命週期，重新設計了 span 的拓撲模型。

### 準確多樣的 Metrics

1.  在服務端對收到的 tracing 資料進行二次聚合計算，得到的計算後的指標符合OpenMetrics 規範。

2.  可以無縫地整合到 Prometheus 儲存和 Grafana 的大盤展示。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/53353695d914476b810753387af48a3a~tplv-k3u1fbpfcp-zoom-1.image "8.png")

RocketMQ span 拓撲模型。該拓撲模型針對 Prod、Recv、Await、Proc、ACK/Nack 階段分別做了重新規範化的埋點處理，同時將 OpenTelemetry的 tracing 模型中的 attributes 部分規範提交到 OpenTelemetry specification 標準組織並得到收錄。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1e14a20be1c2400fba0e74b951113dee~tplv-k3u1fbpfcp-zoom-1.image "9.png")

以上的改進使得訊息軌跡功能得到了極大的增強，不僅可以根據訊息的基本資訊查詢相關軌跡，還能對訊息的生命週期的各個階段一目瞭然。點開 trace ID ，還可以看到詳細的追蹤資訊，並且可以關聯看到生產者、消費者以及相關資源，比如機器資訊的展示。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8df67ad6b62e42d4bc6d348fa49aa7dd~tplv-k3u1fbpfcp-zoom-1.image "10.png")

RocketMQ 的指標資料為什麼要接入到 Prometheus ？因為 Prometheus 天然契合了雲原生的架構，在開源領域 Prometheus 處於 metrics 事實規範地位。Prometheus 為雲原生架構而生，與 Kubernetes 天然整合，具有自動發現、多層次採集的能力、強大的生態、通用的多模指標模型、以及強大的 PromQL 的查詢語法等特點。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13ad5ef6fcfa444e94253415f7a5ba40~tplv-k3u1fbpfcp-zoom-1.image "11.png")

RocketMQ 是基於 trace 資料進行二次計算為 metric 來對接 Prometheus 的。前文講到了 RocketMQ 5.0 引入了 OpenTelemetry tracing 埋點，我們將客戶端和服務端上報的 tracing 資料統一儲存到阿里雲日誌系統中，基於 tracing 資料根據多個維度進行二次聚合，產生了符合 Prometheus 指標規範的時序資料。在 ARMS 團隊內部，透過實時 ETL 工具將日誌資料轉化為指標按租戶儲存到 Prometheus 系統中。RocketMQ 控制檯深度整合了 Grafana 的大盤和 Alarm 告警模組，使用者只需要在 RocketMQ 的例項監控頁面中開通 Prometheus 即可一鍵獲取自己名下的大盤和告警資訊。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/44a8598474904a4abbf539be138d2727~tplv-k3u1fbpfcp-zoom-1.image "12.png")

ARMS Prometheus 整合了眾多的雲產品監控指標，針對雲產品的多租需求提供了一套完整的解決方案。阿里雲的雲產品除了需要對產品自身的指標進行監控外，同時需要對產品售賣的租戶指標進行監控。

雲產品針對租戶資源劃分，主要分為租戶獨佔資源模式和租戶共享資源模式。租戶獨佔資源模式具有租戶單獨佔用部署資源，隔離性好的特點，識別指標的租戶資訊只需要打上租戶指標即可；租戶共享資源模式指租戶之間會共享部署資源，識別指標的租戶資訊需要雲產品自行新增租戶資訊。

ARMS Prometheus 監控相對於開源的 Prometheus 採用了採集和儲存分離的架構，採集端具有多租識別和分發能力，儲存端內建了多租能力，租戶之間的資源完全隔離。

ARMS Prometheus 會為每個阿里雲使用者建立一個 Prometheus 雲服務的例項，來儲存使用者對應的阿里雲的雲產品指標，真正地解決了以往監控系統資料分散形成的資料孤島問題，同時為每個雲產品提供了深度定製、開箱即用的大盤和告警能力。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be2a663622894e118fd29d7be8b19d81~tplv-k3u1fbpfcp-zoom-1.image "13.png")

上圖為 RocketMQ 預設整合的 Grafana 大盤示例。大盤提供 Overview 概覽、Topic 訊息傳送、Group ID 訊息消費等細粒度的監控資料支撐。相較於開源實現，該大盤提供了更多更準確的指標資料，同時結合了 RocketMQ 團隊在訊息領域的多年運維經驗打磨的最佳實踐模板，並提供了持續迭代更新的能力。

## RocketMQ可觀測最佳實踐

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b3eac428ca7b42338982f60afe284e40~tplv-k3u1fbpfcp-zoom-1.image "14.png")

單純地關注訊息系統提供的可觀測資料只能發現一部分的問題，在一個真實的微服務系統中，使用者需要關注整個技術棧全域性中的接入層、業務應用、中介軟體、容器、底層 IaaS的可觀測資料才能準確地定位問題。上圖是一個非常典型的訊息系統上下游的應用結構。上游訂單系統傳送訊息，下游庫存系統、營銷系統訂閱訊息，實現上下游的解耦。如何在這樣一個複雜的業務系統中發現問題、解決問題，需要對整個系統的可觀測性做全面梳理。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e5812f799e8141f8836063f60a2da173~tplv-k3u1fbpfcp-zoom-1.image "15.png")

首先需要對系統中的各個組成部分可觀測資料進行收集，Metric、Trace、Log 的三大支柱必不可少。Metric 衡量了應用狀態，透過指標告警可以快速地發現問題；Trace 資料可以做到請求級別的全週期的跟蹤路徑，透過排查呼叫鏈路可以快速地定位問題；Log 資料詳細記錄了系統產生的事件，透過日誌分析可以快速地排查故障。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3fe7e4fd4a344c34a7595a188d1d8be7~tplv-k3u1fbpfcp-zoom-1.image "16.png")

上圖為 ARMS Kubernetes 監控沉澱的診斷經驗。透過在應用的技術棧端到端、自頂向下的全棧關聯方式，為我們在橫向、縱向將可觀測問題診斷定位提供了實踐思路參考。對於跟業務相關的元件而言，需要更多地關注影響使用者體驗的 RED 指標，在資源層應該更多地關注資源飽和度相關的指標。同時需要橫向地關注日誌、事件、呼叫鏈關聯，只有多方位、全視角的可觀測才可以更加清晰地排查定位問題。

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7682be8a33014045aef0c5696680aa09~tplv-k3u1fbpfcp-zoom-1.image "17.png")

上圖為一個訊息堆積場景的例子。

首先需要理解訊息堆積的指標含義。一條訊息在 Producer 傳送後，在訊息佇列中的處理以及 Consumer 消費的三個階段分別處於 Ready、inFlight、Acked 狀態。需要重點關注兩個指標，已就緒訊息量（Ready message）表示已就緒的訊息條數，該訊息量的大小反映了還未被消費的訊息規模，在消費者異常的情況下，就緒訊息的資料量會變多；訊息排隊時間（Queue time）表示最早一條就緒訊息的就緒時間和當前的時間差，該時間大小反映了還未被處理訊息的時間延遲情況，對於時間敏感的業務而言是一個非常重要的度量指標。

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ac6ec4f867444e91a17bf69823158cf8~tplv-k3u1fbpfcp-zoom-1.image "18.png")

訊息堆積的原因主要有兩點，消費端故障或消費能力不足導致，或者上游生產端訊息量過大，下游消費能力不足導致。

對於生產端更應該關注訊息的傳送健康度，可以針對傳送成功率進行告警。出現告警時，需要關注 load、傳送耗時、訊息量等指標，判斷是否有訊息量的突然變化；對於消費端應該關注消費是否及時的消費健康度，可針對就緒訊息的排隊時間進行告警。當出現告警時，需要關聯地關注訊息的處理耗時、消費的成功率、訊息量、load 等相關指標，判斷訊息的訊息量、消費處理的耗時的變化，並查詢是否有 ERROR 日誌、trace 等相關資訊。

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3eda517a0be8410fb130a73c38fb4fda~tplv-k3u1fbpfcp-zoom-1.image "19.png")

使用者可以使用阿里雲 ARMS 產品，能夠更方便快捷地處理以上排查過程。

收到告警資訊之後，透過查詢業務拓撲、異常標註以及業務指標的變化，一鍵地檢視關聯的呼叫鏈資訊，在呼叫鏈上可以獲得業務處理各個階段的處理時長、是否存在異常等相關資訊。呼叫鏈的每個 span 節點可以下鑽實時查詢呼叫堆疊和耗時分佔比，將問題定位到業務程式碼級別。如果使用者接入的日誌中按照 ARMS 規範關聯到呼叫鏈的 traceID ，還可一鍵關聯檢視對應的日誌詳情，最終定位問題的根因。

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1a9c0ea85aa465c8d26a533c794797e~tplv-k3u1fbpfcp-zoom-1.image "20.png")

當問題出現時，除了方便快捷的問題定位過程，還需要針對告警提供相對完善的告警處理和應急響應機制。ARMS 告警為使用者提供了告警配置、告警排班、告警處理的全流程功能，方便客戶建立應急處理、事後覆盤和機制最佳化。

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/703331b8b5444b81afeead7b35a36af5~tplv-k3u1fbpfcp-zoom-1.image "21.png")

同時 ARMS 的智慧告警平臺支援10+監控資料來源的整合以及多渠道資料推送。基於釘釘的 CHARTOPS 讓告警可協作、可追溯、可統計，並且能夠提供異常檢查、智慧降噪等演算法能力，有效減少無效告警，並且可以在告警中基於應用的上下文得到告警的根因分析。

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a5647683b39d4805b30372e2014bcc43~tplv-k3u1fbpfcp-zoom-1.image "22.png")

阿里雲 ARMS 監控從上到下雲涵蓋了使用者的終端、應用、雲服務/三方元件、容器、基礎設施的全方位、立體化、統一監控和統一告警能力，是企業構建一站式可觀測的最佳實踐平臺。

Prometheus 監測 RocketMQ 最佳實踐

相關文章