一、建設背景和問題

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

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

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

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

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

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

下面我們會逐一介紹。

二、分布式標準制定

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

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

分布式指標體系層級圖

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

三、平臺概述

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

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

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

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

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

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

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

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

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

四、平臺關鍵技術點

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

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

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

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

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

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

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

2、標準化和自服務化

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

分布式監(jiān)控標準模型圖

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

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

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

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

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

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

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

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

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

Adapter工作示意圖

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

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

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

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

五、總結(jié)

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

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

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

六、后繼工作展望

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

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

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

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

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

原文地址：https://mp.weixin.qq.com/s?__biz=MzkwOTIxNDQ3OA==&mid=2247567153&idx=1&sn=f6cbcf2b3899e0de082f2e867adbcd6c&utm_source=tuicool&utm_medium=referral