智能網格天氣預報監控平臺設計研究

何 林，任 杰，吉 慶

(1.陜西省氣象信息中心，陜西 西安 710014；2.秦嶺和黃土高原生態環境氣象重點實驗室，陜西 西安 710014；3.陜西師范大學 計算機科學學院，陜西 西安 710119；4.陜西省氣象臺，陜西 西安 710014)

0 引 言

天氣預報與人們的生產生活息息相關，在交通出行、工農業生產、自然災害防御等方面都發揮著重要作用。傳統天氣預報以縣及以上行政區域為空間范圍，針對未來幾小時到幾天可能發生的天氣狀況進行定性描述，存在時空尺度較大、服務不夠精細和預報準確率較低等諸多問題。近年來，隨著社會經濟的發展及信息化水平的不斷提高，國-省氣象部門基本建成了以時空分辨率更高、要素定量化和多樣化、預報精準、服務貼心為特征的智能網格預報業務體系，為政府部門和公眾提供了全方位、高分辨率、定量定點的精細化氣象要素預報服務。但由于智能網格預報業務流程及功能操作較為復雜，往往一個小環節的故障都會導致整個業務流發生中斷與癱瘓，加之預報員與運維人員存在信息不對稱、故障定位困難等問題，進一步加劇了運維難度。因此實現一體化監控、建立自動化運維體系、保障預報業務系統的穩定運行已成為制約智能網格預報業務發展亟待解決的關鍵問題。

建立滿足業務需求的監控系統是氣象行業信息化支撐能力的最重要體現。近年來，國內外氣象部門紛紛開展了氣象業務領域監控系統的設計研發工作，并取得一定進展。在國外，美國國家環境預報中心(NCEP)的實時數據監測系統(RTDMS)針對觀測數據的數量和時效進行實時監控。歐洲中期天氣預報中心(ECMWF)通過研發觀測告警系統，實現對數據可用性和質量問題的監控。在國內，國家級代表性氣象監控系統如文獻[5]的全國綜合氣象信息共享平臺(CIMISS)的業務監控系統(MCP)，針對氣象觀測數據，從數據的收集分發、加工處理、存儲管理和共享服務等全生命周期進行了監視，并具備監視信息的統計分析和自動告警等功能。文獻[6-7]的綜合氣象觀測系統運行監控平臺(ASOM)則針對國家級地面自動觀測氣象站、探空觀測氣象站、新一代天氣雷達等重點觀測網的設備運行狀態、探測數據質量等進行監控，并改進運行監控綜合評估、監控信息發布等功能。省級監控系統如文獻[8]設計了省級氣象信息發布監控系統，整合現有的預警信息發布手段，實現對一鍵式發布氣象災害預警信息、氣象服務信息、氣象為農信息的全程監控。文獻[9]提出適用于基層臺站、基于云平臺的氣象數據監控服務系統，側重于觀測站數據下載、監控信息獲取、主動告警服務的設計實現。國內氣象業務監控的集大成者是氣象綜合業務實時監控系統(簡稱“天鏡”)，按照“橫向集中、下沉一級、綜合監控”的原則，建立橫縱一體化的氣象綜合業務全流程監控，覆蓋氣象觀測、信息、預報、服務、政務等氣象業務全流程，監控范圍覆蓋業務系統的場地、網絡、服務器、存儲、數據流程、應用狀態等，實現全棧業務的集中告警、綜合監控、運維管理、大屏綜合展示等功能。

該文按照“天鏡”的設計理念，全面梳理智能網格天氣預報業務中的關鍵環節，設計了智能網格預報監控平臺的總體框架及功能模塊。該平臺以數據流向為主線，對銜接緊密的關鍵業務環節和監視對象進行解耦，分別建立監控指標模型，從監視信息的采集、處理、存儲、展示實現分層逐級處理。通過可視化大屏設計，實現分層綜合監視與集中告警，并建立與之聯動的后臺運維信息管理。該平臺滿足運維無紙化、便捷化、規范化、自動化的要求，提高了省級業務運維保障能力。

1 系統設計

1.1 數據流分析

監控平臺圍繞國家級-省級智能網格預報業務流程進行構建。表1分析了智能網格預報業務每個階段的輸入輸出數據對應關系，將抽象的業務流程與可落地的數據產品分離，便于抽取關鍵數據產品，將關鍵業務環節的監視轉換為對輸入輸出數據完整性和時效性的監視。

表1 智能網格天氣預報業務流與數據流的對應關系

1.2 總體架構

監控平臺的總體架構如圖1所示，以數據流為中心屏蔽智能網格預報的業務流程。監視對象包括與業務相關的各類硬件設備、網絡、系統軟件和應用軟件等，適配相應的采集技術，獲取監視源的狀態、指標、事件等監視信息。存儲層匯聚了監控平臺所用到的各類數據資源，包括依托以CIMISS為核心的省級集約化氣象數據環境構建智能網格預報專題庫，如基礎氣象數據、中間產品、預報產品和服務產品等；通過采集工具獲取各類監視對象的指標數據庫和日志事件庫；平臺前端及后端設置面向不同監控對象的閾值、參數及相關元數據的配置信息庫；為提高訪問速度，設計數據緩存庫對熱點信息進行存儲。存儲層與數據處理和應用層進行讀寫交互。業務邏輯層提供各類計算模型和管理組件，對數據進行加工處理，部分加工產品回寫至存儲層，部分直接提供給應用層進行調用。應用層即監控平臺的前臺大屏展示和后臺運維信息管理，通過調用存儲層的統一數據接口獲取相關數據。

圖1 智能網格天氣預報監控平臺架構

1.3 功能設計

包括綜合信息概覽、基礎平臺監視、數據全流程、算法與服務信息、告警配置管理五個功能模塊。

(1)綜合信息概覽。作為系統訪問的入口，綜合展示當前智能網格預報業務中用到的各類氣象基礎數據、預報產品、服務產品的存儲總量及分布，業務整體運行狀況，當前所處業務流程環節、任務狀態，當日業務值班信息，以及各類導航、通知及個性化推薦信息。

(2)基礎平臺監視。對智能網格預報業務中使用的所有服務器、存儲等硬件設備，網絡連通狀態及流量信息、數據庫和消息中間件等支撐軟件的監控。包括查詢單個設備節點狀態，統計某時段內的流量，以及通過可視化組件對查詢和統計結果進行展示。

(3)數據全流程。對智能網格預報業務中各環節輸入和輸出數據產品的應接收總數、實接收數、接收率、應入庫總數、實入庫數、入庫率等以表格方式展示。并可查看接收和入庫詳情，包括每類數據產品記錄列表、每條記錄的接收時間和入庫時間等。

(4)算法與服務信息。針對智能網格預報算法庫里各算法的運行及調度狀況進行監視，包括運行節點、觸發時間、執行是否成功。對預報數據的訪問情況進行統計分析和展示，包括默認和任選時段內的數據調用次數、用戶交互訪問量等。

(5)告警配置管理。面向監控平臺的管理人員，針對不同的監視對象，配置IP地址、監視指標、告警閾值、優先級別。定制告警發布方式，如語音、微信、短信、釘釘，以及相應的告警信息發送對象和范圍。對告警信息進行統計生成報表，對影響業務運行的故障進行登記留痕等。

2 關鍵技術及實現

2.1 數據模型設計

智能網格監控平臺的設計關鍵是對監視信息的采集、存儲、處理及展示。對于每個監視對象的監視指標，首先需要從時間維度記錄相應的監視數值，對其進行建模：

m_data=getValue(m_class,m_object,index1,index2,…,indexN)& timestamp

其中，m_class表示對象類別，m_object表示監視對象，index表示具體指標，對于不同的監視對象，其監視指標可以有多個，timestamp表示監視時間戳。getValue函數表示采用不同采集方式獲取監視數據，將其結果記錄在m_data中。

表2 智能網格預報業務中的主要監視對象及指標

表2對業務監視對象及其主要指標進行了匯總。根據監視指標類數據具有高吞吐量寫入、低延遲讀取、高頻頁面查詢刷新、按時間粒度匯聚等存取特征，選用Cassandra數據庫對指標信息進行存儲，將每一條記錄轉換為鍵值對，數據結構設計如表3所示。

表3 監視指標類數據Cassandra表結構設計與示例

對于每個Columns都有一個時間戳timestamp，即某時刻點記錄的監視值。通過這種方式將指標數據進行持久化，具有很強的靈活性和擴展性，對于不同的監視對象RowKey都可以通過不同時刻timestamp的指標columns記錄其監視值value，并且指標數量column是可以進行靈活增刪，使得不同監視對象的監視指標互不影響。

2.2 監視信息采集技術

針對不同的監視對象及特點，采用C/S架構，監視客戶端“推”或采集服務端“拉”兩種方式實現監視信息的主動推送或被動采集。涉及采集技術包括以下四種。

(1)標準接口。對于數據庫和消息中間件等規范化的系統軟件，一般都提供了類似JDBC連接或消息隊列監聽等標準化的服務接口，采集服務端直接調用客戶端提供的接口抽取信息，然后二次加工后即可采集到相應指標的監視信息。

(2)采集代理。針對基礎硬件平臺監視信息的采集，使用封裝psutil工具的客戶端代理實現。psutil是基于Python語言開發的跨平臺庫，主要應用于系統監控，分析、限制系統資源及進程管理等。通過psutil內置的豐富的函數，能夠快速獲取系統運行的進程和系統利用率(包括CPU、內存、磁盤、網絡)等指標的信息。

(3)日志解析。針對應用軟件和服務信息的監視信息采集，一般采用日志解析方式。其中，日志類型包括結構化存儲的日志數據表、非結構化存儲的標準格式或自定義格式日志文件兩大類。結構化日志數據一般可直連源數據表，并使用SQL語句進行簡單處理后即可實現解析，而非結構化日志則采用Logstash技術進行采集與處理。Logstash是一款輕量級的日志搜集處理框架，可以方便地把分散的、多樣化的日志搜集起來，并進行自定義的轉換處理，然后傳輸到指定的目標位置。Logstash包括Inputs(日志收集)、Filters(日志過濾器)、Outputs(日志轉存)三個階段，形成了一個類似管道的數據流，其中Filter是Logstash管道中間處理的核心組件，包含對多種可插拔的日志解析插件的管理。智能網格預報監控平臺主要采用了Filter中的Grok和Date插件對非結構化日志文件進行處理，將文本格式的字符串，配合正則表達式，轉換成為具體的結構化數據。以下以EC細網格模式資料解碼算法為例，對解碼算法輸出日志進行解析時，日志過濾器的配置示例如下：

filter { #日志過濾器聲明的關鍵字

if [type] == "ec-decode" {

#根據tpye字段來過濾不同的解析規則

grok {

patterns_dir => "～/logstash/mypatterns/"

#自定義匹配規則的存儲路徑

match => {"message" => "%{DECODE_LOG}" }

#對日志按匹配規則的指定格式抽取信息

remove_field => ["message"]

#將無用的原始日志記錄移除

}

date {

match =>

["timestamp","dd/MMM/YYYY:HH:mm:ss Z" ]

#匹配日志中的時間戳

} }}

(4)目錄輪詢。對于日志信息缺失以及極不規范的應用軟件，可轉換為對其輸出數據產品的目錄的間接監視。目錄輪詢軟件采用Quartz開源組件實現，Quartz是一個使用java語言開發的輕量級的任務調度框架。由于需要監視的中間產品和預報產品的目錄較多，且不同目錄的監視頻次存在差別，因此借助Quartz強大的任務調度機制和靈活便捷的配置規則，將眾多目錄的監視轉換為定時觸發任務，在特定時間點對目標目錄下的符合文件名正則表達式的文件總數進行統計，并將結果寫入日志事件數據庫。

此外，為保證以上采集方式得到的多源監視信息的格式和傳輸方式保持一致，采用http RestFul風格的統一接口將json格式的監視信息以post方式向存儲系統提交請求，從而實現監視信息從采集到存儲的過程。

2.3 監視信息處理框架

智能網格預報業務在時間和空間方面存在一定的特征規律，使得某些時段和空間范圍內的監視信息出現陡增。例如，原始數值模式資料一般在每日08及20時次下發比較密集，對應的客觀背景場產品須在每日5:30和15:30預報訂正前生成；市級預報訂正時主要調用本地區責任范圍內的格點數據，邊界及交叉區域的格點數據在訂正是做要素協同，會發生更高頻的數據調用。這些關鍵時段的業務行為使相應的監視對象產生更多的監視信息。為保證關鍵業務時段監視信息的寫入、查詢和分析性能，采用Kafka高吞吐量數據隊列機制和Redis分布式緩存實現對數據的削峰處理和實時緩存。

Kafka是一種高吞吐的分布式發布訂閱消息中間件系統，具有高性能、持久化、多副本備份、橫向擴展能力等優點。為Kafka消息主題topic命名時，包含監視對象、指標等關鍵字。每個主題中的消息體為采集的監視指標或日志事件，生產者即監視信息采集組件向topic里推送消息，消費者從topic中拉取消息進行監視信息入庫、指標計算、統計分析等業務邏輯處理。當處于業務繁忙時段，通過增加topic中的partition數量來進行橫向擴容，而單個parition內的消息始終有序，保證了業務流程不被擾亂。

消費者對監視信息處理的結果先同步到Redis分布式緩存系統中，再寫入對應的目標監視數據庫中。Redis是基于內存、可持久化的日志型、Key-Value數據庫系統，支持豐富的數據類型，并提供多種語言的API。對單節點Redis的Key做一致性哈希，且每個數據分片都采用主從復制結構，實現分布式緩存機制，不但具有讀寫分離的優點，而且保證了高可用性。當運維人員檢索或統計監視信息時，服務端策略為首先從Redis中獲取已過濾的熱點數據，如果命中，則直接在前端頁面進行展示，如果未命中，則按照Key選擇連接對應的目標監視數據庫進行讀取。

2.4 日志事件存儲技術

在網格預報業務環節生成的日志信息包括運行細節信息(detail information，DI)和異常事件信息(event information，EI)。海量日志信息源源不斷寫入，同時前端通過關鍵字進行查詢和分類統計等操作，將對磁盤產生大量I/O讀寫壓力。為更好地滿足上述應用需求，采用ElasticSearch數據庫集群存儲日志事件類的監視數據。

ElasticSearch簡稱ES，是一個分布式可擴展的智能化全文搜索引擎和面向文檔型數據庫，特別適用于快速儲存、實時搜索和分析海量數據的應用場景。ES允許多臺服務器協同工作，每臺服務器運行多個ES實例。單個ES實例稱為一個節點，一組節點構成一個集群，ES去中心化的集群設計方式，將多個分片均衡地分布在集群的所有可用節點上，不會因某個節點的故障而導致集群崩潰。在存儲數據時，ES通過索引所有字段提高查詢速度。索引相當于數據庫，數據表即索引類型，單條記錄稱為文檔，常用JSON作為文檔序列化的格式。使用ES提供的PUT方法建立產品加工DI索引如下所示：

PUT Monitor_log/ #創建DI索引

{ #該索引的分片數為3，副本數為2

"settings": {

"number_of_shards": 3,

"number_of_replicas": 2 },

“mappings”:{

“_DI”:{

#定義DI索引的內部結構

“properties”:{

#定義DI的基本屬性，包括編碼和名稱

“di_codes”:

{“tpye”:“string”}, “di_name”:

{“tpye”:“string” },

#定義DI的具體字段

“fields”:{

“receiver”:“string”,

“sender”:“string”,

“data_type”:“string”,

“source_counts”:“integer”,

“product_counts”: “integer”,

“process_state”:“boolean”,

“record_time”:“date”

}

} } } }

其中，DI的具體字段包括接收系統、發送系統、數據編碼、源數據記錄數、產品記錄數、加工狀態、運行時間等。針對建好的DI索引，插入一條文檔的方法示例如下：

PUTMonitor_log/_DI/1

{

“di_codes”:“FORCAST.DCOEF.DI”,

“di_name”:“交叉取優算法處理詳細信息”，

“fields”{

“receiver”:“降尺度系統”,

“sender”:“背景場系統”,

“data_type”:“F.8299.0001.S001”,

“source_counts”:“384”,

“product_counts”: “16”,

“process_state”:“true”,

“record_time”:“2020-10-28 02:35:12”}

}

EI文檔設計與DI類似，區別在fields中增加了告警級別和響應狀態，不再贅述。

2.5 數據可視化技術

數據可視化的主要目的是通過統計圖形、信息圖形和圖表等方式清晰有效地傳達信息。在智能網格預報監控平臺中的數據可視化包括對氣象業務數據、監視指標、日志事件的可視化。其中，氣象業務數據具有多類型、高維度、弱模式等特點，可在后臺定時繪圖，前端直接加載輪詢圖像產品即可。而監視指標、日志事件等需從時間、空間等維度進行統計整合，并將分析結果以表格及繪圖呈現。該文采用Matplotlib和D3.js進行數據可視化的實現。

Matplotlib是采用Python語言開發的2D繪圖庫，便于將數據進行圖形化，且提供多樣化的格式輸出。Matplotlib提供一套與Matlab語法相近的API，既可用于跨平臺的交互式繪圖，也可作為服務端繪圖組件，設置固定參數后，定時從業務數據庫中讀出數據并生成相應的圖形產品。D3.js全稱是Data-Driven Documents(數據驅動文檔)，是基于數據來操作文檔的JavaScript庫，用于在瀏覽器前端中創建交互式可視化。D3.js采用聲明性編程，支持大型數據集，為線性、分層、網絡和地理數據布置視覺元素，并將數據關聯到html頁面中的元素或元素組。采用Matplotlib結合D3.js的解決方案，滿足對二維氣象數據及監視指標數據常見的時序圖、折線圖、直方圖、餅圖、散點圖、儀表盤、流線圖、熱力圖等，在前端直接繪制和渲染。針對三維標量場氣象數據繪制等值線/面、色斑圖、落區圖、切片圖等，采用Matplotlib庫提供的插值算法進行網格化，并與Basemap相結合，實現氣象GIS圖像的繪制，也可疊加至Web GIS地圖上展示。針對氣象多維數據，采用幾何投影、圖標、像素等多種方法，對其進行映射、投影和變換，實現對雷達、模式資料的降維展示。

3 結束語

智能網格天氣預報監控平臺已在陜西省氣象部門進行了技術實現及推廣應用。該平臺不僅對智能網格預報數據環境中涉及到的地面、高空、雷達、模式等十余類基礎氣象數據，以及網格預報業務中生成的3X3公里客觀背景場、網格實況產品、網格訂正預報、站點預報、線路預報、公共服務產品的接收、制作和存儲狀況進行監視，而且對業務中用到氣象私有云中的30余臺虛擬服務器資源的實時運行狀態、網絡拓撲及流量、應用軟件運行、數據調用和服務信息實現了一體化監控。

平臺上線后，業務人員對智能網格預報業務的整體運行狀況有了更為全面的把控。當異常發生后，平臺能通過多種渠道快速地向值班人員發出告警，大大提高了下一步運行控制和故障處理的提前量，緩解了值班壓力，有效保障了核心預報業務的質量，有助于提供及時、高效的氣象服務。目前，該平臺在陜西省氣象部門運行穩定，已成為全省智能網格預報業務開展的關鍵支撐系統。