prometheus告警流程分析
以 sum(rate(coredns_dns_requests_total[1m])) > 100 为例
- alert和record复用大部分逻辑
- prometheus根据配置文件中拿到规则
- 解析规则查询本地存储或远端存储(带触发条件)，trigger在存储端
- 返回一组当前点结果集，返回多少个对应多少条告警
- 根据内存中的历史数据判断告警持续时间(for 1 min)有没有到达
- 发送告警event给alertmanager
- 由alertmanager做告警的发送、静默、分组路由、关联、回调
夜莺（Nightingale）告警流程分析
- monapi 定时从db同步策略，judge 根据自己的ident 拿到属于自己的策略
- transfer根据存活的judge 拿到所有策略，将策略的judge地址填好
- transfer收到 agent push的数据后，算hash拿到策略列表
- 根据策略拿到judge地址，根据缓存拿到对应的队列，将数据塞入队列中
- judge收到策略后，根据策略中的fun做触发
- 根据策略中配置实现 发送时间、告警升级、回调等
push/pull 模型对比
| 模型 | 系统 | 阈值判断 | 是否支持多series告警 | 触发条件 | 组合条件 | nodata |
|---|---|---|---|---|---|---|
| push | 夜莺v4 | 由judge接收 点触发判断， 查询本地数据 |
不支持，每个策略针对 单一series 对应judge中 内存列表 只能用预聚合解决 |
将happen、all、 any等和聚合 avg、 max、 min等揉在一起 |
需做pull | 需做pull |
| pull | prometheus | 由promql 查 询存储 |
promql直接支持 查询到一个 就是一条，多个就是多条 |
prometheus触发条件 只支持 持续时间， 其他的全部为聚合func |
promql and支持 |
promql absent支持 |
告警push模式的性能提升问题
相比于性能损耗，pull模型带来的灵活性是巨大的
- push型的告警模式无疑会带来性能提升
- 因为pull模型需要每次查询存储，虽然是当前点，但也有些损耗
- 但
- 现代的tsdb 有倒排索引+布隆过滤器的加持，告警查询损耗可以降到很低
- pull模型带来的是非常灵活的触发表达式，从这点看，性能损耗可以忽略不计
- 现在告警触发时都需要带上一些聚合的方法，这点push模型做不到
在夜莺中引入pull的问题
- 最大的动力是否是相中了promql
- 存储和采集不支持promql
- 触发和聚合混在一起