當企業的業務發展到一定的階段時，在系統中引入監控告警系統來對系統/業務進行監控是必備的流程。沒有監控或者沒有一個好的監控，會導緻開發人員無法快速判斷系統是否健康；告警的實質則是“把人當服務用”，用告警通知人的方式去幹預系統達到修正的目的。
監控告警在企業保障系統的穩定性和事故快速恢複的全周期鍊路中都是至關重要的一環。在新版本的 EasyMR 中袋鼠雲開發團隊也對監控告警功能進行了全新的優化，通過本文和大家分享一下監控告警功能的設計思路以及碰到各類問題痛點的解決方法。
EasyMR 監控告警設計
對于 EasyMR 的監控告警設計思路，考慮到 Zabbix 後端資料庫使用 MySQL 對監控資料進行存儲，無法滿足多元度化的告警。而 openfalcon 整體架構上吸取了 Zabbix 的經驗，解決了 Zabbix 的不足之處，但是社群活躍度不高。
是以我們選擇了內建 Prometheus+Grafana 的解決方案搭建 EasyMR 的監控系統，這套解決方案是目前主流的方案，使用的人群較多，在推廣使用上會降低門檻而且容易維護，也适合袋鼠雲平台的容器化部署。整體架構圖如下：
首先我們在這套平台的基礎上增加了一個 dt-alert 元件用來對接第三方的告警發送的處理，其次我們對 Grafana 進行了少量的二次開發。開發的内容主要在于打通 EasyMR 平台的告警通道和 Grafana 上的通道的對接，平台接入好主機和部署好服務後 Prometheus 就能通過服務發現的方式完成目标抓取作業的生成擷取監控資料。
Grafana 從 Prometheus 中擷取名額資料進行展示，同時觸發告警時将告警内容發到 dt-alert 元件中，dt-alert 元件将告警資訊發往第三方平台上。
EasyMR 監控告警痛點
基于上述告警監控的解決方案是否就是一個非常完美的方案呢，答案當然是否定的，接下來我們就讨論一下在使用此方案的過程中遇到的問題和痛點：
● 低版本 Grafana 漏洞頻發
低版本 Grafana 漏洞頻發，導緻平台安全問題受到很大的挑戰。漏洞是指計算機系統安全方面的缺陷，會使得系統或其應用資料的保密性、完整性、可用性、通路控制等方面面臨威脅。由于早期版本的 EasyMR 是基于 Grafana5.3 版本做的二次開發，是以被掃描出來的漏洞非常多，遇到相應漏洞時隻能想辦法規避。
● 缺少分級告警
缺少分級告警，無法區分不同嚴重程度的告警。對于運維人員來說，監控告警是用來發現故障用的，但是存在一個問題，如果一個系統中所有的告警都是同一個級别，那麼出現問題時，可能會同時出現很多的告警，告警沒有分級不光會造成告警過多，還會讓開發人員無法區分優先級，導緻無法優先處理更緊急的問題。
● 無法對同一個儀表盤設定多條告警規則
由于我們是使用 Grafana 來設定告警規則，在老版本中同一個 panel 隻能設定一條告警規則，如果我們想針對同一個監控名額設定多個告警規則的話隻能建立一個相同名額的 panel 再設定新的告警規則，這在使用上來說是非常不便利的。
EasyMR 監控告警優化解決方案
基于以上三點痛點，袋鼠雲開發團隊在新版本的 EasyMR 中，将 Grafana 版本從 5.3.x 更新到了 8.5.x，新版本可以非常順利地解決上述問題。基于新版本的二開前後端為了将 Grafana 很好的嵌入 EasyMR 産品頁面中，做了很多的優化工作，包括但不限于隐藏側邊欄、隐藏 Grafana 一級菜單、取消 title 點選事件隐藏相關資訊等等。
● 優化前
● 優化後
如何配置 EasyMR 新版本告警規則
接下來給大家詳細介紹一下如何配置新版本 EasyMR 的告警規則。
● 選中儀表盤
選擇儀表盤，以 cpu_usage 告警為例，選中 Host_Overview。
● 選中面闆
在 System->cpu_usage 面闆中點選下拉菜單，選中 Edit 選項。
● 建立告警
選中 Alert 項，點選建立告警規則。
編輯告警規則，告警參數參考如下模闆，參數确認無誤後點選儲存。
● 自定義告警模闆
以 Redis 告警為例，在 Prometheus 查詢的值為：
自定義模闆可以引用标簽和值變量：
釘釘告警示例如下：
《資料治理行業實踐白皮書》下載下傳位址：https://fs80.cn/380a4b
《數棧V6.0産品白皮書》下載下傳位址：https://fs80.cn/cw0iw1
想了解或咨詢更多有關袋鼠雲大資料産品、行業解決方案、客戶案例的朋友，浏覽袋鼠雲官網：https://www.dtstack.com/?src=sztth
開源項目位址：https://github.com/DTStack