基于“知天氣”APP 數據全流程的移動端監控系統設計

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

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

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

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

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

1 “知天氣”產品數據特點分析

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

表1 “知天氣”產品數據信息表

2 關鍵技術介紹

2.1 移動端框架Uni-app

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

2.2 接口服務框架Flask

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

3 系統介紹

3.1 基于“知天氣”數據全流程監控系統設計

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

圖1 基于“知天氣”數據全流程監控系統框架圖

3.2 功能設計

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

圖2 監控策略流程圖

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

圖3 告警處置流程圖

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

展示層：系統使用Uni-app 框架實現了監視系統的數據監控、告警處置、數據查詢等界面展示。介于Uni-app的便利性，系統生成了Android 與iOS 這2 個版本。

3.3 性能測試

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

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

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

4 應用效果

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