测验：告警设计

不应该针对 CPU 使用情况设置页面通知的最准确原因是什么？

• CPU 指标具有高基数
• 如果CPU在90%且响应正常，则没有任何事情发生，而如果CPU在40%且响应5秒，则属于严重事故，因此两种情况都是错误的。
• 由于CPU是仪表类型，因此无法使用速率功能并且无法创建通知。
• CPU从云端自动调整

为什么“既然有很多误报，那就增加到 30 分钟”是一个反模式？

• 因为Prometheus不支持超过30分钟，
• 内存使用量增加
• 这是因为检测会延迟 30 分钟，如果事件在 25 分钟内结束，则根本不会发出通知声音。
• for 没有意义，因为它计算的是表达式为真的总时间。

每天 400 条通知中只有 4 条产生实际行动，最大的风险是什么？

• 存储成本随着通知记录的积累而增加。
• 由于音量较大，发送通知存在延迟。
• “暂时忽略它，稍后检查”成为合理的策略。
• 规则过多导致评估缓慢

如果我将实例放在Alertmanager的group_by中会怎样？

• 根据 pod 数量发送通知
• 根本没有任何通知
• 抑制规则不起作用
• 忽略重复间隔

为什么在通知路由方面“目前仅发送到 Slack 通道”的妥协是最糟糕的？

• Slack API 费用昂贵
• Slack 不支持抑制规则
• 因为有四个阶段，没有人承担责任，也没有人阻止它。
• Slack 消息不会记录在审核日志中。

如果沉默超过30天该怎么办？

• 沉默延长至90天
• 将严重性级别提高到页面以引起注意。
• 双倍门槛
• 删除——因为沉默是通知错误的最诚实的信号。