唐維堯，白鐵男，李從英，譚海波，金石聲

(貴州省氣象信息中心，貴州 貴陽 550002)

0 引言

消息是消息隊列中最小的概念，是應用程序之間傳遞的信息載體[1]。消息可以非常簡單，比如只包含文本字符串、XML、JSON等；也可以非常復雜，比如圖片、BUFR(Binary universal form for representation of meteorological data)編碼的二進制文件。消息隊列(Message queue，MQ)也可以稱為消息隊列中間件或消息中間件，它是一種利用高效可靠的消息傳輸機制進行與搭建平臺無關的數(shù)據(jù)交流方式。消息隊列傳輸數(shù)據(jù)有著很明顯的優(yōu)點，特別是解耦和異步，前者可以使得上游和下游業(yè)務互不影響，后者大大縮短了各程序的響應時間。目前市場上的消息中間件有很多，比較主流的消息隊列有RabbitMQ、ActiveMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。綜合考慮傳輸效率、持久化消息、綜合技術實現(xiàn)和高并發(fā)等幾個方面因素，中國氣象局選擇了RabbitMQ作為消息中間件部署CTS2，國內氣象通信軟件系統(tǒng)第二版)中的消息傳輸系統(tǒng)[2]。

氣象系統(tǒng)的監(jiān)控與告警有多種實現(xiàn)方式，例如李四維等[3]基于編程語言和數(shù)據(jù)接口實現(xiàn)氣象數(shù)據(jù)傳輸監(jiān)控，但這種方式可擴展性較差，配置較為復雜，推廣應用較為困難。Zabbix是一個企業(yè)級分布式開源監(jiān)控平臺，該平臺能夠監(jiān)控網(wǎng)絡參數(shù)和服務器的健康度、完整性，告警機制靈活，允許用戶為任何事件配置告警，這樣用戶可以快速響應服務器問題。白鐵男等[4]通過搭建Zabbix對貴州省實時氣象數(shù)據(jù)的傳輸進行了有效監(jiān)控，并得到推廣應用。楊立苑等[5]基于Zabbix開發(fā)了江西省氣象云監(jiān)控運維系統(tǒng)，極大提高了運維效率。譚海波等[6]基于Zabbix開發(fā)了貴州省氣象區(qū)域站的全流程監(jiān)控與告警系統(tǒng)，凸顯了Zabbix在顆粒級監(jiān)控的優(yōu)勢。目前國家氣象局推廣使用的監(jiān)控系統(tǒng)“天鏡”可以對RabbitMQ隊列進行監(jiān)控，但只是對隊列的傳輸概況進行簡單監(jiān)控，沒有精細化到數(shù)據(jù)類型和具體隊列，無法滿足當下的監(jiān)控業(yè)務需求。

本文通過開源監(jiān)控平臺設計并實現(xiàn)消息隊列的監(jiān)控和告警，提高消息類氣象數(shù)據(jù)的監(jiān)控精度和氣象數(shù)據(jù)傳輸服務與保障能力，減輕業(yè)務人員的運維壓力。

1 RabbitMQ在CTS2中的應用

RabbitMQ是由erlang語言開發(fā)，基于AMQP(Advanced Message Queue 高級消息隊列協(xié)議)協(xié)議實現(xiàn)的消息隊列。圖1展示的是RabbitMQ的主要構件。

圖1 RabbitMQ的主要構件

圖1中Broker是指消息隊列服務進程，此進程包括2個部分，分別是Exchange和Queue。Exchange是指消息隊列交換機，按一定的規(guī)則將消息路由轉發(fā)到某個隊列，對消息進行過濾；Queue是指消息隊列，存儲消息的隊列，消息到達隊列并通過Channel(通道)轉發(fā)給指定的消費者；Producer：消息生產(chǎn)者，即生產(chǎn)方客戶端，生產(chǎn)方客戶端將消息發(fā)送；Consumer：消息消費者，接收RabbitMQ轉發(fā)的消息。消費者消費是指消費者從消息隊列中取走數(shù)據(jù)的過程。

為了精細化監(jiān)控消息隊列中的關鍵數(shù)據(jù)，需要掌握消息隊列在CTS2中所扮演的角色。目前，除雷達流數(shù)據(jù)，貴州省90%以上的氣象數(shù)據(jù)收發(fā)都需要通過RabbitMQ隊列，其中主要分為文件類數(shù)據(jù)和消息類數(shù)據(jù)，下面將詳細介紹。

1.1 基于Redis調度的消息傳輸

CTS2在現(xiàn)有系統(tǒng)基礎上新增消息傳輸、流傳輸模式，并以Redis任務隊列為核心的交換控制系統(tǒng)替換現(xiàn)有的調度系統(tǒng)，大幅度提升了文件類氣象數(shù)據(jù)實時傳輸效率[2]。任務隊列機制中包含2種角色，一個是任務生產(chǎn)者，一個是任務消費者，而任務隊列是兩者之間的紐帶，圖2是CTS2系統(tǒng)中文件類氣象數(shù)據(jù)的收發(fā)流程。表現(xiàn)在任務隊列中的運行流程如圖3所示。

從圖2和圖3可以看出，任務隊列的整體運行流程是：首先調度程序結合收發(fā)策略中的目錄收集策略、文件名模板策略等生成收集消息，之后發(fā)到交換器X_CTS_BABJ_COLL_TASK中，該交換器綁定了隊列Q_CTS_BABJ_COLL_TASK，因為收集消息就會放到該隊列中，收集進程將會取出消費，消費的過程包括收集分類、原始文件存檔等；之后生成處理消息放到交換器X_CTS_BABJ_PROC_TASK中，該交換器綁定了Q_CTS_BABJ_PROC_TASK，因此處理消息就會放到該隊列中，處理進程將會取出該消息進行消費，消費過程包括文件名檢查、時效檢查、格式檢查等；之后生成分發(fā)消息放到交換器X_CTS_BABJ_DIST_TASK，該交換器綁定了Q_CTS_BABJ_DIST_TASK，因此分發(fā)消息就會放到該隊列中，分發(fā)進程將會取出進行消費，消費的過程包括文件存檔、記錄消息等。整個過程中消息體并沒有包括數(shù)據(jù)，消息以任務的形式流轉，而文件類氣象數(shù)據(jù)是在收集目錄、處理目錄、分發(fā)目錄之間流轉，任務和數(shù)據(jù)之間相互獨立。簡而言之，任務生產(chǎn)者把任務放進隊列，實際就是把任務的關鍵信息存儲起來，這里會用到Redis數(shù)據(jù)存儲工具；而任務消費者不斷地從數(shù)據(jù)庫中取出任務信息，逐一執(zhí)行。而3個進程的處理日志信息被傳到X_CTS_BABJ_COMM_SQL交換器中，該交換器綁定了隊列Q_CTS_BABJ_COMM_SQL。

圖2 CTS2文件類氣象數(shù)據(jù)的收發(fā)流程

圖3 任務隊列的運行流程

1.2 國家站BUFR消息傳輸

目前在貴州省部署了84個國家級站點，臺站將觀測數(shù)據(jù)封裝成消息類型資料再傳輸?shù)绞〖?，省級通過CTS2中的RabbitMQ進行數(shù)據(jù)入庫和上行中國氣象局。圖4是具體的國家站BUFR數(shù)據(jù)傳輸流程，這里主要以小時BUFR數(shù)據(jù)為例。

圖4 國家站BUFR數(shù)據(jù)在RabbitMQ中的傳輸流程

由圖4可知，首先臺站會通過5672端口將BUFR數(shù)據(jù)傳到交換器X.OBS中，X.OBS一方面把數(shù)據(jù)傳到隊列Q.OBS.TO.Monitor后原始文件落盤；一方面?zhèn)鞯疥犃蠶.OBS.TO.BABJ，該隊列將通過Shovel(RabbitMQ的一個插件，可以把源節(jié)點消息發(fā)送到目標節(jié)點)的方式上行中國氣象局；一方面，傳到隊列Q.OBS.TO.Server，之后通過Shovel的方式傳到5680端口的X.OBS，該交換器綁定了隊列Q.OBS.PQC；快速質控程序將會從隊列Q.OBS.PQC中取到數(shù)據(jù)，經(jīng)過處理后把數(shù)據(jù)傳到交換器X.OBS.PQC中。該交換器綁定了4個隊列，分別是Q.OBS.PQC.TO.BABJ(之后Shovel到中國氣象局)、Q.OBS_PQC.CMADAAS(DPC解碼消費)、Q.OBS_PQC_MDOS(MDOS消費)、 Q.OBS.Monitor(文件落盤，是指文件存檔在服務器的緩沖目錄中)、Q.OBS_PQC.TO.BCGZ(之后Shovel到廣州)。

1.3 區(qū)域站BUFR消息傳輸

目前貴州省有3000多個區(qū)域站站點，其中國家級考核站點有1400多個。數(shù)據(jù)從臺站上傳到省信息中心再到中國氣象局的總體流程與國家站幾乎一致，但在RabbitMQ中的具體流程完全不同，圖5給出了區(qū)域站BUFR數(shù)據(jù)傳輸流程。

圖5 區(qū)域站BUFR數(shù)據(jù)在RabbitMQ中的傳輸流程

從圖5可以看出：首先臺站將數(shù)據(jù)傳到SMOS中心站，之后將分為2路進行數(shù)據(jù)傳輸，一路通過5680端口傳到交換器X.OBS_REG_KH，一路通過5672端口傳到交換器X_OBS_REG。X.OBS_REG_KH綁定了Q.OBS_REG_KH_PQC，快速質控程序2將在該隊列中取數(shù)據(jù)，處理之后把數(shù)據(jù)傳到X.OBS_REG_KH.PQC，該隊列綁定了Q.OBS_REG_KH.PQC.TO_BABJ，之后將通過Shovel的方式傳到中國氣象局；而另一路的X_OBS_REG綁定了2個隊列，分別是Q.OBS.Monitor和Q.OBS_REG.TO.Server。前者進行質控前文件落盤，后者通過Shovel的方式傳到5680端口的X.OBS_REG交換器中，該交換器綁定了Q.OBS_REG.PQC，而快速質控程序1將去該隊列中取到數(shù)據(jù)處理后又放到交換器X.OBS.REG.PQC中，該交換器綁定了3個服務隊列，分別是Q.OBS.Monitor(質控后文件落盤)、Q.OBS_REG_PQC.CMADAAS(DPC解碼)、Q.OBS_REG_PQC.TO_BCGZ(之后Shovel到廣州)?？焖儋|控程序1和快速質控程序2并沒有差別，只是部署在不同的服務器中。

從以上可以看出，文件類數(shù)據(jù)和消息類數(shù)據(jù)都通過RabbitMQ隊列來完成數(shù)據(jù)的收發(fā)業(yè)務，因此對關鍵的RabbitMQ隊列進行監(jiān)控就實現(xiàn)了氣象資料傳輸業(yè)務的精準監(jiān)控。

2 消息隊列監(jiān)控與告警系統(tǒng)的設計與實現(xiàn)

對中國氣象局推廣的“天鏡”監(jiān)控系統(tǒng)進行調研發(fā)現(xiàn)，“天鏡”系統(tǒng)僅僅是對隊列的總體情況監(jiān)控，即是RabbitMQ的Overview(總體概況，包括所有隊列)進行監(jiān)控，但無法從Overview監(jiān)控中準確定位氣象數(shù)據(jù)收發(fā)故障的具體原因，這并不能滿足業(yè)務需求。因此本文基于Zabbix這個開源監(jiān)控平臺，搭建了消息隊列的監(jiān)控與告警系統(tǒng)，以此實現(xiàn)CTS2中消息隊列的精細化監(jiān)控，從而達到對氣象數(shù)據(jù)傳輸全流程保障。

2.1 Zabbix部署

Zabbix是開源監(jiān)控平臺，通過官網(wǎng)介紹的搭建方式，就可自主搭建在服務器中。而單機監(jiān)控系統(tǒng)已經(jīng)不能滿足海量數(shù)據(jù)監(jiān)控需要，使用HA集群架構并結合Zabbix平臺非常有必要。本文搭建和部署Zabbix監(jiān)控集群平臺，包括2個數(shù)據(jù)庫節(jié)點、2個服務器節(jié)點和2個前端節(jié)點，以及多個監(jiān)控代理，對于每個集群，配置HA高可用性，設置1個虛擬IP顯示節(jié)點的活動狀態(tài)，如果基本資源連接失敗，節(jié)點將自動切換。圖6展示的是Zabbix高可用集群架構。當有告警發(fā)生時，Zabbix監(jiān)控系統(tǒng)儀表板頁面將有告警彈出并伴有聲音告警。

圖6 Zabbix集群架構

2.2 Zabbix監(jiān)控和觸發(fā)器配置

Zabbix的HTTP代理數(shù)據(jù)采集方式可以不需要腳本，直接通過curl語句的方式獲取隊列信息。從圖7可知，監(jiān)控與告警系統(tǒng)首先是通過HTTP代理獲取信息，之后創(chuàng)建監(jiān)控項，在該監(jiān)控項的基礎上創(chuàng)建儀表盤依賴項，再通過配置依賴項的方式在采集到的信息上剝離出所需要的隊列指標信息，在此基礎上再配置觸發(fā)器告警；在配置觸發(fā)器時，通過count函數(shù)，將未確認的消息數(shù)連續(xù)幾次采集均超標一定數(shù)值作為觸發(fā)條件，這樣就可以避免因為瞬時積壓而造成的頻繁告警。

圖7 Zabbix監(jiān)控與告警配置的技術路線

例如在配置Q_CTS_BABJ_COLL_TASK隊列的監(jiān)控告警中，首先需要在監(jiān)控主機中創(chuàng)建監(jiān)控項，然后在監(jiān)控類型中選擇HTTP代理，監(jiān)控名稱和監(jiān)控鍵值相同即可，這里用的是“CTS_SCH_MQ_QUEUES”可自定義但不能有重復；之后URL的創(chuàng)建方式是“http://用戶名:密碼@IP:端口/api/queues”，這是采集該地址下的所有隊列，然后再通過配置儀表盤依賴項，名稱和鍵值為CTS_SCH_MQ_QUEUES_Q_CTS_BABJ_COLL_TASK_messages_unacknowledged(這里以message_unacknowledged，消息未確認數(shù)監(jiān)控為例)，類型選擇相關項目，主要項就是選擇上述創(chuàng)建的監(jiān)控項“CTS_SCH_MQ_QUEUES”，之后再配置進程，在第一步名稱選擇JSONPath，參數(shù)是“$.[?(@.name==′Q_CTS_BABJ_COLL_TASK')].messages_unacknowledged”。這個參數(shù)的意義就是從上述的監(jiān)控項結果中取出關鍵字′Q.OBS_REG_KH.PQC.TO.BABJ'，之后取出關于該隊列的messages_unacknowledged的實時參數(shù)，從而獲取到了Q_CTS_BABJ_COLL_TASK的messages_unacknowledged實時參數(shù)值，達到監(jiān)控該隊列的消息未確認數(shù)的目的，其他參數(shù)值類似該配置流程；之后再創(chuàng)建告警觸發(fā)器，名稱自定義為“調度隊列COLL積壓”，嚴重性選擇嚴重，問題表現(xiàn)形式為“{ CTS_SCH_MQ_QUEUES_Q_CTS_BABJ_COLL_TASK_messages_unacknowledged.count(3,100,ge)}>=2”，意思是當未確認的消息數(shù)連續(xù)3次采集均超過100將觸發(fā)告警，告警內容為“調度隊列COLL積壓”，恢復表達式為與問題表現(xiàn)形式相反，將“>=”改成“<”即可，當觸發(fā)器告警后，恢復表達式滿足時，即可自動關閉告警并顯示恢復。

2.3 Zabbix拓撲圖

Zabbix可配置拓撲圖，更加直觀地展示傳輸流程，一旦觸發(fā)告警，可從拓撲圖中快速定位故障原因，使得運維更加高效以調度隊列拓撲圖為例(圖8)。調度任務需要重點關注其收集、處理、分發(fā)以及數(shù)據(jù)庫日志收集4個方面的數(shù)據(jù)收發(fā)業(yè)務，與之對應的就是收集隊列Q_CTS_BABJ_COLL_TASK、處理隊列Q_CTS_BABJ_PROC_TASK、分發(fā)隊列Q_CTS_BABJ_DIST_TASK和日志收集隊列Q_CTS_BABJ_COMM_SQL。圖中所顯示的數(shù)值是隊列積壓的關鍵指標：消息未確認數(shù)。對于消息類數(shù)據(jù)的隊列， 國家站和區(qū)域站BUFR也可通過相同的方式在Zabbix中配置拓撲圖來直觀展示其傳輸流程。

圖8 調度Redis隊列的拓撲示意圖

2.4 Zabbix-Grafana展示

Grafana是一個跨平臺的開源的度量分析和可視化工具，可以通過查詢采集到的數(shù)據(jù)進行可視化展示。它最大的特點是展示方式和數(shù)據(jù)源多樣：有快速靈活的客戶端圖表，面板插件有許多不同方式的可視化指標和日志，官方庫中具有豐富的儀表盤插件；可鏈接的數(shù)據(jù)源多達50多種。本研究把Zabbix作為數(shù)據(jù)源，可視化展示Zabbix的監(jiān)控項，達到展示監(jiān)控隊列的目的。圖9是以調度隊列作為樣例，通過加載不同的圖表展示了Overview和每個隊列的關鍵指標，例如ack_rate(消息確認速率)，publish_rate(消息發(fā)布速率)，deliver_rate(消息接收速率)，隊列中的messages(消息總數(shù))，messages_ready(準備發(fā)布的消息數(shù))，messages_unacknowledged(消息未確認數(shù))。

圖9 調度Redis隊列Grafana監(jiān)控展示

3 結論

本文通過梳理2類重要數(shù)據(jù)：文件類和消息類，掌握CTS2中基于消息中間件的分發(fā)流程，設計并實現(xiàn)了消息中間件的監(jiān)控與告警系統(tǒng)，從而提高氣象數(shù)據(jù)傳輸保障能力。其中還實現(xiàn)了Zabbix監(jiān)控拓撲圖和Zabbix-grafana數(shù)據(jù)監(jiān)控展示，自主開發(fā)訂制并構建了一套從監(jiān)控到告警，再到展示的消息隊列傳輸全流程保障系統(tǒng)，實現(xiàn)了消息隊列的精細化監(jiān)控，高效準確地定位氣象數(shù)據(jù)傳輸故障原因，大大減輕了業(yè)務人員的運維壓力。