CTS2消息中間件監(jiān)控與告警系統(tǒng)的設(shè)計與實現(xiàn)

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

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

0 引言

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

氣象系統(tǒng)的監(jiān)控與告警有多種實現(xiàn)方式，例如李四維等[3]基于編程語言和數(shù)據(jù)接口實現(xiàn)氣象數(shù)據(jù)傳輸監(jiān)控，但這種方式可擴(kuò)展性較差，配置較為復(fù)雜，推廣應(yīng)用較為困難。Zabbix是一個企業(yè)級分布式開源監(jiān)控平臺，該平臺能夠監(jiān)控網(wǎng)絡(luò)參數(shù)和服務(wù)器的健康度、完整性，告警機(jī)制靈活，允許用戶為任何事件配置告警，這樣用戶可以快速響應(yīng)服務(wù)器問題。白鐵男等[4]通過搭建Zabbix對貴州省實時氣象數(shù)據(jù)的傳輸進(jìn)行了有效監(jiān)控，并得到推廣應(yīng)用。楊立苑等[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隊列進(jìn)行監(jiān)控，但只是對隊列的傳輸概況進(jìn)行簡單監(jiān)控，沒有精細(xì)化到數(shù)據(jù)類型和具體隊列，無法滿足當(dāng)下的監(jiān)控業(yè)務(wù)需求。

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

1 RabbitMQ在CTS2中的應(yīng)用

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

圖1 RabbitMQ的主要構(gòu)件

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

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

1.1 基于Redis調(diào)度的消息傳輸

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

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

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

圖3 任務(wù)隊列的運行流程

1.2 國家站BUFR消息傳輸

目前在貴州省部署了84個國家級站點，臺站將觀測數(shù)據(jù)封裝成消息類型資料再傳輸?shù)绞〖?，省級通過CTS2中的RabbitMQ進(jìn)行數(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ā)送到目標(biāo)節(jié)點)的方式上行中國氣象局；一方面，傳到隊列Q.OBS.TO.Server，之后通過Shovel的方式傳到5680端口的X.OBS，該交換器綁定了隊列Q.OBS.PQC；快速質(zhì)控程序?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(文件落盤，是指文件存檔在服務(wù)器的緩沖目錄中)、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路進(jìn)行數(shù)據(jù)傳輸，一路通過5680端口傳到交換器X.OBS_REG_KH，一路通過5672端口傳到交換器X_OBS_REG。X.OBS_REG_KH綁定了Q.OBS_REG_KH_PQC，快速質(zhì)控程序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。前者進(jìn)行質(zhì)控前文件落盤，后者通過Shovel的方式傳到5680端口的X.OBS_REG交換器中，該交換器綁定了Q.OBS_REG.PQC，而快速質(zhì)控程序1將去該隊列中取到數(shù)據(jù)處理后又放到交換器X.OBS.REG.PQC中，該交換器綁定了3個服務(wù)隊列，分別是Q.OBS.Monitor(質(zhì)控后文件落盤)、Q.OBS_REG_PQC.CMADAAS(DPC解碼)、Q.OBS_REG_PQC.TO_BCGZ(之后Shovel到廣州)?？焖儋|(zhì)控程序1和快速質(zhì)控程序2并沒有差別，只是部署在不同的服務(wù)器中。

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

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

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

2.1 Zabbix部署

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

圖6 Zabbix集群架構(gòu)

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

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

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

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

2.3 Zabbix拓?fù)鋱D

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

圖8 調(diào)度Redis隊列的拓?fù)涫疽鈭D

2.4 Zabbix-Grafana展示

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

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

3 結(jié)論

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