通知策略

Это содержимое пока не доступно на вашем языке.

DumbMonit 的承诺是通知值得阅读。告警引擎在告警可能讲话之前保持信息低噪声(依赖关系压制、分组、维护窗口);通知策略在之后保持低噪声,按通道。无需配置:下面的默认值开箱即用。

管道,一份列表

evaluate (hysteresis, per-device overrides)
  → deduplicate → suppress by dependency → silence → group by device
    → flap hold → channel severity filter → channel routing filter
      → resolved on/off → cooldown → quiet hours → batch window
        → hourly cap → send (+ deep link)
                                   ↘ nobody acknowledged → escalation channel

阶段	设置位置	默认值
清除阈值(滞后)	规则编辑器 → 清除下方/上方	无(CPU: 85%,磁盘:运输规则上 88%)
按监控项覆盖	规则编辑器 → 按监控项覆盖	无
故障检测	设置 → 通知与报告 → 通知策略 → 更多选项	4 个变化在 30 分钟内,保持 30 分钟
最小严重级别	通道 → 交付选项 → 发送	全部
告诉我何时清除	通道 → 交付选项	开
按告警最小间隔	通道 → 交付选项	无
安静时间	通道 → 交付选项	关
路由过滤器(标签、类型、规则)	通道 → 交付选项 → 仅某些告警	关(通道听到一切)
如果没有人确认则升级	设置 → 通知与报告 → 通知策略	关
批处理窗口	设置 → 通知与报告 → 通知策略	60 秒
每个通道每小时的消息	设置 → 通知与报告 → 通知策略	20
公共 URL(深链接)	设置 → 通知与报告 → 通知策略,或`DUMBMONIT_PUBLIC_URL`	空

滞后和按监控项覆盖

一个在 90%上触发,值一下 90%就立即清除的规则会在 CPU 在 89–91%徘徊时整晚触发和清除。给它一个 清除阈值:一旦触发,告警仅当值下降到其下时解决 (对于”在上方触发”规则)或在其上方(对于”在下方触发”规则)。API 字段是规则上的clear_threshold;服务器拒绝错误一侧的清除阈值。

一个按监控项覆盖改变一个监控项的阈值或清除阈值, 或关闭该监控项的规则,无需复制规则:

PUT /api/alerts/rules/{id}/overrides/{target_id}
{ "threshold": 97, "clear_threshold": 95 }      # or { "enabled": false }
GET /api/alerts/rules/{id}/overrides
GET /api/alerts/overrides?target_id=7           # every override of one device
DELETE /api/alerts/rules/{id}/overrides/{target_id}

一个所有字段都为空的覆盖被移除。消息引用实际应用的阈值。

故障检测

不管规则如何,一个其指纹在 30 分钟内触发或解决 4 次的告警是飘动:一个通知出去(“飘动:4 个变化在 30 分钟,通知保持 30 分钟”)并且关于该告警的其他内容在保持结束前不发送。保持后的解决仍被公告。调整或在设置 → 通知与报告 → 通知策略 → 更多选项中关闭 (flap_events、flap_window_secs、flap_hold_secs;flap_events: 0 禁用它)。

按通道交付选项

每个通道决定它听到什么(通道有效负载中的policy):

min_severity — info、warning(通知及以上)或critical (仅警告)。电话通道通常想要critical,聊天室一切。
notify_resolved — false仅听关于问题。
min_interval_secs — 关于同一告警的两条消息之间至少这么长(重新触发和提醒)。解决永远不会被它延迟, 解决仅发送到听到触发的通道。
quiet_hours — 你当地时间的每周窗口,与每周维护窗口相同的形状。在安静时间期间仅critical告警通过; 其余的等待并在它们结束时作为一个摘要到达,标题为”安静时间结束 — …”。在安静时间内触发和清除的告警仅在该摘要中被提及为”在安静时间期间解决”。
matcher — 通道想要哪些告警,按标签、监控项类型或规则。空(默认,以及每个现有通道保持)意味着一切。

PUT /api/notify/channels/{id}
{ "name": "Phone", "kind": "ntfy", "settings": {…},
  "policy": { "min_severity": "critical", "min_interval_secs": 900,
              "quiet_hours": { "kind": "weekly", "days": [0,1,2,3,4],
                               "start_minute": 1320, "end_minute": 420,
                               "timezone": "Europe/Paris" } } }

在更新中省略policy保持存储的;"quiet_hours": null 清除它们,"matcher": null清除路由过滤器。

按标签路由

监控项携带标签(site=cellar、role=storage)和一种类型(snmp、 proxmox、synology、agent…)。通道的路由过滤器说哪些告警它想要:

{ "policy": { "min_severity": "warning",
              "matcher": {
                "include": [ { "field": "tag", "key": "site", "value": "cellar" } ],
                "exclude": [ { "field": "tag", "key": "role", "value": "lab" } ] } } }

三个字段,精确相等仅 — 无正则表达式,无括号:

`field`	匹配	示例
`tag`	监控项自己页面的标签	`{"field":"tag","key":"site","value":"cellar"}`
`kind`	轮询监控项的收集器	`{"field":"kind","value":"proxmox"}`
`rule`	规则的`uid`	`{"field":"rule","value":"disk_full"}`

列表读取方式:

相同字段上的条件(相同标签键或kind或rule) 是一个OR — site=cellar加site=attic意味着任一;
不同字段上的条件是一个AND — site=cellar加 role=storage意味着两者;
exclude总是赢,即使超过匹配的include。

所以上面的示例读取,UI 以这些确切的词说回去: 此通道从标签 site=cellar 的监控项接收通知及以上, 除了标签为 role=lab 的监控项。

在编辑器下,一个预览列出你当前监控项的哪些过滤器选择。它不是一个近似:服务器运行告警引擎运行的确切过滤器, 仅限于依赖于监控项本身的部分。规则条件适用于告警而不是监控项,所以预览命名它们单独而不是假装计数它们。

POST /api/notify/match-preview
{ "matcher": { "include": [ { "field": "tag", "key": "site", "value": "cellar" } ] } }

→ { "devices": [ { "id": 3, "name": "nas", "kind": "synology",
                   "tags": { "site": "cellar" }, "matched": true } ],
    "matched": 1, "total": 12, "rules": [], "excluded_rules": [] }

一个过滤器限制为十二个条件。超过那个,第二个通道比一个更多条件清晰。

升级:如果没有人确认

一个额外的跳跃,仅一个。当策略设置escalate_after_secs和 escalate_channel,一个没有人确认的告警在该延迟内仅一次也发送 — 到该通道:

PUT /api/notify/policy
{ "escalate_after_secs": 900, "escalate_channel": 4 }

延迟从第一条消息实际发出的时刻计数, 不是从告警触发。如果安静时间或失败的交付吞没了第一个通知,没有什么要升级的还,跳跃等待。
确认告警停止它,就像它停止提醒一样;告警清除也是。
升级消息去升级通道仅 — 已经听到触发的通道不被告诉两次。
它超过该通道自己的严重级别下限、路由过滤器和安静时间: 你命名这个通道被唤醒,所以在它重要的那一刻不被保持。
这行说:🔴 Critical · Disk full — /data — 95% … — still unacknowledged`。

"escalate_channel": null关闭升级;延迟为0做相同。两者都需要跳跃存在,服务器拒绝不存在的通道而不是升级进入虚空。

DumbMonit 故意停止在这里:一个跳跃,无轮换,无这周谁在值班的时间表。如果你需要那个,指向升级通道在 PagerDuty 或 Opsgenie,这做它适当。

批处理和每小时上限

GET/PUT /api/notify/policy持有全局设置:

{ "batch_window_secs": 60, "max_per_hour": 20,
  "flap_events": 4, "flap_window_secs": 1800, "flap_hold_secs": 1800,
  "public_url": "https://monit.example.lan",
  "escalate_after_secs": 0, "escalate_channel": null }

批处理窗口 — 在窗口内触发的告警离开为一条每个通道的消息,按监控项分组:“2 个监控项上的 3 个告警”有每个监控项的部分;解决搭车(“2 个已解决”)。0在下一个周期发送。摘要列出最多 12 行,然后”…和 N 个更多告警”。
每小时上限 — 一旦一个通道在最后一小时接收了max_per_hour条消息, 进一步的告警等待并作为一个摘要到达当一个插槽释放。 0移除上限。
值班通道(PagerDuty、Opsgenie)永远不被批处理过监控项:它们打开和关闭每个监控项一个事件,所以它们接收每个监控项一条消息而不等待。

交付失败保持行队列;下一个周期重试。

一行说什么

每个告警是一行,在邮件、ntfy、聊天和自定义 webhook 的{{message}}变量中相同:

🔴 Critical · Disk full — /data — 95 % (threshold > 90 %), for 12 min
⚠️ Warning · VM or container stopped — win11-desktop (101), for 59 s
✅ Resolved · Service down — https://example.lan/

字形之后是状态词(Critical / Warning / Info, Resolved、Flapping),所以严重级别可读没有颜色或表情符号。
一个规则看几个系列名称那个触发的:VM 和其 id、挂载点、接口、备份组、探针的 URL。监控项范围的规则(不可达)命名不超过监控项。
值和阈值显示用于测量规则;一个万无一失的规则在 0/1 度量(在电池上、客人停止)不重复”1 (threshold > 0)”。

深链接

每条消息以一个监控项的链接结尾({public_url}/targets/{id}) 当已知公共 URL — 策略的public_url或 DUMBMONIT_PUBLIC_URL。自定义 webhook 也将其作为{{link}} 变量接收除非它们自己的base_url被设置。

故意没有消息中的”沉默 1 小时”链接:聊天服务获取每条他们显示的链接以构建预览,这会触发沉默时刻消息被发布。从监控项页面或告警页面改为沉默。

什么从 Pulse 借来,什么不是

设计跟随Pulse它适合 homelab 监视器:触发/清除阈值、一个按资源覆盖层、一个通知冷却、一个分组窗口、每小时速率限制、安静时间、故障检测带冷却、“在解决时通知”,以及值班工具保在摘要之外。未采纳:Pulse 的 24 小时观察期在通知前(DumbMonit 的基线规则已经静默学习;阈值规则应该从第一天讲话)和从消息打盹/确认(见上文)。按目的地的基于标签的路由被采纳,如上面的路由过滤器 — 在规则上选择通道变成了错误的地方,对于”地下室的一切去这个房间”。