最近设计一个告警的产品,参考了开源的 alertmanager ,但是功能上面有一些疑问:
告警合并/分组:假设一台物理机宕机,这台物理机上面的虚拟机都有宕机告警,如果不分组的话,就会一次性发送多个宕机告警,这个确实不友好,所以可以按告警规则名称这个维度对告警进行合并,这个是合理的。但是除了按告警规则名称进行合并外,也想不到按其他维度进行合并告警的有意义案例。比如按数据中心这个维度进行合并的话,某个数据中心当了,一来概率极低,二来数据中心都宕了,我的告警系统应该也挂了。
告警抑制:比如某台机器宕机了,那么这台机器上面的服务不可用的告警就不发。但是实际情况是,机器宕机告警是发给 SRE ,服务不可用是发给服务开发的人,原则上不应该抑制,服务开发人员需要知道我的服务挂了。告警抑制功能目前我并没有想到真正合理的案例。
告警升级:比如某个服务有问题了,发出了告警,但是一直没人处理,一段时间后通知给到这个服务负责人的 leader 。这个功能虽然谈告警的时候一直有人谈,但实际上我没有遇到真正用到的场景,除非一个人想要离职了,否则一般不会不处理告警。所以这个功能有必要做吗?
我的疑问就是这三个功能,大家有实际的应用场景吗?
1
beyondstars 317 天前
告警合并可以按指定的维度进行合并,也可以按照 ai 对日志做出的分类进行合并。
告警抑制是用来抑制告警风暴问题,比如服务 b1, b2, b3 依赖服务 a, 服务 c11, c12 依赖服务 b1, 服务 c21, c22, c23 依赖服务 b2, 服务 c31 依赖服务 b3, 那么假如服务 a 出问题了,依赖树下依赖它的所有服务可能都会告警,产生告警风波,一般会有根因定位定位到服务 a 出问题,然后其它一些告警被抑制。 |
2
beyondstars 317 天前
更正错别字:告警风波 -> 告警风暴
|
3
beyondstars 317 天前
哦对了上述我说的一些,一部分属于 aiops 的范畴,可能是市面上已有开源告警监控产品/项目不具备的。
|
4
BQsummer 317 天前
负责小公司的监控告警平台:
1. 不是没有聚合的维度, 是维度太灵活了, 不同告警可能需要不同的维度, 由用户定义, 比如我调度中心想按照应用维度聚合, 模型平台想根据模型 code 聚合, 这块我们一直没做, 因为通知这一层做了聚合, 勉强能用. 2. 我们把抑制做了细分: 处理/屏蔽/静默, 处理是指我知道了告警, 在处理, 你先别发我了; 屏蔽是我不想收到这个告警, 或者这个告警我处理不了; 静默是每天的这个时间段可能是有问题, 别告警 3. 升级还是有必要的, 一种是告警没处理升级(离职了或者开会没看到通知等) 一种是处理长时间没恢复需要通知上级(特定告警等级才会升级) |
5
yujianwjj OP 大家能举个实际的例子吗,就是真正在用到的例子。
|
6
yujianwjj OP 第二点就是指告警抑制,不是告警静默
|
7
cnleon 317 天前
1. 这个可以有效避免报警风暴,可以添加报警的时候增加它的 upstream
2. 这个是需要有的,比如磁盘 80%告警,但是这个因为增长不快,直接让它暂时抑制了,或者调用自动处理脚本就行。 3. 值班人员睡着了,或者没注意,通知到其他人是很有必要的。 |
8
F7TsdQL45E0jmoiG 316 天前
前两个功能 alertmanager 都有,第三个没意义
|