DockOne微信分享（二五六）：哆啦A夢：基於Prometheus的企業監控報警平臺
摘要：我們需要先配置好目標Prometheus Server的url，之後才能將報警規則下發到該Prometheus Server進行計算。A：Prometheus根據報警規則的閾值進行內部計算得來的。
【編者的話】360搜索事業部雲平臺一直致力於將容器技術在生產環境中落地，已開源企業級Kubernetes管理平臺 Wayne ，並經歷了在生產環境大規模應用的考驗。當下Prometheus是被廣泛應用的監控系統，既是容器時代的標配，也同時解決了應用指標監控的問題。然而它的報警模塊alert manager還有一些地方不是很完善，使用起來不夠靈活，針對這一問題，我們開發並開源了哆啦A夢報警平臺。本次分享主要介紹了Prometheus在360搜索雲平臺的落地應用，以及結合哆啦A夢報警平臺的功能實踐。
360 Prometheus架構
Prometheus全部使用容器部署，規模大，採用聯邦架構。容器監控指標和物理機監控指標全部使用Prometheus採集。
Alertmanager的痛點
- 無法動態加載監控規則，需要修改配置文件
- 在使用Alertmanager的時候，需要修改Prometheus的配置文件將Alertmanager與Prometheus相關聯
- 無法實現報警升級，不支持獲取動態值班組，標籤匹配不能動態配置（需要修改配置文件）
總而言之配置不夠方便靈活，需要頻繁修改配置文件，學習成本高。
Doraemon的架構
- Rule Engine：從Alert Gateway動態拉取報警規則，並下發到多個Prometheus Server進行計算，與此同時接收從Prometheus Server發來的報警並轉發給Alert Gateway。
- Alert Gateway：接收從Rule Engine發送的報警，並根據報警策略聚合發送報警信息。
- Web UI：用於運維人員添加報警規則，創建報警策略、維護組，進行報警確認或者查看歷史報警。
術語
報警規則：與Prometheus中的 報警規則 概念相同。
數據源：Prometheus Server的URL，由Rule Engine將報警規則下發至該URL進行計算。
報警接收組：由多個報警接收人組成的組。
值班組：和報警接收組類似，但是它是動態的從接口中獲取組成員的列表。
報警延遲：報警觸發一段時間後纔將報警發送給接收人。
報警週期：報警發送的週期。
報警計劃：由多條報警策略組成的集合。
報警方式：對於內部用戶，可以通過藍信、短信和電話的方式進行報警。非內部用戶可以採用hook的方式將報警轉發到自定義的Web Server進行處理。
報警策略：一條報警策略包含報警延遲、報警週期、報警時間段、報警接收組、值班組以及報警方式等配置信息。
報警確認：如果需要短時間的暫停報警，可以通過勾選相應報警並填寫暫停時長來確認報警。
維護組：如果希望屏蔽一些固定時間段內某些特定機器的報警，可以通過配置報警維護組策略來實現。
使用說明
創建報警計劃
爲報警計劃添加報警策略：一個報警計劃下面可以添加多個報警策略，通過這種方式既可以實現報警的定向發送也可以實現報警的升級。例如下面的報警計劃實現了將含有標籤idc=beijing的報警發給op1，將標籤idc!=beijing的報警發送給op2，並且將所有超過60分鐘還沒有被確認的報警以電話形式通知leader。
- 報警時間段：每天發送報警的時段
- 報警延遲：報警觸發多長時間後纔開始發送報警，可用於實現報警升級
- 報警週期：每隔多少分鐘發送一次報警
- 報警用戶：報警接收人，可以輸入多個報警接收人
- 值班組：從接口動態獲取報警值班人
- 報警用戶組：可以創建報警用戶組，一個報警用戶組包含多個報警接收人
- Filter表達式：通過label來過濾要發送的報警。支持“=”（等於），“!=”（不等於），“&”（與），“|”（或），“(”，“)”這幾種運算符號，並且在保存Filter表達式之前會自動校驗表達式的合法性，對於不合法的表達式會給出提示。例如只發送來自北京或上海機房並且app名稱是search的報警，對應的Filter表達式就是“name=search&(idc=beijing|idc=shanghai)”
- 報警方式：支持hook方式將報警以HTTP POST請求的形式發送至指定報警網關
添加Prometheus信息
我們需要先配置好目標Prometheus Server的url，之後才能將報警規則下發到該Prometheus Server進行計算。
在完成前面兩步之後，就可以添加報警規則了。
添加報警規則
這裏的配置和原生Prometheus的alerting rules配置一樣，對於熟悉Prometheus的同學而言一目瞭然。
上面是Prometheus的配置。
下面是哆啦A夢添加報警規則的配置。
- 監控指標：對應Prometheus的alerting rules中的“expr”
- 報警閾值：expr的閾值
- 持續時間：對應Prometheus的alerting rules中的“for”
- 標題：對應Prometheus的alerting rules中的“summary”
- 描述：對應Prometheus的alerting rules中的“description”
- 數據源：關聯到前面創建的Prometheus Server的信息，即將這條監控規則下發到該Prometheus進行計算
- 策略：關聯到前面創建的報警計劃
報警聚合
哆啦A夢所發送出來的報警都是從報警規則的維度進行聚合的，例如某個報警規則所關聯的報警計劃下面有兩個報警策略，一條策略的報警週期是5分鐘，則該條規則下的所有報警會每5分鐘聚合一次併發送，另一條策略的報警週期是10分鐘，則相應的報警會每10分鐘聚合一次併發送。對於報警恢復的恢復信息會每分鐘聚合一次併發送。對於同一條報警，根據報警策略的不同會以不同的報警延時，不同的報警週期聚合後發送給不同的接收者。
例如如下報警策略：報警持續5分鐘後開始發出第一條報警，每5分鐘發一次。假設在第0、1、2、3、4分鐘的每一分鐘都有2臺不同的機器觸發了rule A的報警，如果不聚合則在5-9分鐘每分鐘都會發出一個報警，每條報警包含兩臺機器的信息。這樣當出現多條rule下的多臺機器一起報警的時候，會出現在短時間內多條rule的報警交替出現，這樣對運維人員不友好，不好辨別這一分鐘裏到底是哪幾條rule觸發的報警。
而聚合後，將在第5分鐘將第0分鐘觸發的報警發出，第10分鐘將第0、1、2、3、4分鐘的報警聚合發出，即每五分鐘聚合一次rule A的報警。如果某個報警在第1分鐘到第9分鐘內觸發，並且在這期間又恢復了，則用戶不會收到報警信息以及報警恢復信息。對於同一條報警，由於報警策略不同，會導致有的用戶可能收到過該條報警，而有的用戶沒有，系統會保證該條報警的恢復信息只會發送給已經收到過該報警的用戶。對於沒有發出的報警可以在報警歷史記錄中查看。
報警確認
有兩種方式進行報警確認，一種是點擊報警信息中的確認鏈接，這種方式是從報警規則的維度進行報警確認的（因爲報警是以報警規則的維度聚合發送的），例如，在報警策略中配置了報警延時爲5分鐘，只接收idc=zzzc和idc=shbt的報警，則點開報警確認鏈接只能看到以及確認滿足該報警策略的報警。也就是說，不同的報警策略所展示的報警確認頁面的內容也是不同的：
另一種報警確認方式是從label的維度進行報警確認，比如IP爲10.0.0.1的機器宕機了，觸發了多條報警規則的報警，此時從報警規則的維度進行報警確認效率很低，但如果從label的維度進行報警確認就會非常方便，因爲含有“instance=10.0.0.1:9090”的報警都是該機器產生的報警我們可以一次性的確認。下圖是從label的維度進行報警確認：
維護組
有些時候可能會有大批量的機器處於維護狀態，或者某些機器在一段時間內出現故障，需要屏蔽來自這些機器的報警，此時就可以將這些機器的instance標籤的值（不含端口號）作爲機器的唯一識別信息加入維護組。
- 維護時間段：屏蔽報警的時間段
- 維護月：屏蔽報警的月份
- 維護日期：在維護月份的哪些天對報警進行屏蔽
- 有效期：維護規則的有效期（過了該時間維護規則自動失效）
- 機器列表：instance標籤的值（去掉端口號），通常爲機器ip
此外，在“歷史報警查看” 頁面可以看到歷史報警。
哆啦A夢的快速部署
哆啦A夢提供了兩種部署方式：一種是基於docker-compose本地部署，由於沒有提供額外的高可用機制，因此這種方式僅用於本地測試。另一種方式是基於Kubernetes集羣部署，用於生產環境。兩種部署方式都非常簡單。
後續計劃
- 支持多租戶。
- Prometheus管理，一鍵部署Prometheus，Prometheus配置、規則管理。
- Grafana面板集成，一鍵部署Grafana，Grafana配置、dashboard管理。
- 預製常用軟件監控、容器監控規則。
- 報警方式支持微信、釘釘、郵件等方式。
該項目會在近期開源，目前在公司內部走開源流程。
Q&A
Q：告警支持哪些平臺的接口呢？自由度怎麼樣呢？可以在產品中，配置定製化的接口的json格式呢？
A：支持hook和公司內部的藍信、短信以及電話，對於公司外部的用戶可以暫時使用hook模式，後續會支持微信、短信、郵件、釘釘。
Q：告警觸發器是如何管理的？
A：Prometheus根據報警規則的閾值進行內部計算得來的。
Q：Prometheus如何對接多個Kubernetes集羣實現集羣Pod的彈性伸縮？
A：利用Kubernetes的HPA通過報警平臺的hook機制來做彈性伸縮。
Q：Kubernetes都需要配置哪些方面基礎告警？kube-prometheus默認的就夠了嗎？
A：默認就是節點監控、Pod監控、Kubernetes默認組件的監控。
Q：Prometheus原生是單點，在告警和存儲方面，哆啦A夢是如何支持集羣模式的？
A：告警的存儲使用MySQL，Prometheus只是用於計算規則的。集羣模式可以使用多個Prometheus進行計算，至於Promeheus的架構由用戶自身決定。
Q：Alertmanager針對的是Group維度的預警，那自研的版本如何去定義這個Group， 是否有新增針對單個對象去推送預警及預警的頻次？
A：哆啦A夢的告警是哆啦A夢內部機制實現，不依賴於Alertmanager的Group。
Q：Prometheus使用過程中存在哪些性能陷阱，能否舉例。如何評估預判Prometheus性能容量？
A：在Prometheus的數據量非常大的時候會有性能瓶頸，特別是在計算直方圖以及採集大量節點的時候，但一般場景下不會有這樣的問題。
Q：Prometheus部署在集羣內還是集羣外，多個集羣的實例如何統一監控告警？是否支持跨集羣應用實例的監控告警？如何實現？
A：哆啦A夢不關心Prometheus是部署在集羣內還是集羣外，只要能通過url訪問即可。目前不支持基於多個Prometheus的告警聚合，後續可以考慮實現。
Q：按剛纔分享的案例看，其實這個系統可以類比爲基於alert rule id --> pageduty的一個大系統麼？
A：實際不是，因爲真正的alerts和發送流程是由哆啦A夢控制的，而不是Prometheus，Prometheus只是負責計算報警規則。
Q：自動恢復這方面有考慮嗎？比如告警觸發對於腳本去自動恢復？
A：自動恢復目前沒有做，這個不同公司不同場景差異很大。用戶可以根據Doraemon發出的報警，自定義恢復邏輯。
以上內容根據2020年4月21日晚微信羣分享內容整理。 分享人 劉恆滔，360服務端開發工程師 。DockOne每週都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesf，進羣參與，您有想聽的話題或者想分享的話題都可以給我們留言。
