一、建設背景和問題

隨著分布式云原生、容器化、微服務、大數據技術的成熟和普及，生產系統架構朝著微服務、容器化方向改造，這給監控運維帶來如下問題和挑戰：

• 出現大量分布式新技術并缺乏監控標準：如K8s里的容器、pod、deployment、微服務的API網關、熔斷、服務治理等，亟待梳理這類分布式新技術的監控標準。
• 環境的動態性變強：分布式對象動態可變，例如容器和pod創建、銷毀、遷移，傳統監控工具無法處理云環境下對象的動態發現和更新，無法提前配置。
• 監控數據量急劇增多：監控指標數量隨著容器規模增長呈爆炸式增長，海量監控對象的高頻采集和處理成為一個新的挑戰。
• 業務架構趨于復雜：云原生應用架構下，原有單體系統變成了眾多微服務的協作，單個用戶請求會經過多個微服務應用，形成復雜的調用鏈路，這給問題排查和定位帶來了困難和挑戰。

分布式系統的可觀測性分為metrics(指標)、鏈路和日志。指標監控基于基礎指標數據(例如CPU、內存、響應時間，調用量等)進行監控，是較為傳統和應用范圍最廣的監控手段;鏈路追蹤解決服務間的復雜調用和性能耗時分析問題;日志監控對系統運行過程數據：如關鍵統計信息，警告、錯誤等進行監控，這三種手段共同配合完成分布式系統的全面監控。鏈路監控和日志監控是分布式日志中心的建設范疇，本文主要針對分布式系統的指標監控展開，下文所提到的分布式監控僅限于分布式指標監控范疇。

當前統一監控平臺使用的傳統監控工具比如Zabbix、ITM、Nagios難以實現在容器云及其他分布式動態環境下進行監控，因此亟待采用一種新技術解決分布式系統監控問題。

開展分布式監控，重點需要解決如下幾個問題：

• 分布式監控標準梳理和制定;
• 分布式系統監控工具選型;
• 分布式監控管理平臺設計和開發。維護和管理分布式監控標準，對分布式監控工具進行驅動管理。

下面我們會逐一介紹。

二、分布式標準制定

在分布式監控標準梳理過程中，我們采用如下四個原則，產出如下圖所示的分布式指標體系：

• 分層分類：監控指標進行分層、分類，由各專業團隊再去有重點的豐富監控標準。
• 監控標準統一：無論傳統平臺還是容器云平臺，對于同一個類對象的監控標準要統一，確保指標全覆蓋。
• 同類對標：對于相同類型的監控對象，需對標原有相似類型的監控對象。如新引入的開源中間件需對標傳統的WebLogic監控標準。
• 持續優化：敏捷迭代、持續補充和完善原有監控規范。

分布式指標體系層級圖

具體每個層級，每個組件的監控指標，由于篇幅原因，在此不再展開。

三、平臺概述

分布式監控平臺是統一監控平臺的子系統，負責分布式和云原生系統的監控。平臺主要分為四層：監控工具層、存儲層、處理層和管理平臺層，如下圖所示：

分布式監控平臺邏輯架構圖

監控工具層主要是由Prometheus工具組成，接收處理層的驅動指令，進行監控對象的自動發現、數據采集、告警判斷、性能數據進行本地存儲的同時，實時送入存儲層的Kafka，為后繼的數據分析提供數據源。

處理層負責連接監控管理層和工具層，主要包括工具驅動、實時數據處理、告警處理、Prometheus本地數據實時查詢四大功能模塊。

工具管理和驅動：將監控管理層的指令轉換成Prometheus Operator接口API，進行相應Prometheus工具的驅動，如自動發現配置、采集指標配置、采集頻率、告警配置(指標、閾值、告警持續時間)，告警等級，性能數據存儲配置等。

實時數據處理：對性能數據進行實時時間戳轉換，異常清洗，數據格式化和標準化處理，InfluxDB存儲格式適配等，最后送入存儲層的InfluxDB進行歷史存儲，供后繼的監控視圖展示和問題定位查詢使用。

告警處理：通過搭建AlertManager集群和自研的告警處理模塊，二者互相配合，實現告警的統一集中處理。

Prometheus本地數據實時查詢：接收管理平臺請求，獲取相應Prometheus本地性能數據，按需提取字段，采樣點稀釋，數據聚合等。

管理平臺層由接口層、指標&指標實現管理、策略管理、規則管理、標簽管理、工具管理、驅動管理、監控評價、監控視圖展示、告警管理組成，其中接口層提供統一門戶實現監控信息的全貌展示，提供便捷的管理支持與任務派發。

四、平臺關鍵技術點

1、高可用、高性能、可擴展的分布式監控工具建設

調研當前業界眾多的開源監控系統例如Prometheus、OpenFalcon和夜鶯等，最終選型Prometheus，原因是：

• 原生支持K8s監控：具有k8s對象服務和分布式系統對象的發現能力，而且k8核心組件和很多都提供了Prometheus采集接口。
• 強大的性能：go語言開發，v3版本支持每秒千萬級的指標采集和存儲，可以滿足一定規模下k8s集群的監控需求。
• 良好的查詢能力：PromQL提供大量的數據計算函數，可通過PromQL查詢所需要的聚合數據。
• 不依賴外部存儲：自帶高性能本地時序數據庫，實現采集數據的本地存儲，同時可對接第三方存儲實現歷史數據存儲。

當然Prometheus也有他的不足，那就是：

• Prometheus不支持集群部署，單機處理能力有限，缺乏高可用和擴展能力。
• Prometheus本地存儲容量有限，不能滿足較長時間范圍的歷史數據存儲和查詢。
• 缺乏平臺化和自服務管理能力，不支持通過API進行監控配置(尤其是管理監控目標和管理警報規則)，也沒有多實例管理手段。

我們對Prometheus的不足做了一些擴展與整合：

• 缺乏高可用問題：在分布式監控集群中，每個Prometheus監控實例均采用主備方式部署，同一監控對象同時有兩個Prometheus進行監控，任意一個Prometheus實例失效都不會影響到監控系統的整體功能。
• 不支持集群，單機處理能力有限問題：設計并實現基于標簽的可擴展機制，支持K8s和獨立部署下動態新增或者刪減Prometheus工具實例，采集Target動態調整和分配，實現監控能力可擴展。支持功能分區和水平擴展兩種方式，所謂功能分區就是不同的Prometheus負責監控不同的對象，比如Prometheus A負責監控K8s組件，Prometheus B負責監控容器云上部署的應用;水平擴展就是極端情況下，當個采集任務的Target數也變得非常巨大，這時通過功能分區無法有效處理，可進行水平分區，將同一任務的不同實例的采集任務劃分到不同的Prometheus。
• 本地存儲能力有限問題：把Prometheus性能數據實時寫入Kafka，再通過Flink流式計算實時消費到InfluxDB，利用InfluxDB的分布式可擴展能力，解決了單Prometheus本地存儲的限制問題。
• 缺乏平臺化和自服務管理能力：引入Prometheus Operator對Prometheus、監控規則、監控對象、AlertManager等K8s監控資源進行API式管理。開發分布式監控管理平臺，提供圖形化的監控標準配置管理界面，進行自服務化、自動化下發，具體會在下面章節進行詳細介紹。

2、標準化和自服務化

建立標準化的分布式監控標準管理模型。基于標簽在K8s和Prometheus中的重要作用(K8s基于標簽分類管理資源對象;PromQL基于標簽做數據聚合;Prometheus Operator基于標簽匹配監控對象和監控規則)，因此以標簽為核心，構建了一套分布式管理模型，具體包括監控標簽、監控工具、指標實現、指標、監控策略、監控規則，如下圖所示。通過在分布式監控平臺落地實現了同類對象的標準化監控。

分布式監控標準模型圖

打通運維和研發壁壘，實現代碼即監控。監控管理員提前內置下發監控規則，研發投產時，只需要做兩點就可實現監控：

• 自研應用提供指標采集接口，公共開源組件以sidecar模式部署相應exporter暴露采集接口;
• 投產Service yml配置上具體對象類型標簽信息(nginx、tomcat、Kafka、Java應用、go應用、Redis等)。

驅動模塊根據Service yml驅動Prometheus實現投產對象的配置和發現，并基于預置的規則進行監控，示例如下圖所示：

標準化和自服務化配置下發監控規則過程示例圖

3、集中統一管理

集中告警處理集群搭建：搭建AlertManager告警處理集群，實現告警的集中統一管理。通過AlertManager的分組、抑制、靜默實現告警的初步處理，但是AlertManager現有功能不滿足如下實際生產需求：

• 告警持續發生2小時未恢復，再次產生一條更高級別的告警(告警升級);
• 告警轉換成syslog對接統一監控平臺;
• 相同告警持續發生半小時內只產生一條告警(告警壓縮);
• 針對集群、應用系統維度的總結性告警;
• 基于特定場景的根因定位，如Master節點宕機導致其上K8s核心組件不可用，產生一條master節點宕機根因告警(告警根因定位)。

告警二次處理模塊：基于go語言自研高性能告警處理模塊，提供webhook接口供AlertManger調用。接口實現的功能有：告警字段豐富、告警壓縮、告警升級、告警總結、告警根因提示、告警轉syslog發送統一監控平臺。

Adapter改造：基于開源Prometheus Kafka Adapter進行改造，確保海量性能數據實時寫入Kafka，供后繼的數據分析和數據價值利用，比如動態基線計算和異常檢測等。

Adapter工作示意圖

適配當前Kafka SASL/PLAINTEXT認證模式，對采集數據進行壓縮以節約帶寬，對Kafka寫入性能參數調優以應對大并發數據量的實時寫入。

設計Adapter主備模式，避免數據重復。如果主Adapter健康檢查能通過且主Adapter對應的Prometheus正常運行，則利用主Adapter傳遞數據送入Kafka，備Adapter暫停工作;如果主Adapter或者主Adapter對應的Prometheus健康檢查不通過，則使用備用Adapter進行傳遞數據，并通知管理人員Prometheus和主Adapter故障。

流處理模塊：基于Flink自研流處理模塊，確保海量性能數據的實時處理和入庫。流處理的內容包括：時間戳處理(Prometheus默認采用UTC時間)、異常數據清洗、數據格式化和標準化處理，InfluxDB存儲格式適配。

告警和性能數據集中處理架構圖

五、總結

在平臺建設中，借鑒同業及互聯網企業容器云K8s相關建設經驗，基于開源技術自主研發，構建了立體化、集中化、平臺化、標準化的分布式監控平臺，系統具有如下特點：

• 自動發現：動態環境自動發現并監控;
• 高性能：海量對象秒級采集處理，日均處理T級數據，并可彈性擴展;
• 自動化&自服務化：避免針對具體監控對象逐個手工配置，靈活性差，容易誤操作和漏操作，維護成本較高的問題;
• 研發運維打通：監控遷移到設計開發階段，研發暴露指標&自助配置投產yml和策略即可實現分布式監控;
• 自主可控：基于開源Prometheus技術自主研發。

目前分布式監控平臺已于11月初在G行投產，實現G行容器云生產集群的全面監控，實現海量對象的秒級處理，日均處理T級數據，告警準確率和召回率均為100%，系統運行穩定，監控效果符合預期。

六、后繼工作展望

平臺一期建設實現了容器云及云上應用和服務的監控，接下來會擴大分布式監控的納管范圍，實現分布式數據庫、全棧云管理平臺、分布式消息等的監控納管。

監控自服務化能力建設，封裝有一些自服務監控場景：比如監控的上下線、監控規則修改、個性化監控配置等。

監控評價功能，以量化的方式展示分布式系統的監控覆蓋率和標準化率，以評促改，形成閉環。

分布式監控工具自身優化，比如Prometheus負載的自動平衡，基于一些預警數據，智能擴縮Prometheus的實例個數，自動分配采集對象，達到最佳的監控能力。

與自動化運維操作平臺進行聯動，實現一些場景的自動化處置。