当企业的业务发展到一定的阶段时，在系统中引入监控告警系统来对系统/业务进行监控是必备的流程。没有监控或者没有一个好的监控，会导致开发人员无法快速判断系统是否健康；告警的实质则是“把人当服务用”，用告警通知人的方式去干预系统达到修正的目的。

监控告警在企业保障系统的稳定性和事故快速恢复的全周期链路中都是至关重要的一环。在新版本的 EasyMR 中袋鼠云开发团队也对监控告警功能进行了全新的优化，通过本文和大家分享一下监控告警功能的设计思路以及碰到各类问题痛点的解决方法。

对于 EasyMR 的监控告警设计思路，考虑到 Zabbix 后端数据库使用 MySQL 对监控数据进行存储，无法满足多维度化的告警。而 openfalcon 整体架构上吸取了 Zabbix 的经验，解决了 Zabbix 的不足之处，但是社区活跃度不高。

所以我们选择了集成 Prometheus+Grafana 的解决方案搭建 EasyMR 的监控系统，这套解决方案是目前主流的方案，使用的人群较多，在推广使用上会降低门槛而且容易维护，也适合袋鼠云平台的容器化部署。整体架构图如下：

首先我们在这套平台的基础上增加了一个 dt-alert 组件用来对接第三方的告警发送的处理，其次我们对 Grafana 进行了少量的二次开发。开发的内容主要在于打通 EasyMR 平台的告警通道和 Grafana 上的通道的对接，平台接入好主机和部署好服务后 Prometheus 就能通过服务发现的方式完成目标抓取作业的生成获取监控数据。

Grafana 从 Prometheus 中获取指标数据进行展示，同时触发告警时将告警内容发到 dt-alert 组件中，dt-alert 组件将告警信息发往第三方平台上。

基于上述告警监控的解决方案是否就是一个非常完美的方案呢，答案当然是否定的，接下来我们就讨论一下在使用此方案的过程中遇到的问题和痛点：

低版本 Grafana 漏洞频发，导致平台安全问题受到很大的挑战。漏洞是指计算机系统安全方面的缺陷，会使得系统或其应用数据的保密性、完整性、可用性、访问控制等方面面临威胁。由于早期版本的 EasyMR 是基于 Grafana5.3 版本做的二次开发，所以被扫描出来的漏洞非常多，遇到相应漏洞时只能想办法规避。

缺少分级告警，无法区分不同严重程度的告警。对于运维人员来说，监控告警是用来发现故障用的，但是存在一个问题，如果一个系统中所有的告警都是同一个级别，那么出现问题时，可能会同时出现很多的告警，告警没有分级不光会造成告警过多，还会让开发人员无法区分优先级，导致无法优先处理更紧急的问题。

基于以上三点痛点，袋鼠云开发团队在新版本的 EasyMR 中，将 Grafana 版本从 5.3.x 升级到了 8.5.x，新版本可以非常顺利地解决上述问题。基于新版本的二开前后端为了将 Grafana 很好的嵌入 EasyMR 产品页面中，做了很多的优化工作，包括但不限于隐藏侧边栏、隐藏 Grafana 一级菜单、取消 title 点击事件隐藏相关信息等等。

接下来给大家详细介绍一下如何配置新版本 EasyMR 的告警规则。