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