基于消息的氣象數(shù)據(jù)處理系統(tǒng)運維自動化初探

李從英，支亞京,張淑瑩，李 波，楊遠恒

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

0 引言

“數(shù)算一體”的天擎系統(tǒng)具備海量數(shù)據(jù)存儲、全業(yè)務(wù)貫通、數(shù)據(jù)應(yīng)用高效的能力，可直接支撐天氣、氣候、探測、公服、人影等各類氣象應(yīng)用的云化融入。數(shù)據(jù)種類覆蓋全國綜合氣象信息共享平臺(China Integrated Meteorological Information Service System,CIMISS)全數(shù)據(jù)集，數(shù)據(jù)質(zhì)量更高，性能大幅提升，具備直接支撐應(yīng)用云化改造的能力。

天擎系統(tǒng)數(shù)據(jù)處理在技術(shù)和數(shù)據(jù)種類較CIMISS[1]大幅度提升的同時，保留和繼承了CIMISS的大部分標準規(guī)范，是對CIMISS的繼承和發(fā)展。數(shù)據(jù)處理系統(tǒng)(Data Processing Center,DPC)是天擎的重要環(huán)節(jié)，所有的數(shù)據(jù)由CTS(Communications Technology System)收集后，都要經(jīng)過DPC系統(tǒng)的解碼處理，才能及時入庫。因此DPC是保障數(shù)據(jù)及時處理并入庫的核心系統(tǒng)，DPC運維工作至關(guān)重要。

天擎系統(tǒng)建立快速傳輸、實時質(zhì)控和解碼處理的一體化流程；根據(jù)氣象數(shù)據(jù)的存儲和應(yīng)用特點、傳輸方式、數(shù)據(jù)形態(tài)設(shè)計了9種處理框架。天擎DPC系統(tǒng)主要負責(zé)結(jié)構(gòu)化、非結(jié)構(gòu)化以及storm流式等資料數(shù)據(jù)處理，由18臺服務(wù)器支撐，框架多，運維復(fù)雜度高，因此，探究DPC系統(tǒng)自動化運維意義重大。

1 RabbitMQ在DPC系統(tǒng)中的應(yīng)用

數(shù)據(jù)入庫在整個天擎系統(tǒng)中主要覆蓋消息轉(zhuǎn)發(fā)、消息接收、消息解碼、存儲管理等環(huán)節(jié)。消息隊列(message queue)即消息中間件，它提供的有保障的消息傳遞、有效的路由、安全性、事務(wù)處理支持以及基于優(yōu)先級的消息傳遞方式[2]，在氣象通信系統(tǒng)中有著廣泛的應(yīng)用。RabbitMQ由于開源、支持多種語言的客戶端以及適合在分布式系統(tǒng)中消息存儲轉(zhuǎn)發(fā)的場景等特點，非常符合氣象數(shù)據(jù)傳輸業(yè)務(wù)需求[3]。為解決觀測資料傳輸頻次和海量數(shù)據(jù)傳輸問題，選用RabbitMQ消息隊列技術(shù)進行數(shù)據(jù)傳輸[4]?，F(xiàn)有數(shù)據(jù)處理流程為：CTS[5]通過FTP把數(shù)據(jù)文件推送到數(shù)據(jù)交換共享目錄，發(fā)送通知消息，原始消息發(fā)送至RABBIT5671端口，將拆分后的單條消息發(fā)送至RABBIT5672端口，后續(xù)推送給DPC處理(圖1)。

圖1 數(shù)據(jù)處理流程

在實際工作中，數(shù)據(jù)解碼入庫往往會存在一些問題，主要有以下2種情況。一是系統(tǒng)本身特征導(dǎo)致的。由于DPC系統(tǒng)處理程序種類多，且部署在不同的服務(wù)器上，很多處理程序因為進程掉線、進程假死等原因，造成消息積壓、不能及時處理，進而導(dǎo)致數(shù)據(jù)解碼入庫異常。二是人員修改消息轉(zhuǎn)發(fā)配置導(dǎo)致的。人為修改消息轉(zhuǎn)發(fā)配置出錯等原因造成上游收到消息后并沒有轉(zhuǎn)發(fā)到下游的消息隊列中。現(xiàn)有傳統(tǒng)的監(jiān)控只能在進程是否掉線等粗線條方面進行告警，以上2種異常情況都不能通過現(xiàn)有監(jiān)控手段抓取到，只能通過人工巡檢檢查時發(fā)現(xiàn)，而這時已經(jīng)嚴重影響到預(yù)報和服務(wù)等實時業(yè)務(wù)。鑒于以上現(xiàn)狀，我們開展了DPC數(shù)據(jù)處理系統(tǒng)自動化運維，以此保障數(shù)據(jù)的正常及時入庫，為天氣預(yù)報和服務(wù)業(yè)務(wù)提供及時的基礎(chǔ)數(shù)據(jù)保障。

2 研究方法

隊列(Queue)是RabbitMQ的內(nèi)部對象，用于存儲消息隊列，并將它們轉(zhuǎn)發(fā)給消費者[6]，它是消息的容器，也是消息的終點。消息一直在隊列里等待消費者將其取走。根據(jù)消息是積壓還是長時間沒有接收到2種情況，我們需要獲取消息的具體數(shù)量。由于RabbitMQ的消息內(nèi)容可以處理成嚴格的JSON格式數(shù)據(jù)，然后從中提取關(guān)心的字段，以達到監(jiān)控的目的。本文首次引進了jQuery技術(shù)來獲取RabbitMQ消息隊列相關(guān)詳細信息，并利用這些信息，可以更好地監(jiān)控消息隊列。

RabbitMQ消息的持久化[7]設(shè)置，使得在消息轉(zhuǎn)發(fā)服務(wù)重啟之后，已經(jīng)存入磁盤的消息也會存在。也就是說，在消息沒有被消費者消費的情況下，消息會一直存在。利用消息的持久化，根據(jù)具體消息隊列messages字段，可以獲得消息數(shù)量。根據(jù)Queue隊列的字段next_seq_id沒有持久化設(shè)置，來判定是否存在長期沒有收到消息。

2.1 jQuery技術(shù)簡介

jQuery[8]是一款在Linux系統(tǒng)操作中輕量級且靈活的處理JSON數(shù)據(jù)的工具，它可以接受標準輸入，命令管道或者文件中的JSON數(shù)據(jù)，經(jīng)過一系列的過濾器(filters)和表達式的轉(zhuǎn)換后，形成我們需要的數(shù)據(jù)結(jié)構(gòu)并標準輸出。這種特性使我們能很容易在Shell腳本中調(diào)用它，將數(shù)據(jù)轉(zhuǎn)換成理想格式。

要使用jQuery技術(shù)來處理消息，首先需要在Linux服務(wù)器上安裝jQuery軟件，本項目中使用的是jq-1.5版本。由于是在服務(wù)器內(nèi)部使用，可以直接在github上下載，下載后將安裝文件包上傳服務(wù)器解壓縮部署即可。如果服務(wù)器可以連接外網(wǎng)，可以在部署的Linux服務(wù)器上通過命令yum install jq來安裝。

2.2 自動化運維的設(shè)計與實現(xiàn)

消息中Messages字段是記錄消息數(shù)量，可以通過以下命令獲取消息數(shù)量：

curl --silent -u usernm:passwd "http://ip:15672/api/queues/%2f/queuesname"|jq ".messages"

設(shè)置messages大于一定數(shù)量時，將對應(yīng)隊列的名稱記錄到日志中，并自動到DPC處理服務(wù)器上找到對應(yīng)的處理程序，將其重新啟動。

next_seq_id是記錄消息的總數(shù)量，消息有持久化設(shè)置且不會清零的特征，只要有新的消息來，next_seq_id的值就會增加。利用上述原理，如果next_seq_id在一定時間內(nèi)沒有變化，將會啟動報警，提示運維人員檢查RabbitMQ沒有收到消息的具體原因?？赏ㄟ^下面的命令行獲取next_seq_id值:

curl --silent -u usernm:passwd "http://ip:15672/api/queues/%2f/queuesname"|jq ".backing_queue_status.next_seq_id"

其中usernm、passwd分別是安裝RabbitMQ時設(shè)置的用戶名和密碼；ip是消息服務(wù)器部署地址；2f為隊列所在的虛擬主機名；queuesname對應(yīng)要監(jiān)控隊列的隊列名。

2.2.1 消息積壓時的處理 消息積壓但處理程序沒有報錯的情況下，說明處理程序雖然顯示在線，但是實際并沒有工作，程序處于假死狀態(tài)，現(xiàn)有監(jiān)控?zé)o法檢測。因此程序代碼設(shè)定這種情況下，自動到DPC處理服務(wù)器上找到對應(yīng)的處理程序，將其重新啟動。

通過程序判斷，當messages大于10時,監(jiān)控程序會自動到處理程序所在服務(wù)器上重新啟動處理程序,messages的值可以根據(jù)實際需求設(shè)置。由于自動處理腳本是對幾千個隊列的監(jiān)測，不能在某個處理程序重啟之后就停止整個腳本的執(zhí)行，積壓的消息不能迅速處理完，可能會出現(xiàn)多次重新啟動同一個程序的情況，因此在腳本中設(shè)置重新啟動程序后休眠20 s,以給處理程序更多的時間處理積壓的消息。當messages值小于10時，等待程序處理消息入庫即可。結(jié)構(gòu)化資料積壓時，腳本會自動到DPC14和DPC15上去重新啟動對應(yīng)結(jié)構(gòu)化數(shù)據(jù)解碼程序；非結(jié)構(gòu)化資料積壓時，腳本會自動到DPC04和DPC05上去重新啟動對應(yīng)非結(jié)構(gòu)化數(shù)據(jù)解碼程序；半結(jié)構(gòu)化資料積壓時，腳本會自動到DPC06或DPC07上去重新啟動對應(yīng)半結(jié)構(gòu)化數(shù)據(jù)解碼程序，需要注意的是DPC06和DPC07服務(wù)器上處理的是不同資料的半結(jié)構(gòu)化數(shù)據(jù)；對于一些省內(nèi)自有資料，本省將解碼程序部署在DPC18服務(wù)器上。在自動化運維處理過程中，消息積壓的隊列名稱、積壓數(shù)量以及處理過程都將寫入日志，方便對頻繁出現(xiàn)問題的資料進行原因分析。程序核心代碼protect_messages函數(shù)如圖2所示。

圖2 核心代碼

通過以上代碼調(diào)用protect_messages，并給其傳參"AGME_PQC_E.0001.0007.R001_001""DPC14" "DPC15""/space/cmadaas/dpc/CMADAAS_DPC_DECODE/exec""E.0001.0007.R001.sh"，再通過定時任務(wù)來設(shè)定監(jiān)控頻率，或通過命令守護監(jiān)控程序一直處于工作狀態(tài)。

其中，“AGME_PQC_E.0001.0007.R001_001”表示待監(jiān)控的隊列名稱，“DPC14,DPC15”表示對應(yīng)處理程序所在的服務(wù)器名稱或處理隊列數(shù)據(jù)的程序所在服務(wù)器名稱，“/space/cmadaas/dpc/CMADAAS_DPC_DECODE/exec”表示處理程序所在服務(wù)器上的路徑，“E.0001.0007.R001.sh”表示處理程序名稱。如需要監(jiān)控多個消息隊列，添加多個調(diào)用命令語句即可。

2.2.2 長時間沒有收到消息的處理 由于長時間沒有收到消息的情況，不能通過消息積壓或者程序不在線等方式處理，只有人工巡檢才能發(fā)現(xiàn)，因此目前只能通過告警的方式，第一時間通知值班員人工查找原因，以此減少影響時間。本文通過腳本獲取next_seq_id值后，將該機制引入了Zabbix[9-10]的監(jiān)控[11]告警模塊。將獲取next_seq_id值的腳本文件部署到相應(yīng)Linux服務(wù)器后，通過在Zabbix調(diào)用腳本，設(shè)置監(jiān)控項中abschang()函數(shù)，當監(jiān)控的當前時次消息隊列next_seq_id值和上個時次的值之差為零時，就會被抓取告警反饋給運維人員。

3 結(jié)論

本文基于消息粒度對數(shù)據(jù)消息進行監(jiān)控，在消息積壓的情況下，放棄傳統(tǒng)只告警的監(jiān)控這一手段，采用自動重啟解碼入庫程序，保障基礎(chǔ)數(shù)據(jù)及時入庫，再將處理流程寫入日志，供后期原因分析使用。同時對監(jiān)測長時間沒有收到消息的情況，能及時提醒運維人員，輔助縮短排除故障的時間。實現(xiàn)了DPC處理程序不工作卻不能及時發(fā)現(xiàn)并直接處理故障，保障數(shù)據(jù)及時入庫，減輕了運維人員的工作壓力，提高了工作效率，解決了2種常見故障的監(jiān)控難點。