林孔杰，陳云，郭昌松，汪春輝

（福建省氣象服務中心，福建 福州 350100）

福建“知天氣”APP 作為移動公共氣象服務平臺，向公眾展示實時的氣象信息。為了滿足氣象服務的時效性與準確性，針對“知天氣”的監(jiān)控系統(tǒng)必不可少。本文提出一種基于數(shù)據(jù)全流程的移動端監(jiān)控系統(tǒng)。主要是針對“知天氣”APP 產(chǎn)品數(shù)據(jù)全流程進行監(jiān)控，能第一時間追溯數(shù)據(jù)問題所在。

隨著氣象事業(yè)的不斷發(fā)展，氣象觀測數(shù)據(jù)日益龐大，氣象部門的數(shù)據(jù)傳輸以及應用脈絡錯綜復雜，國內(nèi)氣象工作者提出許多監(jiān)控方法。吳貴義等[1]提出一種全鏈路氣象數(shù)據(jù)監(jiān)控系統(tǒng)，解決數(shù)據(jù)異常定位問題。王力等[2]提出基于Message Queuing 消息中間件技術實現(xiàn)一種氣象數(shù)據(jù)采集與監(jiān)控系統(tǒng)。郭昌松等[3]通過模擬客戶端請求“知天氣”的接口數(shù)據(jù)實現(xiàn)一種數(shù)據(jù)主動監(jiān)控系統(tǒng)。目前福建“知天氣”產(chǎn)品數(shù)已達100 多個，日處理數(shù)據(jù)量達萬兆。單純的數(shù)據(jù)主動監(jiān)控已無法滿足運行需求。一旦數(shù)據(jù)出現(xiàn)未及時更新的情況，業(yè)務人員需要對各個生產(chǎn)環(huán)節(jié)逐一排查。各個數(shù)據(jù)系統(tǒng)監(jiān)控環(huán)節(jié)分散且不連續(xù)，出現(xiàn)問題不能及時定位，很難滿足實時業(yè)務對監(jiān)控的需求。

因此，為解決實際問題，應提升數(shù)據(jù)監(jiān)控水平，及時恢復數(shù)據(jù)。本研究提出了全鏈路氣象數(shù)據(jù)監(jiān)控系統(tǒng)的設計思路，能快速定位數(shù)據(jù)更新異常的具體節(jié)點，達到及時、高效的業(yè)務保障能力。

1 “知天氣”產(chǎn)品數(shù)據(jù)特點分析

“知天氣”APP 作為福建省氣象手機客戶端服務系統(tǒng)，匯聚了全省氣象服務數(shù)據(jù)。主要有自動站實時數(shù)據(jù)，逐日預報、逐時預報、旅游氣象預報，天氣綜述、雷達圖、衛(wèi)星云圖、數(shù)值預報、氣象視頻、生活指數(shù)、空氣質(zhì)量等氣象數(shù)據(jù)。系統(tǒng)針對每種數(shù)據(jù)的更新周期特性，將數(shù)據(jù)分四大類，如表1 所示，同時針對更新特性制定相關的采集頻次與監(jiān)控邊界時間（指當前時間與文件時間的最大差值）。

表1 “知天氣”產(chǎn)品數(shù)據(jù)信息表

2 關鍵技術介紹

2.1 移動端框架Uni-app

本文采用了Hbuilder 平臺下的Uni-app 框架。Uni-app 是一個使用vue.js 開發(fā)所有前端應用的框架，是一個整合了小程序開發(fā)框架、APP 跨平臺框架和兼容性強的HTML5 開發(fā)框架。當業(yè)務系統(tǒng)需要在不同的平臺展示時，針對不同的平臺編寫獨有的運行代碼的成本顯然非常高，Uni-app 可以實現(xiàn)一次開發(fā)多端可拓展的技術框架，它可將代碼編譯成支持Android、iOS以及各種小程序等快應用展示平臺，從而降低系統(tǒng)二次開發(fā)的不便性，因此為了能實時、不受平臺限制地監(jiān)控“知天氣”數(shù)據(jù)源，本系統(tǒng)使用Uni-app 框架開發(fā)前端應用，能同時滿足電腦端、移動端以及其他服務平臺的實時數(shù)據(jù)監(jiān)控。本系統(tǒng)使用Vue 框架來進行平臺開發(fā)，主要涉及CSS 和JavaScript 語言的使用。

2.2 接口服務框架Flask

Flask 是一個輕量級的Python 語言Web 微框架。Flask 框架的主要優(yōu)點是核心簡單且易于拓展。它只保留了Web 開發(fā)的核心功能，因此能夠輕松地結合MVC模式進行系統(tǒng)開發(fā)。另外Flask 還具有很強的定制性，能根據(jù)自身業(yè)務需求來添加不同的組件滿足開發(fā)需求。針對Flask 框架這種特點，系統(tǒng)可以使用Python語言快速實現(xiàn)接口服務。并且針對不同數(shù)據(jù)源的監(jiān)控需求定制合理且普適的文本開發(fā)環(huán)境。

3 系統(tǒng)介紹

3.1 基于“知天氣”數(shù)據(jù)全流程監(jiān)控系統(tǒng)設計

福建“知天氣”APP 的數(shù)據(jù)源從生成到具體應用涉及多個環(huán)節(jié)。其中包括氣象數(shù)據(jù)資源庫、公共數(shù)據(jù)支撐平臺、內(nèi)部數(shù)據(jù)源等。本研究介紹的數(shù)據(jù)全流程監(jiān)控系統(tǒng)，其功能是以APP 應用產(chǎn)品為起點，逐級追溯到數(shù)據(jù)源頭的數(shù)據(jù)狀態(tài)。通過數(shù)據(jù)接口、文件狀態(tài)等監(jiān)控方法，實現(xiàn)對全流程數(shù)據(jù)的信息監(jiān)控。其次根據(jù)數(shù)據(jù)采集頻率、文件更新頻率進一步設計各個數(shù)據(jù)階段的監(jiān)控規(guī)則與告警邊界。最后利用Vue 可視技術將監(jiān)控數(shù)據(jù)塊整合成全流程監(jiān)控展示模塊。系統(tǒng)總體設計示意圖1 所示。

圖1 基于“知天氣”數(shù)據(jù)全流程監(jiān)控系統(tǒng)框架圖

3.2 功能設計

數(shù)據(jù)采集層：全流程監(jiān)控系統(tǒng)對各個數(shù)據(jù)源實現(xiàn)分布式數(shù)據(jù)采集。平臺采用APScheduler 調(diào)度框架處理數(shù)據(jù)采集調(diào)度任務，根據(jù)產(chǎn)品類型配置調(diào)度任務的采集頻率。再通過統(tǒng)一監(jiān)視信息采集接口，采用分布式采集匯聚，所需采集文件的信息包含報文名、資料類型、資料時次、生成時間、文件名、數(shù)據(jù)路徑等。由于平臺涉及多個數(shù)據(jù)平臺調(diào)度、跨網(wǎng)協(xié)同等問題。系統(tǒng)監(jiān)控策略為僅判定“知天氣”數(shù)據(jù)更新異常時，方能回溯采集數(shù)據(jù)源的數(shù)據(jù)狀態(tài)，具體策略如圖2 所示。此方法不僅能減少任務調(diào)度頻率，而且能減少監(jiān)控系統(tǒng)對數(shù)據(jù)平臺的負載壓力?？缇W(wǎng)協(xié)同采用“推”“拉”方式。主要針對不同數(shù)據(jù)源的系統(tǒng)以及網(wǎng)段的互通，通過推的方式將采集獲取監(jiān)測數(shù)據(jù)的狀態(tài)、事件等監(jiān)控信息推送至指定的中間服務器。再通過拉取的方式將獲得的數(shù)據(jù)信息同步至目標服務器。系統(tǒng)使用Kafka技術通過將高吞吐量數(shù)據(jù)隊列等數(shù)據(jù)總線方式對數(shù)據(jù)進行數(shù)據(jù)消峰和緩沖；系統(tǒng)讀取Kafka 隊列中緩沖的數(shù)據(jù)，并結合數(shù)據(jù)庫中的現(xiàn)存數(shù)據(jù)，通過SQL 語句將隊列的數(shù)據(jù)加載為Data Frame 形式，最后再利用Data Frame 上的API進行查詢、轉換、計算，最終將生成的結果數(shù)據(jù)寫回存儲層。

圖2 監(jiān)控策略流程圖

告警規(guī)范層：該模塊功能是對數(shù)據(jù)進行分析告警處理、指標計算、統(tǒng)計分析。告警處理是指當系統(tǒng)監(jiān)控到當前文件超過監(jiān)控邊界時間時，系統(tǒng)會將采集到的異常環(huán)節(jié)告知值班人員。但異常處理完畢時需要值班人員登記備案處理情況。存儲相關的處理結果將有利于日后查詢，并且往后出現(xiàn)相關的異?？蔀橹蛋嗳藛T提供參考，具體流程如圖3 所示。指標計算與統(tǒng)計分析2 個模塊是系統(tǒng)將“知天氣”產(chǎn)品到報時間、異常節(jié)點等數(shù)據(jù)做統(tǒng)計分析，形成圖表等進行可視化，為改善監(jiān)控系統(tǒng)提供數(shù)理分析。

圖3 告警處置流程圖

存儲層：采用基于mysql 數(shù)據(jù)庫，文件日志的方式實現(xiàn)較靈活的基礎設施資源配置管理數(shù)據(jù)庫的存儲。

展示層：系統(tǒng)使用Uni-app 框架實現(xiàn)了監(jiān)視系統(tǒng)的數(shù)據(jù)監(jiān)控、告警處置、數(shù)據(jù)查詢等界面展示。介于Uni-app的便利性，系統(tǒng)生成了Android 與iOS 這2 個版本。

3.3 性能測試

為測驗APP 功能模塊的響應性能，在相同網(wǎng)絡環(huán)境下，分別使用性能相近的安卓版手機與蘋果版手機驗證其響應性能。對異常監(jiān)控模塊與產(chǎn)品查詢模塊加載時長進行統(tǒng)計記錄，每個功能模塊均進行10 次測試實驗，記錄模塊加載時間（以加載全部數(shù)據(jù)時間為準）。

打開“異常處理模塊”響應時間對比如圖4（a）所示。測試結果：安卓端打開該模塊的平均響應時長為1.1 s，蘋果端的平均響應時長為1.0 s。打開“產(chǎn)品查詢模塊”響應時間結果如圖4（b）所示。測試結果：安卓端打開該模塊的平均響應時長為1.56 s，蘋果端的平均響應時長為1.61 s。測試證明APP 主要功能模塊響應時長均在1 s 左右，基本滿足用戶體驗。

圖4 測驗APP 功能模塊的響應性能對比情況

4 應用效果

該系統(tǒng)能滿足“知天氣”的日常數(shù)據(jù)保障的需求，系統(tǒng)多次主動告警提醒值班人員數(shù)據(jù)異常，能快速定位異常數(shù)據(jù)節(jié)點，極大提高了“知天氣”數(shù)據(jù)保障的效率。該系統(tǒng)在監(jiān)控方面仍存在不足，監(jiān)控策略配置上無法達到快速發(fā)現(xiàn)故障。后續(xù)將分析數(shù)據(jù)更新時間進行合理統(tǒng)計分析，制定更加精細的數(shù)據(jù)監(jiān)控策略，進一步提高數(shù)據(jù)保障的及時性。