大家好，又見面了，
說到監控告警平臺，大家應該都不會陌生，對于線上系統而言可以說是個標配，各個公司或專案也都會有搭建自己的監控告警平臺的實際訴求，
當前比較主流的監控告警平臺實作方案，很多都是基于Prometheus + Grafana + AlertManager來實作的，但是實際使用的時候會發現不易實施：
-
在運維部署對接方面存在一些不便，接入新的被監控節點時需要到平臺部署機器上去修改組態檔、甚至重啟服務來生效
-
配置告警規則等也是基于xml配置，必須要到平臺服務器上去添加檔案，對于一個各專案通用的平臺而言，顯然不可能將后端服務地址暴露讓各業務負責人員去自行修改服務器上的組態檔
-
Grafana界面相對單一、可以用于看板或者大屏展示，但是一些公司內高度定制化的頁面能力實作起來會比較麻煩（當然也可以基于Grafana二次開發定制），或者想在公司已有的運維平臺中深度集成，實作難度較大，
前段時間研究了下基于Prometheus構建監控系統相關的概念，并以此為基準設計了一個企業級通用的監控告警平臺的方案，這里分享一下架構的分析程序以及上述問題的解決思路，
平臺與業務職責規劃
既然是構建通用平臺，就會涉及到平臺與業務的職責劃分的問題，這條線究竟按照什么尺度去畫，究竟將平臺做厚還是做薄，將直接決定了平臺的整體定位：
- 平臺做的太厚重，勢必導致業務使用的約束增加、且定制化能力減弱，適用范圍受限；
- 平臺做的太輕薄，業務雖然有更多的主導權與定制靈活度，但也導致各個業務需要重復構建相關能力，平臺將失去意義，
從構建通用平臺的角度而言，很明顯厚平臺方案更具優勢，可以統一整個公司各個業務的監控水平、可以持續的匯聚能力、積累沉淀，
所以，最終選擇采用厚平臺模式來構建：
- 集成資料存盤、統計、告警策略、告警推送等能力，業務僅負責埋點資料上報即可，
- 告警能力擴展性強，全業務無差別共享
- 業務接入簡單，但平臺實作作業量較大
- 業務可以有限定制，但是需要基于管理界面上去配置規則，受平臺規則支持度限制
用戶場景訴求分析
先分析下對監控平臺的一個整體的訴求情況、以及監控平臺需要支持的一些核心業務場景，
從用戶角度，收集下不同角色的人員的訴求：
-
管理人員：
- 掌控全域整體情況
- 可以按照不同維度查看（比如按照部門、按照專案、按照負責人等維度進行查看）
-
開發人員：
- 知曉自己負責的專案的狀態
- 若有例外能第一時間收到告警通知
- 可定制自己專案的告警規則與告警接收人員
-
運維人員：
- 查看負責的所有機器情況
- 部署接入簡單
- 中間件可以一鍵接入，不要有額外的部署安裝操作
- 監控平臺自身的穩定與可靠
總結下來，用戶層面對系統的訴求點主要有：
能用：能查看整體情況、能劃分權限控制、能接收告警
易用：業務接入簡單、方便自定義規則
選型與整體設計
作為監控平臺，當前主流的一個方案就是Prometheus + Grafana + AlertManager的配套，本次方案也使用此常規配套，
關鍵設計點：
-
由于
prometheus采用組態檔的方式管理資料采集、告警規則等，為方便使用，設計搭建配置界面與配套服務，負責web端修改配置，server端寫入prometheus組態檔中的邏輯、中間件探針自動啟動部署等能力， -
考慮到
prometheus告警推送通道有限、因此設計了訊息推送服務，提供rest介面接收prometheus的告警推送，然后轉發到現有的微信推送通道中，實作在微信上接收告警， -
通常
Prometheus探針會部署到被監控的行程所在機器上，較為分散，維護難度較大，對于常見的各種中間件的資料采集探針，采用集中服務器部署的方案，通過web下發命令部署對應中間件的探針服務，
最終整體構建的全貌圖如上所示，橙色的部分為使用開源組件實作，綠色部分為自行構建，作為輔助能力，打通平臺的輔助操控能力，降低用戶的使用門檻，
關鍵點設計
監控平臺管理界面方案
作為與用戶層面打交道的門面，管理界面端的實作既要承載用戶維度的基本使用訴求，更是解決前述說的Prometheus + Grafana + AlertManager使用配置與規則定制門檻過高的關鍵一環，
基于Prometheus構建的監控平臺中，很多都是標配了Grafana作為界面展示，但是Grafana作為通用開源組件，側重點在dashboard展示能力上，其余一些管理能力較為榷訓，
所以在界面的規劃上，采用的策略是繼續以現有的運維平臺界面為主，設計整合grafana的dashboard展示能力，也即對用戶而言，入口都是運維平臺Poral，一些規則配置、部署操作等統一由運維平臺portal提供，只是點擊查看某個專案的資料時，跳轉到Grafana展示，
分層、分組告警實作機制
作為一個監控告警平臺，告警能力自然是最關鍵的一個部分，此部分使用Prometheus已有能力，
具體實施時，為了實作告警的按需推送、精準推送，規劃在Prometheus配置采集探針資料的時候，為每個探針配置對應的標簽資料，比如專案組、系統、模塊、環境型別等等資訊，這樣就可以進一步按照專案組或者系統維度進行推送給相關人員，
此處規劃是在prometheus拉取探針服務的地方進行配置追加固定分組tag資訊，而不是由各個探針的指標項中自己上報，主要也是從平臺統一控制維度進行考量，
對接告警通道設計
Prometheus實作告警有2種可選方案：
- 對接
Prometheus AlarmManager組件， 通過修改服務器上的本地組態檔，實作告警規則的設定； - 對接
Grafana，使用Grafana告警功能，直接在Grafana的界面指標項中進行配置，
其實，不管是Prometheus AlertManager還是Grafana，其配置都需要遵循一定的規則，對于沒接觸過的人而言，還是有一定的使用門檻的，而且兩種配置起來都很不方便，尤其是AlertManager，還得登錄部署服務器上去新增或修改組態檔 —— 這個作為一個平臺，顯然是不可接受的，
所以，從功能與便捷性角度考慮，選定使用AlertManager實作告警能力，作為對其弊端的補償，規劃構建管理配置服務，并在平臺統一Portal上提供無門檻易用的配置能力，如下：
用戶通過界面上配置好之后，變更的組態檔經由管理配置服務中轉，自動寫入AlertManager對應組態檔中，由此避免人為修改AlertManager服務端組態檔可能引發的問題，
AlarmManage預置的告警通道主要有郵箱、釘釘、企業微信、或者webhook等，出于可自由定制、以及后續可自由定制的角度觸發，此處選擇采用webhook的方式：
- 新開發一個
webhook告警接收服務，提供rest介面用來接收告警資訊； - 對接收到的告警資訊進行處理后，呼叫當前監控平臺提供的微信告警推送介面，推送給用戶，
部署與運維管理策略
基于Prometheus的機制，資料上報采用探針的方式暴露相關介面，然后Prometheus定時輪詢拉取，
對于探針的部署，考慮可選常規模式與集中模式兩種，
常規模式：
各業務、各中間件節點自行部署自己的探針服務，
集中模式：
各中間件的探針服務集中部署，打通web端配置邏輯，根據自動部署探針服務，
從實施作業量上進行評估，最終敲定混合使用兩種模式：
- 中間件監控，采用集中部署，作為平臺能力一部分，集中監管，
- 各業務監控，采用常規模式，各個業務自行定制提供探針服務并部署，
關于中間探針集中部署：
- 將各常見中間件的exporter包安裝到服務器上
- 根據web傳過來的被監控中間件的型別
- 執行命令，z啟動對應探針
- 為了后續可維護，將啟動命令寫入腳本檔案中，設定開機自啟動
- 相關配置資訊、每個exporter系結的port資訊以及監控的中間件資訊，保存到DB中，便于維護，
高可用設計
作為一個用來監控其他服務是否正常的告警平臺，其自身的高可用性顯然是必須要考慮的事情，一旦監控平臺掛掉，業務出問題可能就無法第一時間通知到責任人，很容易引發線上事故，
對整個平臺的高可用設計，采用分模塊不同的策略：
Prometheus
高可用：冗備方案，部署2套prometheus行程，兩套prometheus采集相同的探針節點，擁有完全相同的配置資料，
可擴展：分片策略，當監控物件數量太多時，將監控物件分片，每個分片部署一套(2個行程)prometheus服務，實作水平無限制擴展，
AlarmManager
高可用、可擴展：集群部署，多個prometheus行程發送到AlarmManager Cluster中的重復告警資訊，最終只會有1條告警會被發送出去，
配置部署服務
高可用、可擴展：集群部署，部署多個行程節點，對外提供統一訪問地址，
探針服務
非監控平臺主體，不做高可用保證，宕機會有告警，滿足要求，
總體回顧
回顧下整個方案的分析與設計程序，其實整體邏輯很簡單，選型確定之后，根據選型結果，以及選型與目標訴求之間的差異度，考慮如何抹平兩者之間的差異，也即所謂的“不忘初心、以始為終”，
按照上述策略搭建完成后，整體的監控平臺的功能全貌為如下：
我是悟道，聊技術、又不僅僅聊技術~
如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新，
期待與你一起探討，一起成長為更好的自己，
本文來自博客園，作者：架構悟道，歡迎關注公眾號[架構悟道]持續獲取更多干貨，轉載請注明原文鏈接：https://www.cnblogs.com/softwarearch/p/16435280.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/498992.html
標籤：其他
上一篇：設計模式之概述篇