基于Prometheus體系的復雜業務系統監控實踐

張曉強

中國聯通軟件研究院濟南分院，山東濟南，250000

0 引言

相較于主機、容器、中間件等通用性的監控對象，業務系統監控具有更大的挑戰性。首先，對于主機、容器、中間件等，Prometheus社區有很多通用指標采集器、監控指標規范等可以借鑒，采集周期多為固定時長，指標數據相對簡單、規整。但是業務監控不同：業務指標相對來說較為復雜，不同的業務系統會有不同的指標體系，對于具體的業務指標，需要單獨開發指標采集器；告警規則不同，業務指標之間有時會產生一定的關聯性，需要關聯判斷；采集周期不確定，一般分為固定時間點和固定時間周期兩種。在長期的業務系統監控實踐中，我們根據Prometheus生態體系，結合實際的業務情況，摸索出一套現實可行的業務監控系統[1]。

1 系統架構

系統分為數據采集層、監控與告警組件、用戶交互三層（如圖1所示）。數據采集層采用自研指標統一采集框架，在Prometheus原有采集功能上擴充指標數據超時及指標基線功能。監控組件采用Prometheus+Alertmanager，Prometheus采用主備部署模式，用于拉取并存儲時間序列數據以及計算、配置告警規則，Alertmanager采用三節點集群部署模式，用于進行告警的管理及將告警發送到對應的webhook，在webhook中根據配置的告警策略通過通知中心發送給用戶。用戶交互層通過自研的釘釘移動端，包含監控視圖、運維操作、數據可視化、通知中心等功能[2]。

1.1 指標采集

業務數據采集沒有現成的指標采集器可以使用，需要自己去開發。采集器主要分為兩種模式，標準模式和自定義采集模式。標準模式將指標數據刷新到緩存中，Prometheus調取接口獲取緩存中數據，采集效率高，但數據會有延遲。自定義采集模式為Prometheus調用采集器接口時，采集器才會去業務系統獲取對應的指標，并把指標返回給Prometheus，數據延遲低，但采集性能差。在實際的業務監控中，對于及時性要求不高或者獲取業務數據時間耗時長的指標，我們采用標準模式以降低Prometheus采集的性能消耗，對于及時性要求很高且指標數量少、數據獲取時間短的指標我們采用自定義采集的模式以降低指標數據延遲。Prometheus提供拉取+推送（實際是pushgateway提供中間數據緩存，實際仍為拉取方式）兩種采集方式。對于固定周期數據使用拉取方式實現，對于固定時間點（如每月、每周固定時間點產生）或隨機產生指標適用于推送方式實現。

Prometheus本身不提供指標基線功能，只要是指標采集器返回的數據照單全收，對于指標缺失是沒有感知的。但是對于指標缺失的情況，所有的告警規則計算結果都會為空，這樣就會產生一定的風險。對此我們進行了改造，首先在主應用側維護所有的指標基線，在不同的指標采集器側維護同步接口，定時從主應用同步所有的指標基線存儲到本地Redis中，且為每條指標增加當前時間戳字段表示數據時間，同時對于不同的指標設置不同的超時時間。指標采集器進行Redis中指標取值刷新時，會判斷該條指標是否在指標基線中，若存在則賦值并刷新時間戳，否則則忽略。在Prometheus拉取指標時，直接取出Redis中所有的指標進行返回，采集器會判斷Redis中指標基線取值是否已超過超時時間，若超過則將指標取值打為-9999.99等特殊數值，在Prometheus中配置告警規則判斷是否有-9999.99的取值來判斷是否有指標缺失，若存在則告警通知用戶[3]。如圖2所示。

1.2 指標體系

Prometheus指標分為三部分。①指標名和標簽（metric）：在內部存儲上指標名也作為名為__name__的特殊標簽與其他標簽共同唯一標識每條指標；②時間戳（timestamp）：指標數據采集的時間，精確到毫秒；③樣本值（value）：表示當前樣本的值，folat64類型。

在系統中采用Prometheus默認時序數據庫進行指標存儲。Prometheus會將所有采集到的樣本數據以時間序列（time-series）的方式保存在內存數據庫中，并且定時保存到時序庫中。時間序列中縱軸為所有的標簽，橫軸為時間戳，這樣所有的標簽只需要存儲一次，每次采集指標只需要存儲時間戳和取值即可，大大地提升了存儲性能。

Prometheus支持四種類型的指標，包括Counter（只增不減）、Gauge（可增可減）、Summary（數據集的不同分位數）、Histogram（數據集的不同區間的指標數量）。在實際的業務系統監控中，我們采用Gauge的指標類型，基于其可增加可減少，也可以直接賦值的特性，可以很好地滿足業務監控需求。

為了應對業務的復雜程度，指標體系中統一添加了模塊和租戶標簽，以區分不同業務模塊的指標。對于所有的指標體系進行統一編碼，統一管理，每條指標明細配置唯一ID和CMDB實例名稱，告警發生后以便定位具體的告警指標和CMDB實例，方便進行告警分析。指標基線由CMDB統一管理，配置指標無數據告警，保證數據可靠性。

1.3 告警處理

告警規則配置在Consul中，通過Consul Template同步到Prometheus配置文件中，不同的業務模塊使用不同的配置文件。告警規則結合業務經驗進行配置，一般為固定閾值，對于閾值隨時間變化的監控點，需要按照需求定時去刷新Consul中規則配置文件，除了閾值外，還應配置閾值持續時間，即超過閾值多長時間才算告警，避免一些瞬時超過閾值造成誤告警或者告警閃斷。告警規則分為一般告警及嚴重告警，不同的告警等級對應不同的告警通知方式以及告警恢復的緊急程度。

Prometheus負責告警規則計算，告警觸發后，將告警信息發送到Alertmanager，Alertmanager負責接收Prometheus等發送的告警。Alertmanager具有告警分組、告警靜默、告警抑制功能；告警分組是在告警第一次發生后，等待一段時間再進行發送，若在等待期間有同組的告警觸發，則會加入分組中一塊發送給用戶，以防發生告警風暴；告警抑制是告警之間往往有一定的關聯程度，具有因果關系的告警不應該重復發送給用戶，例如進程停止后往往會造成進程積壓，進程狀態發生告警后，進程積壓不應該再發給用戶；告警靜默是告警發生后，用戶可以手動觸發靜默，使告警不再發送給用戶，給用戶足夠的解決問題的時間。Alertmanager接收告警后通過配置的告警路由將告警路由到正確的webhook接口，通過自定義webhook接口對告警信息、告警策略進行個性化定制，例如采用不同的告警方式、根據值班表發送給不同的值班人員等[4]。

1.4 用戶交互

用戶交互采用自研釘釘移動端平臺的方式，前臺采用React框架，后臺采用SpringCloud微服務框架。平臺區分多租戶，不同租戶之間提供租戶服務、配置信息、存儲資源隔離，保證租戶之間互不影響、互不干涉。平臺提供多種監控視圖，針對不同業務模塊、不同監控對象為用戶提供多維度多樣式的監控視圖。同時平臺提供相關的運維操作功能及數據展示功能，實現告警、監控、運維操作一體化[5]。

通知中心提供短信通知、釘釘通知及電話外呼功能。針對一般告警，通常只需要進行釘釘通知。釘釘通知分為工作通知、群機器人等方式。在用戶權限允許范圍內，用戶可自行訂閱告警通知以及告警通知接收時間等，通知接收后用戶可在釘釘平臺中進行告警確認、告警靜默等操作。對于嚴重的告警，需要通過電話外呼的形式發送給用戶，電話外呼采用逐層上報告警策略，結合值班表會對值班人員進行多次通知，若用戶沒有響應，則會向上反映，直到告警接收為止，確保嚴重告警發生后，保證值班人員能夠接收到告警信息。對于可預見性的告警提供生產聯動功能，在正常生產操作發生時靜默告警點，防止產生誤告警。

2 業務流程監控

在系統建設過程中，指標接入工作一直以監控點作為單位進行，對于系統中一些關鍵的業務流程是否覆蓋全面、是否能夠有效地監控無法進行有效的分析。為了增加監控系統的可靠性、全面性，針對關鍵的業務流程進行重點監控，我們引入了業務流程監控。使用CMDB和圖數據庫，構建業務流程圖，每個節點對應一部分實際存在的進程、數據庫、中間件、主機、容器等組件，針對具體的實例節點定制監控點規范、稽核實例節點是否監控全面、是否監控有效。同時針對具體的應用構建應用拓撲，告警發生時，根據業務拓撲分析告警產生的根本原因或產生的范圍影響[6]。

3 結論與展望

業務監控復雜程度高，對于一些業務指標設置固定的告警規則會造成很多的誤告警，需要結合AiOps技術實現單指標閾值監控及多指標閾值自動判斷。平臺缺乏監控自助接入功能，目前監控接入依賴維護人員人工配置，效率低。同時，當前告警處理自動化程度低，無法實現告警自動恢復、處理等功能。平臺接入指標后，缺乏可靠的告警全面性、有效性分析標準，對于缺失的監控無法有效識別。在后續建設工作中，需要擴充告警分析模塊，對產生的告警進行影響范圍分析、根因分析、智能告警收斂等，進一步提升告警的價值，減少業務人員處理的告警數量；完善告警自助接入功能，將接入功能全面下放；對接告警自動及手動處理模塊，實現告警閉環，同時建立完善的有效性、全面性分析機制，進一步提升監控系統可用性、可靠性。