適配金融業的應用監控標準化演進之路

　　 引言

　　應用監控是整個監控體系的重要組成部分，面對各個應用系統之間的差異性和複雜性特點，如何全面有效的實施應用監控是應用運維人員和監控管理員共同面臨的難題。G行透過多年的實踐證明，應用監控標準化是解決複雜IT環境下應用系統有效監控的一柄利劍，也是實現監控數字化和智慧化的基礎。G行從監控標準化方法論、監控標準化模型、監控物件模型、指標定義及接入規範等多個層面進行探索，有效促進應用監控工作在組織層面的融合和打通，確保“三早”原則的落地執行，保障了應用系統平穩執行。本文對G行應用監控標準化演進之路進行了回顧和介紹。

　　 一、應用監控標準化的內容和意義

　　1. 應用系統的定義

　　應用系統一般由計算機硬體系統、系統軟體、應用軟體組成。硬體系統和作業系統、資料庫、中介軟體等軟體系統的標準化程度較高，具有相對通用的監控指標和監控手段。應用軟體基於通用的開發語言和開發框架，編寫應用程式滿足不同的業務需求，具有差異性和複雜性，需要建立統一的監控標準變不確定為確定，保障應用系統業務連續性。因此應用監控標準化的管理物件主要是應用軟體。

　　2. 應用監控標準化內容

　　標準化，實質上就是為標準制定、釋出和實施過程而進行的一切活動。應用監控標準化重點是Metric監控相關的指標集、監控物件、監控工具等標準模型以及由此產生的閉環和量化管理活動。對於應用監控中可能涉及到的日誌和Tracing規範，有單獨的技術標準進行闡述，不包含在本次監控標準化範圍內。

　　3. 應用監控標準化的意義

　　確保“三早”原則落地：透過部署標準化的監控指標體系，全面掌控應用系統執行狀態，對於生產故障的發現，確保“監控工具早於運維人員、科技部門早於業務部門、銀行早於客戶”的“三早”原則的有效落地。

　　提升監控管理水平：沉澱和固化運維經驗，將運維工作中積累的監控手段歸納總結後進行組織級推广部署，從全域性角度提升監控管理水平。

　　組織內監控工作融合：透過監控標準化中的指標接入規範、指標測試規範、應用監控策略部署規範以及生產事件跟蹤機制，將監控工作前移至應用開發和測試環節，形成管理閉環。

　　 二、傳統環境應用監控標準化

　　監控系統建立之初一切都是從零開始，每個應用系統都是單獨進行對接，單獨梳理監控指標、監控策略，部署監控後再根據執行情況進行調整。隨著監控系統不斷完善，接入的應用也越來越多，應用型別五花八門，依賴人工經驗單打獨鬥的方式已經捉襟見肘，具體表現在：

　　指標不明確：每個型別的應用應該有什麼樣的監控指標不明確。

　　策略不明確：每個指標需要如何設定閾值、報警級別不明確。

　　介面不明確：指標需要採用哪種介面、如何接入監控系統不明確。

　　現狀不明確：應用的監控策略實際應用情況如何，這些問題在過去都要依賴手工查詢核實，很難快速回答。

　　為了全面提升應用監控覆蓋率，規範應用監控工藝，提升監控實施效率，迫切需要進行應用監控標準化。

　　1. 應用監控標準化模型　　

圖1 監控標準化模型

　　監控物件：從監控角度需要關注其狀態和效能指標的應用物件。

　　監控指標：用來識別監控物件狀態的相關資料。

　　監控策略：用來度量和判斷監控指標優劣的標準。

　　監控工具：實現從應用監控物件上採集監控指標所採用的技術手段，是監控策略執行的載體。

　　監控規則：監控團隊參考各專業團隊日常運維經驗結合業內優秀實踐總結的監控物件和監控策略的對應規則，用於指導監控策略的部署和對策略執行情況進行事後審計。

　　2. 應用監控物件模型

　　監控物件標準化：除了常規的作業系統、資料庫、中介軟體外，以監控視角對一個應用服務的元件進行拆分和建模。　　

圖2 應用監控物件模型圖

　　3. 主要應用監控元件和指標

　　①基礎環境層

　　網路

　　TCP長連線監控：該指標主要用於對Established狀態的TCP長連線進行監控。一般透過固定埠號作為篩選條件統計連線數量，同時可對該連線的緩衝區佇列深度進行監控，以此發現網路連線中斷或應用處理瓶頸的異常。

　　檔案

　　產生異常檔案：該指標主要用於對應用程式是否產生錯誤檔案或未處理檔案進行監控。C語言應用常見錯誤檔案為bin目錄下產生coredump，或應用程式自定義生成的.err檔案。此外對於應用目錄下超時未處理的檔案，也可視同為發現異常檔案而需要監控和報警。

　　缺失關鍵檔案：該指標主要用於對應用目錄下的資料檔案存在性進行監控，通常結合時間段條件進行綜合判斷，可提前發現資料檔案未生成、未傳輸、檔名不符等異常現象。

　　記憶體

　　GC次數/分鐘：該指標用於對Java虛擬機器每分鐘的FullGC次數進行監控，用於發現Java虛擬機器堆記憶體不足的問題。相比於對Heap空間使用率的監控，透過對持續的、多次FullGC更加能夠準確的發現應用程式執行中潛在的記憶體問題。

　　直接記憶體使用率：該指標用於對Java直接記憶體（堆外記憶體）的使用率進行監控，用於發現Java直接記憶體空間使用的容量問題。

　　②應用元件層

　　API呼叫

　　API呼叫異常：該指標用於對應用程式呼叫外部API介面存在的錯誤和超時進行監控。常見的通用外部介面可能包括加密機API、Redis API、MQ API等，透過對呼叫介面的系統級錯誤資訊進行實時監控，能夠更早、更明確的提示故障根因。

　　佇列

　　佇列深度：該指標用於對應用程式內部自定義佇列的深度進行監控。佇列深度的單位可能是佇列內訊息數量、佇列內超時待處理訊息的數量等，用於發現應用程式可能存在的效能瓶頸。

　　③功能服務層

　　定時任務

　　批次任務失敗/批次任務超時：該指標用於對批次任務的執行狀態/執行時間進行監控。尤其對關鍵批次任務（影響系統開門、客戶服務、監管報送）設定高報警級別，確保及時通報和處理。

　　應用功能

　　系統換日狀態：該指標用於對各交易類系統的賬務日期更換狀態進行監控。

　　秘鑰交換狀態：該指標用於對聯機交易類系統和加密平臺之間秘鑰交換的結果進行監控。

　　應用健康檢查：該指標用於對應用服務的存活狀態進行外部探測檢查，用於及時發現服務夯死的情況，檢查方式通常為透過監控工具發起http探測或模擬交易探測。

　　業務服務

　　交易成功率/響應率/交易量/響應時間：此類指標為聯機交易類應用系統的通用指標，透過從容量、延遲、錯誤3個維度度量應用服務健康狀態。需要關注的是可細分為多個維度，如全域性指標/單交易碼、渠道、商戶、系統返回碼/業務返回碼等，透過維度+指標組合分析發現和定位應用系統交易的異常。

　　4. 監控工具標準化

　　監控工具的標準化，核心思想是根據各類工具的特性合理運用工具，充分發揮工具特長。根據監控需求，監控工具的選取因素包括：有代理/無代理採集、監控主動採集/監控被動接收、帶內採集/帶外採集等。

　　自定義監控指標：具有周期性和靈活性的特點，適合使用有代理、主動採集方式，如Zabbix、Prometheus等。

　　關鍵通知訊息：具有實時和精準的特點，適合使用應用主動推送、監控被動接收的採集方式，如syslog、trap、webhook等。

　　交易資料指標：具有資料量大、資料原始程度高的特點，適合採用旁路/帶外方式將原始資料進行採集後送入專用的監控工具進行分析和處理，減少採集和分析對原有系統的影響。適用的工具包括BPC工具、CDC類工具（變更資料捕獲）等。

　　5. 監控策略標準化

　　監控策略標準化的重要內容是報警級別。G行從兩個維度來定義報警級別：

　　按照管理員視角來定義的級別：根據技術人員是否需要立即展開處置動作來定級，1級表示需技術人員立即處置的報警，2級表示需進一步判斷分析的報警，3級表示暫無需處理的報警。

　　按照業務人員/管理層的視角來定義的級別：根據業務影響的大小來定義報警級別，從高到低分別為重大影響、較大影響、一般影響、輕微影響、潛在影響和無影響。

　　按照上述規則配置應用監控報警策略，當報警發生時分別從兩個維度進行展示、通報和升級等後續處理，滿足技術人員和管理層的差異化運維需求。

　　6. 智慧運維技術的應用

　　AIOps技術的推廣使用，為應用監控標準能力帶來了以下提升：

　　動態閾值豐富了監控策略的管理模式：基於大資料、實時計算和無監督演算法的智慧運維技術，對於各項執行指標的歷史資料生成預測基線，實時計算生產執行資料的偏差程度，及時發現執行指標的異常情況。在原有的基於固定閾值監控策略模式基礎上，動態閾值豐富了監控標準化策略，成為應用系統交易監控必須部署的標準監控策略。

　　多維分析技術提升故障根因定位能力：基於交易碼、返回碼、渠道碼、商戶碼以及服務處理節點資訊等多維度的交易分析，在應用系統聯機交易關鍵指標發生異常時，能夠快速推算出導致異常的組合因子，便於科技人員迅速定位故障原因，同時透過支援黑白名單機制預先固化運維經驗，提升故障告警準確性。

　　 三、分散式應用監控標準化

　　隨著容器技術、微服務以及分散式應用的興起和部署，G行原有的面向傳統環境的應用監控面臨著巨大挑戰，包括大量開源軟體的使用、應用彈性擴縮容常態化、CI/CD帶來的開發投產模式的變更等。G行在傳統環境監控標準化的基礎上進一步最佳化了標準化工作模型，支援分散式應用的監控管理。

　　1. 監控標準化工作模型　　

圖3 監控標準化方法模型圖

　　2. 分散式監控指標參考

　　面對分散式環境下大量開源產品/元件的使用，監控標準化的牛鼻子是監控指標標準化。

　　在監控指標選取方面，G行參考Google提出了黃金指標概念，具體內容如下圖所示：　　

圖4 黃金指標模型圖

　　3. 分散式監控指標制定原則

　　分層分類：監控指標進行分層、分類，由專業團隊和監控團隊合力豐富監控標準。

　　標準統一：無論傳統平臺還是容器雲平臺，對於同一類物件的監控標準要統一，確保指標全覆蓋。

　　同類對標：對於相同型別的監控物件，需對標原有相似型別的監控物件。

　　敏捷迭代：透過主動分析和監控未達事件分析機制，持續補充和完善原有監控規範。

　　4. 分散式應用監控模型　　

圖5 分散式監控模型圖

　　在傳統的應用服務監控模型基礎上，增加了微服務元件，如註冊中心、配置中心、API閘道器等，增加了分散式應用元件，如分散式快取、分散式批次、分散式訊息、分散式資料庫的監控標準化。

　　5. 分散式指標接入

　　透過監控標準化中的指標接入規範、指標測試規範、應用監控策略部署規範以及生產事件跟蹤機制，將監控工作前移至應用開發和測試環節，形成管理閉環。

　　監控指標的介面格式統一採用Prometheus採集規範，即應用程式透過http協議主動暴露資料，監控工具採用pull模型定期拉取監控資料。介面格式為：

　　<指標名稱>{<標籤名稱>=<標籤值>, ...} 資料

　　指標名稱：反映了被監控樣本的含義。

　　標籤：大括號中的標籤反映了當前樣本的特徵維度，用於對樣本資料進行過濾，聚合等。

　　資料：採集到的具體值。

　　應用指標暴露方式主要分為以下兩種：

　　基於G行通用研發平臺開發的應用程式：平臺已內建了監控SDK包，預設支援暴露應用或Spring Boot框架，按照要求進行配置即可暴露監控指標。

　　非G行通用研發平臺開發的應用程式：需要應用程式基於Prometheus的client sdk 或Spring Boot Actuator開發監控介面，按照監控標準暴露應用監控指標。

　　6. 基於標籤的監控自動化部署機制

　　針對每類監控物件我們都設計了監控標籤，監控標籤與一組標準監控指標和標準監控策略對應，我們稱之為標準化監控規則。監控標籤主要用於以下三個場景：　　

圖6 監控標籤應用場景

　　監控標籤的工作機制如下：

　　透過指定標籤查詢指定資料

　　透過標籤實現豐富的聚合和查詢

　　監視具有特定服務發現註解的監控目標

　　向目標抓取請求新增 HTTP 查詢引數

　　僅儲存從指定目標中提取樣本的子集

　　將抓取序列的兩個標籤值合併為一個標籤

　　平臺已有的應用型別新接入時只需要使用製品庫提供的帶監控基礎映象生成應用映象，同時在容器雲平臺透過圖形化方式生成帶有監控標籤的Service.yaml檔案，後續基於該yaml檔案的應用釋出投產後，監控系統採集到的資料同步打上了監控標籤，自動匹配對應的監控策略，實現了全自動監控物件發現和監控策略對接，無需人工干預，確保監控標準化全覆蓋。

　　7. 量化監控評價

　　通常監控系統執行效果評價的指標是監控發現率、報警壓縮率、報警根因定位率等，這些指標都偏向於透過事後的量化統計體現監控系統的效能。除了這些指標外，G行還定義了監控覆蓋率和監控標準化率兩個指標。

　　監控標準化率的計算公式為：

　　監控標準化率 =監控檔案 /監控標準 *100%

　　監控檔案 = ∑監控物件 *已部署標準監控策略

　　監控標準 = ∑監控物件 *應部署標準監控策略

　　按照上述公式對應用系統的所有元件進行監控標準化的度量，可獲得每個應用系統的監控標準化率。　　

圖7 應用監控量化評價效果圖

　　透過上述排名機制，可以獲知各個應用系統的監控策略和基線的偏差情況，對於缺失的監控項需及時進行補充部署監控策略，對於非標準的監控項（如個性化閾值、報警級別降低等情況）需進行應用系統的整改以滿足標準化要求。

　　目前G行已完成對全域性類系統的應用監控標準化評分，後續還將持續最佳化和推廣量化反饋機制，持續提升監控效能。

　　 小結與展望

　　透過多年探索與實踐，G行逐步建立了應用監控標準化的實施方法模型、應用服務模型、監控指標體系以及閉環量化管理機制，逐步完善了傳統應用與分散式應用的監控手段，提升了監控系統整體效能。面對日益複雜的應用系統環境，G行後續將持續進行監控系統最佳化，透過持續豐富應用監控指標集、引入非侵入監控資料採集方式、支援自助式監控配置管理模式等工作，提升應用監控能力。