建設背景和問題
随着分布式雲原生、容器化、微服務、大資料技術的成熟和普及，生産系統架構朝着微服務、容器化方向改造，這給監控運維帶來如下問題和挑戰：
出現大量分布式新技術并缺乏監控标準：如K8s裡的容器、pod、deployment、微服務的API網關、熔斷、服務治理等，亟待梳理這類分布式新技術的監控标準。
環境的動态性變強：分布式對象動态可變，例如容器和pod建立、銷毀、遷移，傳統監控工具無法處理雲環境下對象的動态發現和更新，無法提前配置。
監控資料量急劇增多：監控名額數量随着容器規模增長呈爆炸式增長，海量監控對象的高頻采集和處理成為一個新的挑戰。
業務架構趨于複雜：雲原生應用架構下，原有單體系統變成了衆多微服務的協作，單個使用者請求會經過多個微服務應用，形成複雜的調用鍊路，這給問題排查和定位帶來了困難和挑戰。
分布式系統的可觀測性分為metrics（名額）、鍊路和日志。名額監控基于基礎名額資料（例如CPU、記憶體、響應時間，調用量等）進行監控，是較為傳統和應用範圍最廣的監控手段；鍊路追蹤解決服務間的複雜調用和性能耗時分析問題；日志監控對系統運作過程資料：如關鍵統計資訊，警告、錯誤等進行監控，這三種手段共同配合完成分布式系統的全面監控。鍊路監控和日志監控是分布式日志中心的建設範疇，本文主要針對分布式系統的名額監控展開，下文所提到的分布式監控僅限于分布式名額監控範疇。
目前統一監控平台使用的傳統監控工具比如Zabbix、ITM、Nagios難以實作在容器雲及其他分布式動态環境下進行監控，是以亟待采用一種新技術解決分布式系統監控問題。
開展分布式監控，重點需要解決如下幾個問題：
分布式監控标準梳理和制定；
分布式系統監控工具選型；
分布式監控管理平台設計和開發。維護和管理分布式監控标準，對分布式監控工具進行驅動管理。
下面我們會逐一介紹。
分布式标準制定
在分布式監控标準梳理過程中，我們采用如下四個原則，産出如下圖所示的分布式名額體系：
分層分類：監控名額進行分層、分類，由各專業團隊再去有重點的豐富監控标準。
監控标準統一：無論傳統平台還是容器雲平台，對于同一個類對象的監控标準要統一，確定名額全覆寫。
同類對标：對于相同類型的監控對象，需對标原有相似類型的監控對象。如新引入的開源中間件需對标傳統的WebLogic監控标準。
持續優化：靈活疊代、持續補充和完善原有監控規範。
分布式名額體系層級圖
具體每個層級，每個元件的監控名額，由于篇幅原因，在此不再展開。
平台概述
分布式監控平台是統一監控平台的子系統，負責分布式和雲原生系統的監控。平台主要分為四層：監控工具層、存儲層、處理層和管理平台層，如下圖所示：
分布式監控平台邏輯架構圖
監控工具層主要是由Prometheus工具組成，接收處理層的驅動指令，進行監控對象的自動發現、資料采集、告警判斷、性能資料進行本地存儲的同時，實時送入存儲層的Kafka，為後繼的資料分析提供資料源。
處理層負責連接配接監控管理層和工具層，主要包括工具驅動、實時資料處理、告警處理、Prometheus本地資料實時查詢四大功能子產品。
（1）工具管理和驅動：将監控管理層的指令轉換成Prometheus Operator接口API，進行相應Prometheus工具的驅動，如自動發現配置、采集名額配置、采集頻率、告警配置（名額、門檻值、告警持續時間），告警等級，性能資料存儲配置等。
（2）實時資料處理：對性能資料進行實時時間戳轉換，異常清洗，資料格式化和标準化處理，InfluxDB存儲格式适配等，最後送入存儲層的InfluxDB進行曆史存儲，供後繼的監控視圖展示和問題定位查詢使用。
（3）告警處理：通過搭建AlertManager叢集和自研的告警處理子產品，二者互相配合，實作告警的統一集中處理。
（4）Prometheus本地資料實時查詢：接收管理平台請求，擷取相應Prometheus本地性能資料，按需提取字段，采樣點稀釋，資料聚合等。
管理平台層由接口層、名額&名額實作管理、政策管理、規則管理、标簽管理、工具管理、驅動管理、監控評價、監控視圖展示、告警管理組成，其中接口層提供統一門戶實作監控資訊的全貌展示，提供便捷的管理支援與任務派發。
平台關鍵技術點
高可用、高性能、可擴充的分布式監控工具建設
調研目前業界衆多的開源監控系統例如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式管理。開發分布式監控管理平台，提供圖形化的監控标準配置管理界面，進行自服務化、自動化下發，具體會在下面章節進行詳細介紹。
标準化和自服務化
建立标準化的分布式監控标準管理模型。基于标簽在K8s和Prometheus中的重要作用（K8s基于标簽分類管理資源對象；PromQL基于标簽做資料聚合；Prometheus Operator基于标簽比對監控對象和監控規則），是以以标簽為核心，建構了一套分布式管理模型，具體包括監控标簽、監控工具、名額實作、名額、監控政策、監控規則，如下圖所示。通過在分布式監控平台落地實作了同類對象的标準化監控。
分布式監控标準模型圖
打通運維和研發壁壘，實作代碼即監控。監控管理者提前内置下發監控規則，研發投産時，隻需要做兩點就可實作監控：
自研應用提供名額采集接口，公共開源元件以sidecar模式部署相應exporter暴露采集接口；
投産Service yml配置上具體對象類型标簽資訊（nginx、tomcat、Kafka、Java應用、go應用、Redis等）。
驅動子產品根據Service yml驅動Prometheus實作投産對象的配置和發現，并基于預置的規則進行監控，示例如下圖所示：
标準化和自服務化配置下發監控規則過程示例圖
集中統一管理
集中告警處理叢集搭建：搭建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%，系統運作穩定，監控效果符合預期。