一、背景介绍
我们知道 Zabbix 在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，思必驰引入了 Prometheus 技术.并和 OpsMind 共同研发了一整套监控平台和分级告警配置引擎系统。
思必驰的监控系统的演进经过如下几个阶段：
- 人肉堆积阶段——采用比较原始的模式，例如系统监测采用 Zabbix,网络监测采用 Cacti 等，八仙过海各显神通，所有的数据都是一个个海上孤岛。
- 平台化建设——当意识到以上问题时，开始了新一代监测系统的平台化建设，首先是去 ZC,把整个监测系统的技术栈统一到 Prometheus。
- 监测数据的分析和统计——当数据汇总以后，很多之前割裂的信息达到空前的整合，可以基于海量的监测数据进行大数据分析，例如容量评估等。
- 研发和运维共同合作阶段——把研发和运维有机的结合在一起，因为统一了技术栈，而 Prometheus 的技术特性天生为研发帮助运维改进系统可靠性提供的有利的保障，可以用不同开发语言来进行埋点，上报各种个性化的监测需求。
- 平台可控性建设——因为有了强大监测系统，便可以洞悉整个站点，使 SRE 成为可能。
二、平台建设目标
建设新一代监控平台我们需要什么？
多样化的自主接入
接入的数据将不再只局限于基础监测，网络监测，而且从不同的角度来洞悉整个系统，那么你就需要方便可靠的监测数据采集系统。
指标的灵活配置
监测指标海量以后随之带来的则是配置问题，不同的监测指标有不同的度量值，不再是以前简单的逻辑运算，会变得相当复杂。
监测指标的可视化
把海量的监测指标有机的结合起来，针对某个系统来进行集中的 Dashboard 展示，或者是详尽的可视化的问题排查。
告警的配置和分级通知
为了避免告警风暴，让最有价值的告警信息出现并通知到相关的部门和小组，需要对不同告警对象进行分级管理。
平台的扩展能力
原生的 Prometheus 并没有一个很好的企业级解决方案，并且不支持集群化，需要管理和优化 Prometheus 进行企业平台的开发
通过引入 Prometheus 的企业级解决方案，辅以二次开发，以上问题得以跨越。
- 提升 Prometheus 的各项能力。
- Agent 采用无侵入方式，不用卖点。
- 告警配置自助化和完全下放。
三、建设过程
今天我们主要讲一下告警配置引擎。
告警的通知形式
绝大部分公司，可能都没有考虑系统监控告警策略，一旦发生异常，就发邮件/短信通知系统负责人，这样可能导致这样一些问题：
同一个集群的不同实例出问题，可能会造成重复告警，浪费带宽资源，升高短信成本；
系统负责人短时间内手机被告警短信刷屏，导致产生麻木感；
系统负责人短时间内手机，邮箱，钉钉，微信同时对一个故障告警，导致产生巨大压力；
员工不重视告警，无法判断告警的优先级，Leader 又不知情，导致事故影响扩大；
告警的通知渠道
目前传统的四种文字告警的方式，其成本，到达率，实时性都不一样：
短信：成本高，实时性好，到达率高
邮件：成本低，实时性差，到达率高
钉钉/微信：成本低，实时性中，到达率中
为了解决上述问题，针对不同的服务，在不同的时间段，不同的员工层级，应该设定不同的告警策略，我们采用了 OpsMind 设计的告警配置引擎。他主要解决以下几个问题：
- 告警频率收敛策略：对同一个服务或者接口，应该在固定的时间内，只发送有限的告警，常见的方式是，按照1分钟1次限制告警次数，一来降低研发的紧张感与压力感，二来节省计算成本。
- 不同时段区分告警方式策略：工作日工作时段在公司时，通过邮件/钉钉/微信发送告警能更加节省成本；半夜或者周末发生故障时，通过邮件发送告警能保证实时性；另外可以通过时间段的设置屏蔽部分服务自动重启时所带来的误告警。
- 逐层上报告警策略：每个模块都应该有负责人，原则上告警会发送给模块的负责人，但如果告警连续一小时未恢复正常，告警会自动发送给系统负责人的直属 Leader，如果告警连续一个小时未恢复正常，告警会自动发送给系统负责人的二级 Leader。
- 黑白跳动策略：当系统由正常变为异常，异常恢复正常，出现正反的变化时，都应该发出告警。
- 告警分级策略：针对不同的告警对象设置不同的触发阈值，并推送对应负责人。实现一个指标项的告警规则在一个策略里完成配置。
- 筛查告警策略：通过存储引擎层面的扫描，筛查已经失效的告警策略，并通知负责人，做到重要告警不漏报。
四、总结
统一监控平台，不能一异常就告警，太不人性化，要实现统一的分级告警策略；
不同时段区分告警方式策略：工作日/非工作日，白天/夜晚区分；
逐层上报告警策略：先模块负责人告警，n 分钟未恢复升级，m 分钟未恢复再升级；
黑白跳动策略：当系统由正常变为异常，异常恢复正常都通报；
告警筛查：自动筛查失效的告警策略，避免漏报。
