應用監控是整個監控體系的重要組成部分，面對各個應用系統之間的差異性和復雜性特點，如何全面有效的實施應用監控是應用運維人員和監控管理員共同面臨的難題。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、RedisAPI、MQAPI等，通過對調用接口的系統級錯誤信息進行實時監控，能夠更早、更明確的提示故障根因。
●隊列
隊列深度：該指標用于對應用程序內部自定義隊列的深度進行監控。隊列深度的單位可能是隊列內消息數量、隊列內超時待處理消息的數量等，用于發現應用程序可能存在的性能瓶頸。
功能服務層
●定時任務
批量任務失敗/批量任務超時：該指標用于對批量任務的運行狀態/運行時間進行監控。尤其對關鍵批量任務（影響系統開門、客戶服務、監管報送）設定高報警級別，確保及時通報和處理。
●應用功能
系統換日狀態：該指標用于對各交易類系統的賬務日期更換狀態進行監控。
秘鑰交換狀態：該指標用于對聯機交易類系統和加密平臺之間秘鑰交換的結果進行監控。
應用健康檢查：該指標用于對應用服務的存活狀態進行外部探測檢查，用于及時發現服務夯死的情況，檢查方式通常為通過監控工具發起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包，默認支持暴露應用或SpringBoot框架，按照要求進行配置即可暴露監控指標。
非G行通用研發平臺開發的應用程序：需要應用程序基于Prometheus的clientsdk或SpringBootActuator開發監控接口，按照監控標準暴露應用監控指標。
6.基于標簽的監控自動化部署機制
針對每類監控對象我們都設計了監控標簽，監控標簽與一組標準監控指標和標準監控策略對應，我們稱之為標準化監控規則。監控標簽主要用于以下三個場景：
圖6監控標簽應用場景
監控標簽的工作機制如下：
通過指定標簽查詢指定數據
通過標簽實現豐富的聚合和查詢
監視具有特定服務發現注解的監控目標
向目標抓取請求添加HTTP查詢參數
僅存儲從指定目標中提取樣本的子集
將抓取序列的兩個標簽值合并為一個標簽
平臺已有的應用類型新接入時只需要使用制品庫提供的帶監控基礎鏡像生成應用鏡像，同時在容器云平臺通過圖形化方式生成帶有監控標簽的Service.yaml文件，后續基于該yaml文件的應用發布投產后，監控系統采集到的數據同步打上了監控標簽，自動匹配對應的監控策略，實現了全自動監控對象發現和監控策略對接，無需人工干預，確保監控標準化全覆蓋。
7.量化監控評價
通常監控系統運行效果評價的指標是監控發現率、報警壓縮率、報警根因定位率等，這些指標都偏向于通過事后的量化統計體現監控系統的效能。除了這些指標外，G行還定義了監控覆蓋率和監控標準化率兩個指標。
監控標準化率的計算公式為：
監控標準化率=監控檔案/監控標準*100%
監控檔案=∑監控對象*已部署標準監控策略
監控標準=∑監控對象*應部署標準監控策略
按照上述公式對應用系統的所有組件進行監控標準化的度量，可獲得每個應用系統的監控標準化率。
圖7應用監控量化評價效果圖
通過上述排名機制，可以獲知各個應用系統的監控策略和基線的偏差情況，對于缺失的監控項需及時進行補充部署監控策略，對于非標準的監控項（如個性化閾值、報警級別降低等情況）需進行應用系統的整改以滿足標準化要求。
目前G行已完成對全局類系統的應用監控標準化評分，后續還將持續優化和推廣量化反饋機制，持續提升監控效能。
小結與展望
通過多年探索與實踐，G行逐步建立了應用監控標準化的實施方法模型、應用服務模型、監控指標體系以及閉環量化管理機制，逐步完善了傳統應用與分布式應用的監控手段，提升了監控系統整體效能。面對日益復雜的應用系統環境，G行后續將持續進行監控系統優化，通過持續豐富應用監控指標集、引入非侵入監控數據采集方式、支持自助式監控配置管理模式等工作，提升應用監控能力。
