夜莺和prometheus监控/pull与push

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
• 触发和聚合混在一起