一、建設(shè)背景和問題

隨著分布式云原生、容器化、微服務(wù)、大數(shù)據(jù)技術(shù)的成熟和普及，生產(chǎn)系統(tǒng)架構(gòu)朝著微服務(wù)、容器化方向改造，這給監(jiān)控運(yùn)維帶來如下問題和挑戰(zhàn)：

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

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

當(dāng)前統(tǒng)一監(jiān)控平臺使用的傳統(tǒng)監(jiān)控工具比如Zabbix、ITM、Nagios難以實(shí)現(xiàn)在容器云及其他分布式動態(tài)環(huán)境下進(jìn)行監(jiān)控，因此亟待采用一種新技術(shù)解決分布式系統(tǒng)監(jiān)控問題。

開展分布式監(jiān)控，重點(diǎn)需要解決如下幾個問題：

• 分布式監(jiān)控標(biāo)準(zhǔn)梳理和制定;
• 分布式系統(tǒng)監(jiān)控工具選型;
• 分布式監(jiān)控管理平臺設(shè)計(jì)和開發(fā)。維護(hù)和管理分布式監(jiān)控標(biāo)準(zhǔn)，對分布式監(jiān)控工具進(jìn)行驅(qū)動管理。

下面我們會逐一介紹。

二、分布式標(biāo)準(zhǔn)制定

在分布式監(jiān)控標(biāo)準(zhǔn)梳理過程中，我們采用如下四個原則，產(chǎn)出如下圖所示的分布式指標(biāo)體系：

• 分層分類：監(jiān)控指標(biāo)進(jìn)行分層、分類，由各專業(yè)團(tuán)隊(duì)再去有重點(diǎn)的豐富監(jiān)控標(biāo)準(zhǔn)。
• 監(jiān)控標(biāo)準(zhǔn)統(tǒng)一：無論傳統(tǒng)平臺還是容器云平臺，對于同一個類對象的監(jiān)控標(biāo)準(zhǔn)要統(tǒng)一，確保指標(biāo)全覆蓋。
• 同類對標(biāo)：對于相同類型的監(jiān)控對象，需對標(biāo)原有相似類型的監(jiān)控對象。如新引入的開源中間件需對標(biāo)傳統(tǒng)的WebLogic監(jiān)控標(biāo)準(zhǔn)。
• 持續(xù)優(yōu)化：敏捷迭代、持續(xù)補(bǔ)充和完善原有監(jiān)控規(guī)范。

分布式指標(biāo)體系層級圖

具體每個層級，每個組件的監(jiān)控指標(biāo)，由于篇幅原因，在此不再展開。

三、平臺概述

分布式監(jiān)控平臺是統(tǒng)一監(jiān)控平臺的子系統(tǒng)，負(fù)責(zé)分布式和云原生系統(tǒng)的監(jiān)控。平臺主要分為四層：監(jiān)控工具層、存儲層、處理層和管理平臺層，如下圖所示：

分布式監(jiān)控平臺邏輯架構(gòu)圖

監(jiān)控工具層主要是由Prometheus工具組成，接收處理層的驅(qū)動指令，進(jìn)行監(jiān)控對象的自動發(fā)現(xiàn)、數(shù)據(jù)采集、告警判斷、性能數(shù)據(jù)進(jìn)行本地存儲的同時，實(shí)時送入存儲層的Kafka，為后繼的數(shù)據(jù)分析提供數(shù)據(jù)源。

處理層負(fù)責(zé)連接監(jiān)控管理層和工具層，主要包括工具驅(qū)動、實(shí)時數(shù)據(jù)處理、告警處理、Prometheus本地?cái)?shù)據(jù)實(shí)時查詢四大功能模塊。

工具管理和驅(qū)動：將監(jiān)控管理層的指令轉(zhuǎn)換成Prometheus Operator接口API，進(jìn)行相應(yīng)Prometheus工具的驅(qū)動，如自動發(fā)現(xiàn)配置、采集指標(biāo)配置、采集頻率、告警配置(指標(biāo)、閾值、告警持續(xù)時間)，告警等級，性能數(shù)據(jù)存儲配置等。

實(shí)時數(shù)據(jù)處理：對性能數(shù)據(jù)進(jìn)行實(shí)時時間戳轉(zhuǎn)換，異常清洗，數(shù)據(jù)格式化和標(biāo)準(zhǔn)化處理，InfluxDB存儲格式適配等，最后送入存儲層的InfluxDB進(jìn)行歷史存儲，供后繼的監(jiān)控視圖展示和問題定位查詢使用。

告警處理：通過搭建AlertManager集群和自研的告警處理模塊，二者互相配合，實(shí)現(xiàn)告警的統(tǒng)一集中處理。

Prometheus本地?cái)?shù)據(jù)實(shí)時查詢：接收管理平臺請求，獲取相應(yīng)Prometheus本地性能數(shù)據(jù)，按需提取字段，采樣點(diǎn)稀釋，數(shù)據(jù)聚合等。

管理平臺層由接口層、指標(biāo)&指標(biāo)實(shí)現(xiàn)管理、策略管理、規(guī)則管理、標(biāo)簽管理、工具管理、驅(qū)動管理、監(jiān)控評價(jià)、監(jiān)控視圖展示、告警管理組成，其中接口層提供統(tǒng)一門戶實(shí)現(xiàn)監(jiān)控信息的全貌展示，提供便捷的管理支持與任務(wù)派發(fā)。

四、平臺關(guān)鍵技術(shù)點(diǎn)

1、高可用、高性能、可擴(kuò)展的分布式監(jiān)控工具建設(shè)

調(diào)研當(dāng)前業(yè)界眾多的開源監(jiān)控系統(tǒng)例如Prometheus、OpenFalcon和夜鶯等，最終選型Prometheus，原因是：

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

當(dāng)然Prometheus也有他的不足，那就是：

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

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

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

2、標(biāo)準(zhǔn)化和自服務(wù)化

建立標(biāo)準(zhǔn)化的分布式監(jiān)控標(biāo)準(zhǔn)管理模型?；跇?biāo)簽在K8s和Prometheus中的重要作用(K8s基于標(biāo)簽分類管理資源對象;PromQL基于標(biāo)簽做數(shù)據(jù)聚合;Prometheus Operator基于標(biāo)簽匹配監(jiān)控對象和監(jiān)控規(guī)則)，因此以標(biāo)簽為核心，構(gòu)建了一套分布式管理模型，具體包括監(jiān)控標(biāo)簽、監(jiān)控工具、指標(biāo)實(shí)現(xiàn)、指標(biāo)、監(jiān)控策略、監(jiān)控規(guī)則，如下圖所示。通過在分布式監(jiān)控平臺落地實(shí)現(xiàn)了同類對象的標(biāo)準(zhǔn)化監(jiān)控。

分布式監(jiān)控標(biāo)準(zhǔn)模型圖

打通運(yùn)維和研發(fā)壁壘，實(shí)現(xiàn)代碼即監(jiān)控。監(jiān)控管理員提前內(nèi)置下發(fā)監(jiān)控規(guī)則，研發(fā)投產(chǎn)時，只需要做兩點(diǎn)就可實(shí)現(xiàn)監(jiān)控：

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

驅(qū)動模塊根據(jù)Service yml驅(qū)動Prometheus實(shí)現(xiàn)投產(chǎn)對象的配置和發(fā)現(xiàn)，并基于預(yù)置的規(guī)則進(jìn)行監(jiān)控，示例如下圖所示：

標(biāo)準(zhǔn)化和自服務(wù)化配置下發(fā)監(jiān)控規(guī)則過程示例圖

3、集中統(tǒng)一管理

集中告警處理集群搭建：搭建AlertManager告警處理集群，實(shí)現(xiàn)告警的集中統(tǒng)一管理。通過AlertManager的分組、抑制、靜默實(shí)現(xiàn)告警的初步處理，但是AlertManager現(xiàn)有功能不滿足如下實(shí)際生產(chǎn)需求：

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

告警二次處理模塊：基于go語言自研高性能告警處理模塊，提供webhook接口供AlertManger調(diào)用。接口實(shí)現(xiàn)的功能有：告警字段豐富、告警壓縮、告警升級、告警總結(jié)、告警根因提示、告警轉(zhuǎn)syslog發(fā)送統(tǒng)一監(jiān)控平臺。

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

Adapter工作示意圖

適配當(dāng)前Kafka SASL/PLAINTEXT認(rèn)證模式，對采集數(shù)據(jù)進(jìn)行壓縮以節(jié)約帶寬，對Kafka寫入性能參數(shù)調(diào)優(yōu)以應(yīng)對大并發(fā)數(shù)據(jù)量的實(shí)時寫入。

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

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

告警和性能數(shù)據(jù)集中處理架構(gòu)圖

五、總結(jié)

在平臺建設(shè)中，借鑒同業(yè)及互聯(lián)網(wǎng)企業(yè)容器云K8s相關(guān)建設(shè)經(jīng)驗(yàn)，基于開源技術(shù)自主研發(fā)，構(gòu)建了立體化、集中化、平臺化、標(biāo)準(zhǔn)化的分布式監(jiān)控平臺，系統(tǒng)具有如下特點(diǎn)：

• 自動發(fā)現(xiàn)：動態(tài)環(huán)境自動發(fā)現(xiàn)并監(jiān)控;
• 高性能：海量對象秒級采集處理，日均處理T級數(shù)據(jù)，并可彈性擴(kuò)展;
• 自動化&自服務(wù)化：避免針對具體監(jiān)控對象逐個手工配置，靈活性差，容易誤操作和漏操作，維護(hù)成本較高的問題;
• 研發(fā)運(yùn)維打通：監(jiān)控遷移到設(shè)計(jì)開發(fā)階段，研發(fā)暴露指標(biāo)&自助配置投產(chǎn)yml和策略即可實(shí)現(xiàn)分布式監(jiān)控;
• 自主可控：基于開源Prometheus技術(shù)自主研發(fā)。

目前分布式監(jiān)控平臺已于11月初在G行投產(chǎn)，實(shí)現(xiàn)G行容器云生產(chǎn)集群的全面監(jiān)控，實(shí)現(xiàn)海量對象的秒級處理，日均處理T級數(shù)據(jù)，告警準(zhǔn)確率和召回率均為100%，系統(tǒng)運(yùn)行穩(wěn)定，監(jiān)控效果符合預(yù)期。

六、后繼工作展望

平臺一期建設(shè)實(shí)現(xiàn)了容器云及云上應(yīng)用和服務(wù)的監(jiān)控，接下來會擴(kuò)大分布式監(jiān)控的納管范圍，實(shí)現(xiàn)分布式數(shù)據(jù)庫、全棧云管理平臺、分布式消息等的監(jiān)控納管。

監(jiān)控自服務(wù)化能力建設(shè)，封裝有一些自服務(wù)監(jiān)控場景：比如監(jiān)控的上下線、監(jiān)控規(guī)則修改、個性化監(jiān)控配置等。

監(jiān)控評價(jià)功能，以量化的方式展示分布式系統(tǒng)的監(jiān)控覆蓋率和標(biāo)準(zhǔn)化率，以評促改，形成閉環(huán)。

分布式監(jiān)控工具自身優(yōu)化，比如Prometheus負(fù)載的自動平衡，基于一些預(yù)警數(shù)據(jù)，智能擴(kuò)縮Prometheus的實(shí)例個數(shù)，自動分配采集對象，達(dá)到最佳的監(jiān)控能力。

與自動化運(yùn)維操作平臺進(jìn)行聯(lián)動，實(shí)現(xiàn)一些場景的自動化處置。