李從英，支亞京,張淑瑩，李 波，楊遠(yuǎn)恒

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

0 引言

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

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

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

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

數(shù)據(jù)入庫在整個(gè)天擎系統(tǒng)中主要覆蓋消息轉(zhuǎn)發(fā)、消息接收、消息解碼、存儲(chǔ)管理等環(huán)節(jié)。消息隊(duì)列(message queue)即消息中間件，它提供的有保障的消息傳遞、有效的路由、安全性、事務(wù)處理支持以及基于優(yōu)先級(jí)的消息傳遞方式[2]，在氣象通信系統(tǒng)中有著廣泛的應(yīng)用。RabbitMQ由于開源、支持多種語言的客戶端以及適合在分布式系統(tǒng)中消息存儲(chǔ)轉(zhuǎn)發(fā)的場景等特點(diǎn)，非常符合氣象數(shù)據(jù)傳輸業(yè)務(wù)需求[3]。為解決觀測資料傳輸頻次和海量數(shù)據(jù)傳輸問題，選用RabbitMQ消息隊(duì)列技術(shù)進(jìn)行數(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í)際工作中，數(shù)據(jù)解碼入庫往往會(huì)存在一些問題，主要有以下2種情況。一是系統(tǒng)本身特征導(dǎo)致的。由于DPC系統(tǒng)處理程序種類多，且部署在不同的服務(wù)器上，很多處理程序因?yàn)檫M(jìn)程掉線、進(jìn)程假死等原因，造成消息積壓、不能及時(shí)處理，進(jìn)而導(dǎo)致數(shù)據(jù)解碼入庫異常。二是人員修改消息轉(zhuǎn)發(fā)配置導(dǎo)致的。人為修改消息轉(zhuǎn)發(fā)配置出錯(cuò)等原因造成上游收到消息后并沒有轉(zhuǎn)發(fā)到下游的消息隊(duì)列中?，F(xiàn)有傳統(tǒng)的監(jiān)控只能在進(jìn)程是否掉線等粗線條方面進(jìn)行告警，以上2種異常情況都不能通過現(xiàn)有監(jiān)控手段抓取到，只能通過人工巡檢檢查時(shí)發(fā)現(xiàn)，而這時(shí)已經(jīng)嚴(yán)重影響到預(yù)報(bào)和服務(wù)等實(shí)時(shí)業(yè)務(wù)。鑒于以上現(xiàn)狀，我們開展了DPC數(shù)據(jù)處理系統(tǒng)自動(dòng)化運(yùn)維，以此保障數(shù)據(jù)的正常及時(shí)入庫，為天氣預(yù)報(bào)和服務(wù)業(yè)務(wù)提供及時(shí)的基礎(chǔ)數(shù)據(jù)保障。

2 研究方法

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

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

2.1 jQuery技術(shù)簡介

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

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

2.2 自動(dòng)化運(yùn)維的設(shè)計(jì)與實(shí)現(xiàn)

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

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

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

next_seq_id是記錄消息的總數(shù)量，消息有持久化設(shè)置且不會(huì)清零的特征，只要有新的消息來，next_seq_id的值就會(huì)增加。利用上述原理，如果next_seq_id在一定時(shí)間內(nèi)沒有變化，將會(huì)啟動(dòng)報(bào)警，提示運(yùn)維人員檢查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í)設(shè)置的用戶名和密碼；ip是消息服務(wù)器部署地址；2f為隊(duì)列所在的虛擬主機(jī)名；queuesname對(duì)應(yīng)要監(jiān)控隊(duì)列的隊(duì)列名。

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

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

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

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

3 結(jié)論

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