當(dāng)前比較主流的監(jiān)控告警平臺實現(xiàn)方案，很多都是基于Prometheus + Grafana + AlertManager來實現(xiàn)的。但是實際使用的時候會發(fā)現(xiàn)不易實施：

在運維部署對接方面存在一些不便，接入新的被監(jiān)控節(jié)點時需要到平臺部署機器上去修改配置文件、甚至重啟服務(wù)來生效。

• 配置告警規(guī)則等也是基于xml配置，必須要到平臺服務(wù)器上去添加文件，對于一個各項目通用的平臺而言，顯然不可能將后端服務(wù)地址暴露讓各業(yè)務(wù)負責(zé)人員去自行修改服務(wù)器上的配置文件。

• Grafana界面相對單一、可以用于看板或者大屏展示，但是一些公司內(nèi)高度定制化的頁面能力實現(xiàn)起來會比較麻煩（當(dāng)然也可以基于Grafana二次開發(fā)定制），或者想在公司已有的運維平臺中深度集成，實現(xiàn)難度較大。

前段時間研究了下基于Prometheus構(gòu)建監(jiān)控系統(tǒng)相關(guān)的概念，并以此為基準(zhǔn)設(shè)計了一個企業(yè)級通用的監(jiān)控告警平臺的方案。這里分享一下架構(gòu)的分析過程以及上述問題的解決思路。

一、平臺與業(yè)務(wù)職責(zé)規(guī)劃

既然是構(gòu)建通用平臺，就會涉及到平臺與業(yè)務(wù)的職責(zé)劃分的問題，這條線究竟按照什么尺度去畫，究竟將平臺做厚還是做薄，將直接決定了平臺的整體定位：

• 平臺做得太厚重，勢必導(dǎo)致業(yè)務(wù)使用的約束增加、且定制化能力減弱，適用范圍受限；

• 平臺做的太輕薄，業(yè)務(wù)雖然有更多的主導(dǎo)權(quán)與定制靈活度，但也導(dǎo)致各個業(yè)務(wù)需要重復(fù)構(gòu)建相關(guān)能力，平臺將失去意義。

從構(gòu)建通用平臺的角度而言，很明顯厚平臺方案更具優(yōu)勢，可以統(tǒng)一整個公司各個業(yè)務(wù)的監(jiān)控水平、可以持續(xù)的匯聚能力、積累沉淀。

所以，最終選擇采用厚平臺模式來構(gòu)建：

• 集成數(shù)據(jù)存儲、統(tǒng)計、告警策略、告警推送等能力，業(yè)務(wù)僅負責(zé)埋點數(shù)據(jù)上報即可。

• 告警能力擴展性強，全業(yè)務(wù)無差別共享。

• 業(yè)務(wù)接入簡單，但平臺實現(xiàn)工作量較大。

• 業(yè)務(wù)可以有限定制，但是需要基于管理界面上去配置規(guī)則，受平臺規(guī)則支持度限制。

二、用戶場景訴求分析

先分析下對監(jiān)控平臺的一個整體的訴求情況、以及監(jiān)控平臺需要支持的一些核心業(yè)務(wù)場景。

從用戶角度，收集下不同角色的人員的訴求：

1、管理人員

• 掌控全局整體情況
• 可以按照不同維度查看（比如按照部門、按照項目、按照負責(zé)人等維度進行查看）

2、開發(fā)人員

• 知曉自己負責(zé)的項目的狀態(tài)
• 若有異常能第一時間收到告警通知
• 可定制自己項目的告警規(guī)則與告警接收人員

3、運維人員

• 查看負責(zé)的所有機器情況
• 部署接入簡單
• 中間件可以一鍵接入，不要有額外的部署安裝操作
• 監(jiān)控平臺自身的穩(wěn)定與可靠

總結(jié)下來，用戶層面對系統(tǒng)的訴求點主要有：

• 能用：能查看整體情況、能劃分權(quán)限控制、能接收告警
• 易用：業(yè)務(wù)接入簡單、方便自定義規(guī)則

三、選型與整體設(shè)計

作為監(jiān)控平臺，當(dāng)前主流的一個方案就是Prometheus + Grafana + AlertManager的配套，本次方案也使用此常規(guī)配套。

關(guān)鍵設(shè)計點：

• 由于prometheus采用配置文件的方式管理數(shù)據(jù)采集、告警規(guī)則等，為方便使用，設(shè)計搭建配置界面與配套服務(wù)，負責(zé)web端修改配置，server端寫入prometheus配置文件中的邏輯、中間件探針自動啟動部署等能力。

• 考慮到prometheus告警推送通道有限、因此設(shè)計了消息推送服務(wù)，提供rest接口接收prometheus的告警推送，然后轉(zhuǎn)發(fā)到現(xiàn)有的微信推送通道中，實現(xiàn)在微信上接收告警。

• 通常Prometheus探針會部署到被監(jiān)控的進程所在機器上，較為分散，維護難度較大。對于常見的各種中間件的數(shù)據(jù)采集探針，采用集中服務(wù)器部署的方案，通過web下發(fā)命令部署對應(yīng)中間件的探針服務(wù)。

最終整體構(gòu)建的全貌圖如上所示，橙色的部分為使用開源組件實現(xiàn)，綠色部分為自行構(gòu)建，作為輔助能力，打通平臺的輔助操控能力，降低用戶的使用門檻。

四、關(guān)鍵點設(shè)計

1、監(jiān)控平臺管理界面方案

作為與用戶層面打交道的門面，管理界面端的實現(xiàn)既要承載用戶維度的基本使用訴求，更是解決前述說的Prometheus + Grafana + AlertManager使用配置與規(guī)則定制門檻過高的關(guān)鍵一環(huán)。

基于Prometheus構(gòu)建的監(jiān)控平臺中，很多都是標(biāo)配了Grafana作為界面展示。但是Grafana作為通用開源組件，側(cè)重點在dashboard展示能力上，其余一些管理能力較為弱化。

所以在界面的規(guī)劃上，采用的策略是繼續(xù)以現(xiàn)有的運維平臺界面為主，設(shè)計整合grafana的dashboard展示能力。也即對用戶而言，入口都是運維平臺Poral，一些規(guī)則配置、部署操作等統(tǒng)一由運維平臺portal提供，只是點擊查看某個項目的數(shù)據(jù)時，跳轉(zhuǎn)到Grafana展示。

2、分層、分組告警實現(xiàn)機制

作為一個監(jiān)控告警平臺，告警能力自然是最關(guān)鍵的一個部分。此部分使用Prometheus已有能力。

具體實施時，為了實現(xiàn)告警的按需推送、精準(zhǔn)推送，規(guī)劃在Prometheus配置采集探針數(shù)據(jù)的時候，為每個探針配置對應(yīng)的標(biāo)簽數(shù)據(jù)，比如項目組、系統(tǒng)、模塊、環(huán)境類型等等信息。這樣就可以進一步按照項目組或者系統(tǒng)維度進行推送給相關(guān)人員。

此處規(guī)劃是在prometheus拉取探針服務(wù)的地方進行配置追加固定分組tag信息，而不是由各個探針的指標(biāo)項中自己上報，主要也是從平臺統(tǒng)一控制維度進行考量。

3、對接告警通道設(shè)計

Prometheus實現(xiàn)告警有2種可選方案：

• 對接Prometheus AlarmManager組件， 通過修改服務(wù)器上的本地配置文件，實現(xiàn)告警規(guī)則的設(shè)置。

• 對接Grafana，使用Grafana告警功能，直接在Grafana的界面指標(biāo)項中進行配置。

其實，不管是Prometheus AlertManager還是Grafana，其配置都需要遵循一定的規(guī)則，對于沒接觸過的人而言，還是有一定的使用門檻的，而且兩種配置起來都很不方便，尤其是AlertManager，還得登錄部署服務(wù)器上去新增或修改配置文件 —— 這個作為一個平臺，顯然是不可接受的。

所以，從功能與便捷性角度考慮，選定使用AlertManager實現(xiàn)告警能力。作為對其弊端的補償，規(guī)劃構(gòu)建管理配置服務(wù)，并在平臺統(tǒng)一Portal上提供無門檻易用的配置能力，如下：

用戶通過界面上配置好之后，變更的配置文件經(jīng)由管理配置服務(wù)中轉(zhuǎn)，自動寫入AlertManager對應(yīng)配置文件中，由此避免人為修改AlertManager服務(wù)端配置文件可能引發(fā)的問題。

AlarmManage預(yù)置的告警通道主要有郵箱、釘釘、企業(yè)微信、或者webhook等。出于可自由定制、以及后續(xù)可自由定制的角度觸發(fā)，此處選擇采用webhook的方式：

• 新開發(fā)一個webhook告警接收服務(wù)，提供rest接口用來接收告警信息；

• 對接收到的告警信息進行處理后，調(diào)用當(dāng)前監(jiān)控平臺提供的微信告警推送接口，推送給用戶。

4、部署與運維管理策略

基于Prometheus的機制，數(shù)據(jù)上報采用探針的方式暴露相關(guān)接口，然后Prometheus定時輪詢拉取。

對于探針的部署，考慮可選常規(guī)模式與集中模式兩種。

1）常規(guī)模式

各業(yè)務(wù)、各中間件節(jié)點自行部署自己的探針服務(wù)。

2）集中模式

各中間件的探針服務(wù)集中部署，打通web端配置邏輯，根據(jù)自動部署探針服務(wù)。

從實施工作量上進行評估，最終敲定混合使用兩種模式：

• 中間件監(jiān)控，采用集中部署，作為平臺能力一部分，集中監(jiān)管。

• 各業(yè)務(wù)監(jiān)控，采用常規(guī)模式，各個業(yè)務(wù)自行定制提供探針服務(wù)并部署。

關(guān)于中間探針集中部署：

• 將各常見中間件的exporter包安裝到服務(wù)器上

• 根據(jù)web傳過來的被監(jiān)控中間件的類型

• 執(zhí)行命令，z啟動對應(yīng)探針

• 為了后續(xù)可維護，將啟動命令寫入腳本文件中，設(shè)定開機自啟動

• 相關(guān)配置信息、每個exporter綁定的port信息以及監(jiān)控的中間件信息，保存到DB中，便于維護。

5、高可用設(shè)計

作為一個用來監(jiān)控其他服務(wù)是否正常的告警平臺，其自身的高可用性顯然是必須要考慮的事情。一旦監(jiān)控平臺掛掉，業(yè)務(wù)出問題可能就無法第一時間通知到責(zé)任人，很容易引發(fā)線上事故。

對整個平臺的高可用設(shè)計，采用分模塊不同的策略：

1）Prometheus

• 高可用：冗備方案。部署2套prometheus進程，兩套prometheus采集相同的探針節(jié)點，擁有完全相同的配置數(shù)據(jù)。

• 可擴展：分片策略。當(dāng)監(jiān)控對象數(shù)量太多時，將監(jiān)控對象分片，每個分片部署一套(2個進程)prometheus服務(wù)，實現(xiàn)水平無限制擴展。

2）AlarmManager

• 高可用、可擴展：集群部署。多個prometheus進程發(fā)送到AlarmManager Cluster中的重復(fù)告警信息，最終只會有1條告警會被發(fā)送出去。

3）配置部署服務(wù)

高可用、可擴展：集群部署。部署多個進程節(jié)點，對外提供統(tǒng)一訪問地址。

4）探針服務(wù)

非監(jiān)控平臺主體，不做高可用保證，宕機會有告警，滿足要求。

五、總體回顧

回顧下整個方案的分析與設(shè)計過程，其實整體邏輯很簡單，選型確定之后，根據(jù)選型結(jié)果，以及選型與目標(biāo)訴求之間的差異度，考慮如何抹平兩者之間的差異。也即所謂的“不忘初心、以始為終”。

按照上述策略搭建完成后，整體的監(jiān)控平臺的功能全貌為如下：

? ?