告警规则引擎服务概述
1. 什么是规则引擎
规则引擎是一种嵌套在应用程序种的组件，它实现了将业务规则从应用程序代码中分离出来，
使复杂的业务规则实现变得简单，也可以动态修改业务规则，从而快速的响应需求变更。
image.png
2. 常见报警规则设计
2.1 Cat
基本逻辑流程
- 查询当前告警类型配置的所有告警规则
- 每间隔一分钟，取对应类型的报表，如果transaction类型的告警，就取transaction类型的报表，event类型的，就取event类型的报表，根据报表里面的duration（key=当前分钟，value=生成的次数）去校验是否触发告警规则，如果触发，则返回告警实例。
- 将上一步返回的告警实例，插入到AlertMananger内部队列里
- AlertManager 异步线程消费告警实例。根据类型、分组、级别（warn、error）查询对应的发送通道（email、sms、weixin），无论发送成功与否，都要写入数据库。（这里没有记录发送成功与否的状态，算是个bug）
image.png
2.2 Open-Falcon
image.png
transfer，接收客户端发送的数据，做一些数据规整，检查之后，转发到多个后端系统去处理。在转发到每个后端业务系统的时候，transfer会根据一致性hash算法，进行数据分片，来达到后端业务系统的水平扩展。
报警判定，是由judge组件来完成。用户在web portal来配置相关的报警策略，存储在MySQL中。heartbeat server 会定期加载MySQL中的内容。judge也会定期和heartbeat server保持沟通，来获取相关的报警策略。
heartbeat sever不仅仅是单纯的加载MySQL中的内容，根据模板继承、模板项覆盖、报警动作覆盖、模板和hostGroup绑定，计算出最终关联到每个endpoint的告警策略，提供给judge组件来使用。
transfer转发到judge的每条数据，都会触发相关策略的判定，来决定是否满足报警条件，如果满足条件，则会发送给alarm，alarm再以邮件、短信、米聊等形式通知相关用户，也可以执行用户预先配置好的callback地址。
用户可以很灵活的来配置告警判定策略，比如连续n次都满足条件、连续n次的最大值满足条件、不同的时间段不同的阈值、如果处于维护周期内则忽略 等等。
另外也支持突升突降类的判定和告警。
2.3 滴滴夜莺
告警资料 https://www.bookstack.cn/read/Nightingale/3972cc67c6123806.md
image.png
https://s3-gz01.didistatic.com/n9e-pub/video/n9e-arch-intro.mp4
-
collector 即 agent，可以采集机器常见指标，原生支持日志监控，支持插件机制，支持业务通过接口直接上报数据；
-
transfer提供 rpc 接口接收 collector 上报的数据，然后通过一致性哈希，将数据转发给多台tsdb和多台judge；
-
tsdb 即 open-falcon 中的 graph 组件，用于存储历史数据，支持配置为双写模式提升系统容灾能力，tsdb 会把监控数据转发一份给 index 建索引；
-
index 是内存索引模块，替换原来的 mysql 方案，在内存里构建索引，便于后续数据检索，在检索的灵活性和检索性能方面大幅提升；
-
judge 是告警引擎，从 monapi(portal) 同步监控策略，然后对接收到的数据做告警判断，如满足阈值，则生成告警事件推送到 redis 队列；
-
monapi(alarm) 从 redis 队列中读取 judge 生成的事件，进行二次处理，补充一些元信息，生成告警消息，重新推送回 redis 队列；
-
各发送组件，比如 mail-sender、sms-sender 等，从 redis 读取告警消息，发送告警，抽象出各类 sender 是为了后续定制方便；
-
monapi 集成了原来多个模块的功能，提供接口给 js 调用，api 前缀为 /api/portal，数据查询走 transfer，去除了 open-falcon 中原来的 query 组件，api 前缀为 /api/transfer，索引查询的 api 前缀 /api/index，于是，在前端统一搭建 nginx，即可通过不同 location 将请求转发到不同后端；
-
数据库仍然使用 MySQL，主要存储的内容包括：用户信息、团队信息、树节点信息、告警策略、监控大盘、屏蔽策略、采集策略、部分组件心跳信息等。
对比：Nightingale与Open-Falcon---->告警引擎重构
- Open-Falcon 的告警策略，在监控数据推送上来的同时会触发策略判断，这种「推」的模式优势是策略的判断时效性非常高，但是不利于更高级的告警策略的支持和扩展，比如多条件的组合报警就很难支持。
- Nightingale 转为推拉结合模式，通过推模式保证大部分策略判断的效率，通过拉模式支持了与条件告警和nodata告警；
2.4 prometheus
https://www.jianshu.com/p/af0f98fe7699
image.png
image.png
prometheus一次alert流程 主要包括告警阈值触发、分组（group）、抑制（inhibitor) 、Silencer（静默）、 重复告警延时（Dedup）等。
2.4.1 告警
Prometheus以scrape_interval（默认为1m）规则周期，从监控目标上收集信息。其中scrape_interval可以基于全局或基于单个metric定义；然后将监控信息持久存储在其本地存储上。
Prometheus以evaluation_interval（默认为1m）另一个独立的规则周期，对告警规则做定期计算。其中evaluation_interval只有全局值；然后更新告警状态。
其中包含三种告警状态：
-
inactive：没有触发阈值
-
pending：已触发阈值但未满足告警持续时间
-
firing：已触发阈值且满足告警持续时间
image.png
- Prometheus以5s（scrape_interval）一个采集周期采集状态；
- 然后根据采集到状态按照10s（evaluation_interval）一个计算周期，计算表达式；
- 表达式为真，告警状态切换到pending；
- 下个计算周期，表达式仍为真，且符合for持续10s，告警状态变更为active，并将告警从Prometheus发送给Altermanger；
- 下个计算周期，表达式仍为真，且符合for持续10s，持续告警给Altermanger；
- 直到某个计算周期，表达式为假，告警状态变更为inactive，发送一个resolve给Altermanger，说明此告警已解决。
2.4.2 告警分组、抑制、静默
告警发送给了Altermanger，但是Altermanger并不是把一条从Prometheus接收到的告警简简单单的直接发送出去；直接发送出去会导致告警信息过多，运维人员会被告警淹没；所以Altermanger需要对告警做合理的收敛
2.4.2.1 告警分组的作用
同类告警的聚合帮助运维排查问题
通过告警邮件的合并，减少告警数量
2.4.2.2 告警抑制的作用
消除冗余的告警
2.4.2.1 告警静默的作用
阻止发送可预期的告警
2.4.3 告警延时
分组势必会带来延时；合理的配置延时，才能避免告警不及时的问题，同时帮助我们避免告警轰炸的问题
告警延时涉及的几个主要参数
group_by:分组参数，比如按照[mysql-id]分组
group_wait:分组等待时间，比如：5s
group_interval:分组尝试再次发送告警的时间间隔，比如：5m
Repeat_interval: 分组内发送相同告警的时间间隔，比如：60m
image.png
image.png
image.png
3. Skywalking与prometheus集成
image.png
- skywalking 将指标数据发送kafka
- 告警规则模块监听kafka指标数据，将指标数据转换为prometheus标准的数据写入prometheus target模块
- prometheus模块 从Gateway拉出指标数据，进行处理，
- 程序启动的时候加载默认告警规则，写入到prometheus AlertManager模块
- prometheus AlertManager 模块提供webhook回调地址，由告警规则模块接口控制消息告警
