基于Alertmanager设计告警降噪系统，成本低可落地
时间:2025-11-26 23:40:59 出处:数据库阅读（143）
一 、基于降噪背景
转转基于Prometheus落地了一体化监控系统 ，设计并自研了告警系统 ，系统但研发同学每人每天都会接收到很多告警 ，成本导致重要的落地告警被淹没 ，部分同学会选择直接屏蔽掉所有告警 ，基于降噪进一步加重问题 。设计告警过多等同于没有告警 。系统
另外 ，成本多个告警之间通常具有一定的落地关联性 ，如 ：SQL执行错误告警导致异常日志过多告警 。基于降噪而面对杂乱无章的设计告警 ，很难快速分析出告警的系统根本原因 。源码下载
告警降噪治理十分重要 ，成本在此背景下 ，落地我们基于Alertmanager扩展研发了转转告警中心 。
二 、规范与SDK
2.1 发送告警
Alertmanager提供了告警发送的OpenAPI ，其中 ，告警的labels用于识别同一条告警并对告警去重 、降噪，相同labels的告警的annotations会被覆盖 。startsAt与endsAt分别为告警发生时间与结束时间 。
复制[ { "labels": { "<labelname>": "<labelvalue>",...
}, "annotations": { "<labelname>": "<labelvalue>", }, "startsAt": "<rfc3339>", "endsAt": "<rfc3339>", "generatorURL": "<generator_url>" },...
]1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.一条告警从提交到发送再到接收人的流程大致如下图所示，香港云服务器其中 ，Alertmanager需要集群部署来保证高可用性 ，需要注意的是 ，发送告警时不能对集群做负载均衡 ，必须要对集群内所有的Alertmanager发送告警才能保证高可用性 。
2.2 常用标签
Alertmanager为基于标签的告警降噪 ，需提前规范告警常见标签 。
ENV ：环境 ，如：线上环境 、测试环境APP ：服务名SOURCE ：告警来源 ，如：日志告警 、JVM告警NAME：告警名称LEVEL ：告警等级 ，免费模板如 ：P0告警 、P5告警INSTANCE ：告警实例IPRECEIVER_TYPE ：告警接受者类型RECEIVER ：告警接受者 ，与RECEIVER_TYPE配合使用 ，如RECEIVER_TYPE=邮件 ，RECEIVER即为邮箱地址。Alertmanager标签名的正则规则为[a-zA-Z_][a-zA-Z0-9_]* ，在真正发送通知时 ，最好将标签名做一次中文映射转换 。
2.3 SDK
我们针对Alertmanager开发了发送告警的SDK ，如下所示 ，发送告警非常简单 ，SDK默认会为每条告警自动增加服务名 、环境、IP、服务器租用告警等级 ，并按照接收方拆开为多条告警发送 。每一项内容都是标签 ，其中value较为特殊 ，放在了annotations内 ，其他均放在了labels内用于唯一识别一条告警 。
复制AlertManager alertManager = AlertManager.builder() //告警名称 ，必传
.name("告警Demo") //告警标签 ，拓展信息 ，非必传
.label("label1", "value1") .label("label2", "value2") //告警值，非必传
.value("123") //指定为企业微信告警 ，并指定发送人
.wechat("zhangsan", "lisi") .build();//同步发送告警
alertManager.send();//异步发送 ，默认线程池
alertManager.sendAsync();//自定义线程池发送
ThreadPoolExecutor executor;executor.execute(alertManager);1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.三 、告警降噪
3.1 分组去重
分组机制可以将多条告警信息合并成一个通知 。例如 ，建站模板当集群中有数百个正在运行的服务实例 ，假如此时发生了网络故障 ，结果就会有数百个告警被发送到Alertmanager 。
而作为用户 ，可能只希望能够在一个通知中就能查看哪些服务实例受到影响 。这时可以按照服务所在集群或者告警名称对告警进行分组 ，将这些告警聚合在一起成为一个通知。
Alertmanager可以将收到的告警按照特定的标签分组 、去重 ，并基于以下参数决定何时发送组内的告警通知 ，Alertmanager的每一次通知都会包含当前组内的模板下载所有告警 。
初始等待时间（group_wait）：一组告警第一次发送之前等待的时间 ，用于等待同一组的更多告警合并发送。变化等待时间（group_interval） ：一组已发送初始通知的告警在接收到新告警或有告警恢复后 ，再次发送通知前等待的时间 。重复等待时间（repeat_interval）：一组已发送初始通知的告警 ，组内告警均没有恢复且没有新增告警 ，再次发送通知前等待的时间。下面以一张图 ，来展示从告警产生到合并到某个集合中，到发送通知的整个过程 。三角形和圆形表示不断产生的告警 ，矩形代表实际的通知时间以及告警内容 。
3.2 恢复通知
Alertmanager自带恢复通知，默认5m没有收到告警后 ，告警将被认为恢复 ，然后会等待group_interval后通知给用户 。发送告警时也可以指定告警恢复时间 ，如下所示 ：
复制//告警发生时间
Date startTime = new Date();
//告警结束时间 ，如果在startTime~endTime期间没有告警 ，则认为告警恢复
Date endTime = new Date(new Date().getTime() + 5 * 60 * 1000);
AlertManager.builder().startsAt(startTime).endsAt(endTime)..1.2.3.4.5.需要注意的是，endTime如果小于当前时间 ，会认为告警在发出时就已经恢复 ，这条告警不会通知 。
3.3 告警分级
我们将告警分为P0~P5六个等级 ，告警等级默认取决于服务重要性 ，转转服务按照重要性分了A 、B 、C 、D 、E五个等级 ，服务重要性与告警等级的对应关系 ：A → P1 ，B → P2 ，C → P3 ，D → P4 ，E → P5 。发送告警时也可以指定告警等级 ，如下 ：
复制AlertManager.builder().level(AlertManager.Level.P0)...1.告警分级的目的是尽量让高等级的告警及时发出 ，低等级的告警减少用户打扰次数 。不同等级告警的分组、去重时间均不相同 。
如：P4/P5的告警初始时会等待3m收集告警 ，并将当前告警接收者的所有告警汇总到一条通知内；
P0的告警只会等待15s收集告警 ，并按照告警接收者 、环境 、服务名 、告警来源 、告警名称为维度拆分成多个通知 。
复制route:group_by: [...]receiver: web.hookroutes: - group_by: [_RECEIVER, _RECEIVER_TYPE] group_wait: 3m
group_interval: 10m
repeat_interval: 4h
matchers: - _LEVEL =~ "P4|P5" continue: false - group_by: [_RECEIVER, _RECEIVER_TYPE, _ENV] group_wait: 2m
group_interval: 10m
repeat_interval: 2h
matchers: - _LEVEL = "P3" continue: false # ... 省略P3 、P2 、P1 、P0降噪策略1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.告警等级
分组标签
group_wait
group_interval
repeat_interval
P0
告警接收者 、环境 、服务名 、告警来源 、告警名称
15s
1m
30m
P1
告警接收者 、环境、服务名 、告警来源
30s
5m
1h
P2
告警接收者 、环境、服务名
1m
5m
1h
P3
告警接收者 、环境
2m
10m
2h
P4/P5
告警接收者
3m
10m
4h
3.4 通知合并
统一使用Alertmanager webhook通知 ，一次通知内容会包含分组内的多个报警 ，我们会按照告警相似度对告警做合并，如下为6条报警合并成一条通知 ，其中 ，告警值与服务实例一一对应 。
定义相似度 ：对于多个报警的labels ，只有一个label value不一样 ，剩余的label key与label value均相同 ，则认为相似并合并；一次Alertmanager webhook通知可按照相似度拆分成多种告警 ，不同的告警提取公共标签 ，最终推送到一条通知内 。
如下 ，为4条告警合并到一条通知 ，可清晰的看到两台机器的异常日志报警的原因是由于Druid执行SQL错误导致。
3.5 告警抑制
抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。
当同一个服务 、环境 、告警来源 、IP、接受者 、告警名称 ，同时出现多个等级的告警时 ，高等级的告警会抑制低等级告警的通知 。
如 ：告警名称为FGC次数 ，P1告警阈值为20次，P2告警为10次，当某个实例的FGC次数达到20次以上时 ，只会发送P1告警，不会发送P2告警。
复制inhibit_rules: - source_matchers: - _LEVEL="P4" target_matchers: - _LEVEL="P5" equal: [_APP, _ENV, _SOURCE, _INSTANCE, _RECEIVER, _RECEIVER_TYPE, _NAME] - source_matchers: - _LEVEL="P3" target_matchers: - _LEVEL=~"P4|P5" equal: [_APP, _ENV, _SOURCE, _INSTANCE, _RECEIVER, _RECEIVER_TYPE, _NAME] # ... 省略P2、P1、P0抑制策略1.2.3.4.5.6.7.8.9.10.11.12.四 、多通知机制
支持企业微信 、企业微信群 、短信 、邮件 、电话 、WebHook，可在一个告警内同时指定多种接收方式 ，我们会自动按照接收人拆分成多条告警 。
企业微信、企业微信群 、邮件、WebHook ：最详细 ，发送告警与恢复通知 。短信 ：相对以上，只是不会发送恢复通知 。电话：不会发送恢复通知，并且只会播报报警标题与告警服务名 。复制AlertManager.builder()
//企业微信
.wechat("zhangsan","lisi")
//指定了消息通道的企业微信
.wechat(Arrays.asList("zhangsan","lisi"), "10")
//企业微信群聊机器人
.wechatRobot("企业微信群机器人key")
//邮件
.mail("zhangsan@zhuanzhuan.com", "lisi@zhuanzhuan.com")
//Http回调
.webhook("http://www.baidu.com")
//短信
.sms("188xxxxxxxx", "180xxxxxxxx")
//语音电话
.phone("188xxxxxxxx", "180xxxxxxxx")..1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.五 、未恢复告警
为了防止告警过多时淹没了重要告警 ，在每条告警的最后 ，都提供了一个未恢复告警链接 ，用于实时查询当前未恢复的告警 。
未恢复告警拥有三种状态 ：活跃 、静默、抑制。其中，活跃状态可以设置静默，静默状态可以查看被谁静默 。
六 、静默告警
基于Alertmanager OpenAPI ，支持基于标签的静默告警 ，每条告警通知内都提供了一个链接用于快速静默，也可以在未恢复告警内静默告警。
点击新增静默后 ，会自动补充静默匹配的标签项 ，也可以增减标签项 ，如：去掉INSTANCE标签维度以便匹配所有的机器 ，修改_RECEIVER为其他人等 。需要注意的是 ，添加静默时RECEIVER必须要指定 。
添加完成后 ，会自动跳转到静默列表 ，并展示刚刚添加的静默项 。
在静默列表内可查询所有的活跃、过期的静默项 ，可编辑、删除 、查看影响的告警 。
查看受影响的告警为实时查询，如果当前静默没有匹配到任何告警 ，查询结果会为空。
七 、告警历史
告警通知给用户后 ，我们会保留三个月的历史告警记录列表 。
八 、总结
Alertmanager提供了告警降噪的策略，我们在Alertmanager的基础上制定了标签规范 、告警分级降噪 、分级抑制 、告警合并 ，并基于Alertmanager OpenAPI扩展了未恢复告警 、静默告警 、告警历史 。Alertmanager虽然不是告警降噪的银弹 ，但也可以解决大部分问题 ，如果你也面临着告警轰炸的问题 ，可以尝试一下 。
关于作者
苑冲 ，转转架构部存储服务负责人 ，主要负责MQ 、监控系统 、Redis 、KV存储等 。爱学习 ，喜欢以辩证思维与变化思维思考 。