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

隨著分布式云原生、容器化、微服務(wù)、大數(shù)據(jù)技術(shù)的成熟和普及，生產(chǎn)系統(tǒng)架構(gòu)朝著微服務(wù)、容器化方向改造，這給監(jiān)控運(yùn)維帶來(lái)如下問(wè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)境的動(dòng)態(tài)性變強(qiáng)：分布式對(duì)象動(dòng)態(tài)可變，例如容器和pod創(chuàng)建、銷毀、遷移，傳統(tǒng)監(jiān)控工具無(wú)法處理云環(huán)境下對(duì)象的動(dòng)態(tài)發(fā)現(xiàn)和更新，無(wú)法提前配置。
• 監(jiān)控?cái)?shù)據(jù)量急劇增多：監(jiān)控指標(biāo)數(shù)量隨著容器規(guī)模增長(zhǎng)呈爆炸式增長(zhǎng)，海量監(jiān)控對(duì)象的高頻采集和處理成為一個(gè)新的挑戰(zhàn)。
• 業(yè)務(wù)架構(gòu)趨于復(fù)雜：云原生應(yīng)用架構(gòu)下，原有單體系統(tǒng)變成了眾多微服務(wù)的協(xié)作，單個(gè)用戶請(qǐng)求會(huì)經(jīng)過(guò)多個(gè)微服務(wù)應(yīng)用，形成復(fù)雜的調(diào)用鏈路，這給問(wèn)題排查和定位帶來(lái)了困難和挑戰(zhàn)。

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

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

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

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

下面我們會(huì)逐一介紹。

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

在分布式監(jiān)控標(biāo)準(zhǔn)梳理過(guò)程中，我們采用如下四個(gè)原則，產(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)一：無(wú)論傳統(tǒng)平臺(tái)還是容器云平臺(tái)，對(duì)于同一個(gè)類對(duì)象的監(jiān)控標(biāo)準(zhǔn)要統(tǒng)一，確保指標(biāo)全覆蓋。
• 同類對(duì)標(biāo)：對(duì)于相同類型的監(jiān)控對(duì)象，需對(duì)標(biāo)原有相似類型的監(jiān)控對(duì)象。如新引入的開(kāi)源中間件需對(duì)標(biāo)傳統(tǒng)的WebLogic監(jiān)控標(biāo)準(zhǔn)。
• 持續(xù)優(yōu)化：敏捷迭代、持續(xù)補(bǔ)充和完善原有監(jiān)控規(guī)范。

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

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

三、平臺(tái)概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adapter工作示意圖

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

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

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

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

五、總結(jié)

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

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

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

六、后繼工作展望

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

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

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

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

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