Apache RocketMQ 是一個分布式消息和流資料平台，具有低延遲、高性能、高可靠性、萬億級容量和靈活的可擴充性。簡單的來說，它由 Broker 伺服器和用戶端兩部分組成，其中用戶端一個是消息釋出者用戶端 (Producer)，它負責向 Broker 伺服器發送消息；另外一個是消息的消費者用戶端 (Consumer)，多個消費者可以組成一個消費組，來訂閱和拉取消費 Broker 伺服器上存儲的消息。正由于它具有高性能、高可靠性和高實時性的特點，與其他協定元件在MQTT 等各種消息場景中的結合也越來越多，應用也越來越廣泛。為了全方位的監控RocketMQ，Apache RocketMQ開源社群基于Prometheus開發了RocketMQ Exporter。Prometheus具有易于管理，監控服務的内部運作狀态，強大的資料模型，強大的查詢語言PromQL，高效的資料處理，可擴充，易于內建，可視化，開放性等優點，基于RocketMQ Exporter可以很快速的建構出一個能夠監控RocketMQ的監控平台。本次分享将由Apache RocketMQ Committer陳厚道為大家介紹為什麼Prometheus是雲原生時代首選的監控方案？Prometheus的強大的查詢語言PromQL的典型應用場景有哪些？對于Apache RocketMQ分布式消息隊列，需要監控和關注哪些名額等内容。
演講嘉賓簡介：陳厚道，Apache RocketMQ Committer
以下内容根據演講視訊以及PPT整理而成。
觀看回放
https://developer.aliyun.com/live/43210 本次分享主要圍繞以下五個方面：一、Prometheus 簡介
二、幾種主流的消息隊列的比較
三、RocketMQ-Exporter的實作 四、RocketMQ-Exporter的監控訓示和告警訓示
五、RocketMQ-Exporter的使用示例
一、Prometheus 簡介
CNCF基金會中有幾個重點項目，其中一個便是K8S，啟發于Brog系統。Prometheus是CNCF的另一個項目，啟發于BrogMon系統，為Brog系統做監控。在2017年，Prometheus 釋出了2.0版本，提供了全新的時間序列資料庫引擎，大大的提高了資料存儲、資料讀取、資料查詢的效率。同時，Prometheus 2.0還提供了遠端存儲能力，以及對容器的支援。現在，Prometheus已經成為了雲原生時代中主流的監控解決方案。
監控系統基本架構
監控系統大概可以分為幾個子產品，包括資料的采集、資料的存儲、資料的處理、資料的展示以及告警。傳統的資料采集方案是通過push的模型，在機器上安裝agent，讓agent搜集資料，再push到服務端。而Prometheus做的是pull的模型，這也是與傳統監控系統最大的差別，它會向各個目标pull監控資料。需要注意的是并不是所有的資料都适合Prometheus，如短生命周期的應用不适合直接pull。是以，Prometheus提供了Pushgataway的元件。Prometheus的架構的優點是不需要安裝agent，但是需要解決從哪裡拉資料的問題，是以需要具備動态發現目标的能力。在雲原生下，有很多服務注冊，服務發現的解決方案，如K8S、DNS、Kubernates、Consull等，那麼如何才能從服務注冊中心拿到想要監控的目标。Prometheus與這些元件結合起來，就可以從K8S、DNS、Kubernates等拿到注冊的服務。Prometheus支援從服務中心拿到的服務資訊定時的寫到檔案中，還支援從檔案中定時的發現監控目标。Prometheus核心的功能是資料的存儲，目前Prometheus可以達到每秒百萬級的資料采集和存儲，還支援遠端的讀和寫。另外，Prometheus還支援資料的處理，即PromCL，一個類SQL的子產品，具備很強的類聚合能力，提供豐富的算子。此外，Prometheus還支援資料的展現，其中還提供了API clients，支援定制化展示效果。最後還提供告警的功能，Alertmanager，提供對告警做分組、去重、更新等等能力。
Prometheus優勢
Prometheus易于管理，部署非常友善。如果有插件，也可以進行單獨部署。其次，Prometheus易于內建，采用pull模型，其中包含監控名額，Prometheus可以自動的拉取資料，可以友善的監控服務的内部狀态。Prometheus具備強大的資料模型和查詢語言PromQL。Prometheus資料采集和資料存儲的效率是非常高的，還可以将資料寫到遠端的DB中，還提供聯邦叢集能力，完成更大規模的業務監控資料的采集。
資料模型
下圖展示了監控資料調用鍊統計的例子，前面部分是metric，後面是統計的時間timestamp，以及目前的值value。在metric部分還可以增加統計的次元tag，如status，method，handler等，進而使得描述更具體。最後資料模型中還包括類型counterType。
Metrics類型
Metrics類型包含幾種，首先是Counter，隻增不減的計數器，如接口調用量，永遠都是累加的。還有Gauge類型，可增可減的儀表盤，如接口調用耗時、記憶體占用、cpu占用等。Prometheus還提供另外兩種類型，Histogram和Summary，針對接口耗時這個名額，監控其最大，最小及平均值，即使平均耗時很平穩，但不能表示沒有問題。是以，Prometheus可以統計每個區間内的耗時分布情況，如分别統計耗時在0-50ms，100-200ms的請求量，以及在TP50、TP99、TO99.9時的請求量。
PromQL
Prometheus資料存儲能力非常強大，原因是有自己的SQL語言，PromQL，相比SQL更加簡潔。依然以統計調用量為例子，如下圖，括号中是過濾條件，過濾出狀态404、500、501的請求，過濾條件還支援正規表達式。整個語句還支援函數，下圖中将Counter名額通過rate函數轉換為了Gauge名額，代表每分鐘的調用情況。PromQL還支援很多其它函數，如irate、increase、predict_linear、histogram_quantile等。
有了各個次元的名額後，進行轉換後，還希望通過接口名做統計，此時可以通過sum by的方式算出按照接口名每分鐘的調用量。此外，PromQL還支援其它算子，如min、max、avg、bottomk、topk、quantile等，支援更多聚合的功能。
此外，還可以增加聚合的次元，如下圖，除了handler之外，還可以聚合status。如果想知道某個接口1分鐘之内出錯的調用量的比例，則可以通過相除兩個值。但是直接将2個次元和1個次元相除會出現問題，是以需要加ignoring(status)group_left。PromQL還提供其它比對模式，包括一對一、一對多、多對一等比對模式。
二、主流消息隊列比較
基礎項對比
下圖對比了一些主流的消息隊列，包括Kafka、RocketMQ、RabbitMQ等。在成熟度方面，Kafka在日志領域應用更廣泛，RocketMQ和RabbitMQ在業務領域比較成熟。Kafka、RocketMQ是Apache的，RabbitMQ是Mozilla的。但他們在完備性、活躍度等方面都類似。
可用性&可靠性比較
三種消息隊列部署方式都是叢集，叢集的管理Kafka用的是Zookeeper，RocketMQ使用輕量級的Name Server。選主方式，Kafka是競争選主，RocketMQ在4.5版之後基于Raft協定，可以自動切換。是以在可用性方面，RocketMQ是級強的可以做到強一緻，任何節點挂掉後，資料不會丢失。總體來說，可靠性上面三者差不多。
功能對比
由于RocketMQ是專注于業務的，是以在功能性上支援延時消息、事務消息、還支援消息的過濾、消息的查詢、消息回溯、消息失敗重試等功能。是以RocketMQ适合做業務消息的MQ。
三、RocketMQ-Exporter的實作
Prometheus Exporter
Prometheus是pull的模型，提供了兩種內建RocketMQ的方式，一種是直接在業務中上報，但對中間件來說并不合适，如MySQL就不适合直接暴露問題，是以需要Exporter暴露問題，Prometheus再從Exporter拉資料，做采集。在Prometheus官方提供了很多Exporter，如Node Exporter就是讀伺服器名額的監控Exporter，還有容器的cAdvisor，資料庫的MySQL Exporter，Redis Exporter，Kafka Exporter等。基于RockerMQ的Exporter與其它Exporter類似，從終端Server裡将監控名額拿到，暴露給Prometheus。
RocketMQ Exporter
RocketMQ 提供API的功能，MQAdminExt，從RocketMQ cluster中拿到監控的資料，再通過MetricsService做資料規範化，如按照Metrics資料模型，再暴露給Prometheus，從Exporter中拉監控名額資料。（RocketMQ Exporter具體實作代碼可觀看視訊回放）
監控的黃金名額
如果做一個監控系統，那應該監控哪些名額？下圖給出了一些監控的黃金名額。
延遲
第一類是延遲名額。首先是發送消息延遲。其次是消費延遲，具體分為兩種，一種是消費者直接拉取消息的延遲，另一個是消費過程中的業務處理，即消費消息延遲。還需要監控消息堆積量的延遲，如消費消息落後生成消息的時間內插補點。還有主從延遲，發送消息排隊時間，消費消息的排隊時間等。通過對這些延遲名額的監控，可以對系統健康問題進行排查。
通訊量
在通訊量方面，可以監控每秒發送消息的數量和位元組數，每秒消費消息的數量和位元組數，進而監控目前broker的運作狀态，再進行排查。
此外，還需要對錯誤的次數做監控，包括消息失敗的次數，未讀取到消息的次數，觸發broker限流的原因等。
飽和度
MQ實際上是一個存儲系統，是以需要對記憶體、磁盤I/O進行監控。若這些名額發現異常，則表示Broker的性能可能出現了問題。
需要注意的是，其中有一些名額無法通過API拿到，如觸發broker限流的原因，但可以通過RocketMQ的日志拿到。
RocketMQ-Exporter監控名額
輸出的名額可以從以下次元劃分，broker次元包含broker上生産消息tps、消費消息tps。在生産者名額次元，包含topic在broker上的生産tps、topic在broker上的機關時間收到的位元組數、topic在broker上的生産進度。消費者次元包含在broker上消費者消費某個topic的tps、在broker上消費者消費某個topic的進度、在broker上消費者消費某個topic機關時間内消費位元組數、在broker上消費者消費延遲時間，以及消費堆積量。
在消費者用戶端次元，包含消費者1小時内消費失敗的總條數、消費者消費失敗tps、消費者消費成功tps、消費者消費單條消息平均時間、消費者拉取單條消息平均時間、消費者拉取消息tps等。
在broker運作名額次元，最重要的是broker上拉取隊列對頭等待時間、broker上查詢隊列對頭等待時間、broker上發送隊列對頭等待時間。如果等待時間很長，則表示broker性能出現問題，是以需要着重監控。其次是broker上消費者拉取失敗的tps、broker上消費者拉取成功的tps、broker上消費者拉取的tps以及已處理consumeQueue檔案位元組數與已生成commilog檔案的位元組內插補點。
RocketMQ-Exporter告警政策
下圖介紹了RocketMQ-Exporter的告警政策，其中expr是PromQL語言，将叢集做一個聚合，看叢集每秒生産的消息數量，超過10就告警，告警持續3分鐘，具體的告警描述是description那一行。Prometheus将告警消息發給AlertManager，由AlertManager通過微信、郵件、釘釘等方式進行告警的傳達。
RocketMQ-Exporter進階PromQL
下圖展示的是稍微複雜的消息增量的告警。上半部分是sum的是消息生産者進度名額以及消息消費者進度名額，生産者名額減去消費者名額就是所需的消息增量名額。在生産者名額中通過topic次元做聚合，而消費者名額中是通過group和topic兩個次元，屬于一對多的比對模式，是以需要加上group_right來描述這個關系。下半部分語句關注的是生産的消息量，下圖中取了5分鐘的平均值，再按照topic做聚合，此時就計算的是每5分鐘topic的生産值，再乘以5*60=300秒，再檢查值是否大于0。上下兩部分相減就表示生産消息量隻要大于平均每5分鐘的生産的消息總量，則進行告警。可以發現中間加了ignoring(group)group_left，表示前後是多對一的比對模式。
一般情況下，topic需要動态增加的話，可以将告警規則寫到自己的存儲中，寫到資料庫配置中，定時的載入到Prometheus中，通過這樣的方式進行熱更新，進而盡快的發現問
題。
感興趣的同學可以clone RocketMQ-Exporter。具體的步驟：
1）首先啟動NameServer和Broker，驗證RocketMQ和Spring-Boot用戶端，確定RocketMQ服務正确的下載下傳并啟動，大家可以參考RocketMQ主站的快速開始進行操作。確定啟動NameServer和Broker已經正确啟動。
2）其次是編譯RocketMQ-Exporter，通過git clone仔細下載下傳git源碼編譯。
3）正确編譯後進行配置和運作，RocketMQ-Exporter目前有下圖中的幾種運作選項，當然這些選項可以自行在配置檔案中進行更改。運作後自動搜集所需要監控的名額。
4）之後再到Prometheus官方下載下傳位址中下載下傳Prometheus安裝包，Prometheus預設監聽端口号為9090，安裝完後再通過浏覽器通路
http://<伺服器IP位址>，就可以驗證Prometheus是否已成功安裝。
5）Prometheus還可以展示資料，當然目前Prometheus自身的名額展示平台沒有現在流行的展示平台Grafana好，為了更好的展示RocketMQ的名額，可以使用Grafana來展示Prometheus擷取的名額。同樣到官網下載下傳Grafana，為了不與其它進行的使用端口沖突，可以修改conf目錄下的default.ini檔案的監聽端口，将目前Grafana的監聽端口改為5555，然後使用 “./bin/grafana-server web”指令啟動即可。當然Grafana官網可以下載下傳到已為RocketMQ建立好的配置檔案，大家也可以到自行下載下傳。