prometheus告警流程分析 以 sum(rate(coredns_dns_requests_total[1m])) > 100 为例 alert和record复用大部分逻辑 prometheus根据配置文件中拿到规则 解析规则查询本……
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
promqland支持
promql absent支持
告警push模式的性能提升问题
相比于性能损耗，pull模型带来的灵活性是巨大的
push型的告警模式无疑会带来性能提升
因为pull模型需要每次查询存储，虽然是当前点，但也有些损耗
但
现代的tsdb 有倒排索引+布隆过滤器的加持，告警查询损耗可以降到很低
pull模型带来的是非常灵活的触发表达式，从这点看，性能损耗可以忽略不计
现在告警触发时都需要带上一些聚合的方法，这点push模型做不到
在夜莺中引入pull的问题
最大的动力是否是相中了promql
存储和采集不支持promql
触发和聚合混在一起