告警工作原理
Ce contenu n’est pas encore disponible dans votre langue.
有用的规则在安装后就立即活跃;无需任何调整。日常使用中有所不同的是什么保持信息低噪声:依赖关系压制、按主机分组、维护窗口以及一个学习后才发言的基线。
界面使用天气预报的级别。API 和规则编辑器在其引擎名称下存储相同的三个级别。
| 在 UI 中 | 在 API 中 (severity) | 含义 |
|---|---|---|
| 信息 | info | 值得了解,无需采取行动。由基线规则使用。 |
| 通知 | warning | 需要很快关注:CPU 高、磁盘快满、服务缓慢。 |
| 警告 | critical | 立即需要你的注意:监控项不可达、服务关闭、备份验证失败、证书过期。 |
升级在escalate_after后将规则的严重级别提升一级,如果告警持续触发(信息 → 通知 → 警告;警告保持)。
每个告警都是一个状态机,每 30 秒评估一次
(DUMBMONIT_ALERT_INTERVAL_SECS)。
| 阶段 | 在 UI 中 | 含义 |
|---|---|---|
ok | — | 条件为假。 |
pending | 积累中 | 条件为真,但规则的保持(for)尚未经过。不发送任何内容。 |
firing | 触发中 | 条件已保持足够长的时间。第一条通知发出,然后每repeat_interval发送提醒(大多数内置规则默认为 6 小时),如果配置则升级。 |
resolved | 已解决 | 恢复正常。仅当触发已被宣布时才发送解决通知。 |
suppressed | 由父监控项压制 | 告警正在触发,但父监控项宕机,或监控项本身不可达:见下文。 |
phase是引擎的状态;effective_phase是你看到的。一个effective_phase为suppressed的告警在下面保持phase = firing,所以父监控项恢复时不会再次通知。
告警也可以被确认(acked,带有acked_by、acked_until
和ack_note):阶段不移动,提醒和升级暂停直到
acked_until,解决仍被通知并清除确认。
打盹一个告警在底层工作方式相同,但通过范围限定在该告警的精确标签(silenced: true)的维护窗口,
而不是整个监控项:同一监控项上的兄弟规则继续讲话。
见摆脱告警。
依赖关系压制
Section titled “依赖关系压制”任何监控项都可以声明一个父监控项。当监控项宕机时,其后代上的每个告警
被标记为由父监控项压制而不是被发送:一个交换机关闭产生一个通知,而不是三十个。
最近的宕机祖先被命名为原因(suppressed_by),链被跟随直到 64 级。
当以下任一告警在监控项上触发时,无论原因如何,该监控项即为宕机:
- 监控项不可达:完全没有测量值(停止应答的 SNMP 设备、停止推送的代理);
- 服务关闭:其可用性检查在运行但失败(100 % 丢包的 ping、出错或超时的 HTTP 检查、关闭的 TCP 端口等)。
父项上的普通警告(磁盘已满、CPU 过高、服务缓慢、证书即将过期)不会隐藏任何内容: 设备仍在应答,其后的内容也是如此。父项保留自己的告警和通知;当它恢复时,仍然 宕机的子项会触发并各自发出通知。
不可达的监控项本身也是如此:它的其他告警(磁盘已满、CPU 等)被其自身的故障压制,suppressed_by指向监控项本身,因为这些读数已过时,只是同一故障的症状。只有它的”监控项不可达”告警永远不会被自身的故障隐藏,所以你仍会收到一次通知。
在监控项表单上设置父监控项。在监控项页面上,子项堆叠在 其父项下,当父项宕机时变暗。
一个中继代理算作它探测的每个监控项的父项(通过监控项表单上的监控项),除了父项 明确设置:当中继宕机时,其监控项被压制,中继作为 原因被命名。在相等距离下,明确的父项获胜。
父项也算作一旦其自己的探针说是这样就宕机( 超时、监控项不可达或服务关闭状态在其页面上),无需等待 其告警触发:一个停止推送的代理将 其监控项在其自己的告警之前一分钟或两分钟带走,一个刚刚 ping 失败的交换机会在 “服务关闭”的保持时间结束之前隐藏其子项;否则它们会先通知每个。
分组、去重、提醒
Section titled “分组、去重、提醒”没有分组,一个 NAS 其 RAID 降级会发送一条消息每个磁盘、
每个周期。DumbMonit 每个主机每个周期最多发送一条消息,即使
它包含五行。每个告警在开始触发时被通知一次
(firing),然后仅作为提醒(reminder,每repeat_interval)、升级(escalation)或解决(resolved)。告警历史
记录每个过渡,无论是否被通知以及如果不是,为什么
(学习、压制、静音、确认)。
一个静音停止通知而不停止评估:在一个 窗口的末尾,一个仍然活跃的告警被通知一次,而不是”出生” 在两小时的存在后。窗口是一次性的或每周的,每个监控项或对于 整个实例。见维护窗口。
“异常 CPU”规则不需要阈值。对于每个系列它保持 168
个桶,每个(星期几、小时),并将每个点与通常
在那个时刻观察到的内容进行比较。得分是鲁棒的(中位数和 MAD,一个
每个桶有alpha = 0.05的 EWMA),所以单个事件不会改写
基线,季节漂移被跟随。
该规则在其学习的前十四天保持沉默:每个桶 必须至少被看到两次才能区分”异常”和”从未观察到”。在 此期间它显示有一个学习标志,仅告诉你 它会触发什么。消失的系列的基线在 60 天后被遗忘。
两种告警预测而不是报告,概览在预报下列出它们:基线异常,以及predict规则,用predict_linear()在 VictoriaMetrics 端
外推一个系列
(“文件系统即将满”在四天内)。PBS 数据库估计是
PBS 自己预报的纯阈值。
通知去往何处
Section titled “通知去往何处”内置规则没有附加通道,这意味着每个启用的通道。 一个你编辑的规则可以命名特定通道。通道在 设置 → 通知与报告中配置;见通知通道。
上面的一切决定是否告警可能讲话。第二个阶段, 通知策略,决定何时和在哪个通道上,以便 没有人被垃圾邮件淹没。一个告警的完整路径,按顺序:
- 评估 — 阈值、异常分数或预报,带有规则的
保持(
for)和,当设置时,其清除阈值(滞后:触发 超过 90%,仅在 85%下清除)和任何每监控项覆盖。 - 去重 — 每个(规则、系列)一个指纹,键在
监控项 id(
target)上而不是其名称:重命名监控项或编辑 其标签不创建第二个告警,一个系列解决为 相同的键两次产生一个告警。删除或暂停的监控项的系列 被丢弃:其告警立即清除,没有任何 通知,历史记录device removed or disabled。 - 按依赖关系压制 — 宕机监控项的后代保持 安静。
- 静音 — 维护窗口使其涵盖的内容哑巴。
- 按监控项分组 — 每个周期每个监控项一条消息,提醒和 升级折叠。
- 故障保持 — 在 30 分钟内触发和清除 4 次的指纹 发送单个”飘动”通知,然后 30 分钟内什么都不发送。
- 按通道过滤器 — 最小严重级别,“告诉我何时清除” 开/关,以及同一告警的两条消息之间的最小间隔。
- 安静时间(按通道) — 仅警告级告警通过; 其余的等待并在安静时间结束时作为摘要到达(“安静时间” 结束 — …”)。在安静时间内触发和清除的告警仅 在该摘要中被提及为”在安静时间期间解决”。
- 批处理 — 批处理窗口内的告警(默认 60 秒)离开为 每个通道一条消息:“3 个监控项上的 2 个告警,1 个已解决”。
- 每小时上限 — 过去
max_per_hour条消息在一个通道上, 告警等待并作为一个摘要到达(”…和 7 个更多告警”)。 - 发送 — 当公共 URL 已知时带有每个监控项的”在 DumbMonit 中打开”链接。
第 6 到 10 步在设置 → 通知与报告 → 通知策略(全局)中配置,并且 在每个通道(交付选项)上。见通知策略。