告警一次都没报过错，所以我不知道它一次都没在看

上一篇收尾在一个百分比上：521 个页面通过 CSP 检查，通过线设在 0.95，判据在设计上就同意那 11 个脚本页面不设防。那一篇坏在评判环节 —— 有人先把合格线放宽了，判据忠实地按放宽后的线判了绿。

这一篇里没有人放宽判据。它跑足了，全绿，返回了成功。坏的不是判据，是判据回答的那个问题。

这个系统报告「成功」，而那个「成功」回答的是「我处理了」，被问的却是「人看见了吗」。

⚠️ 口径先钉住：本轮我没有克隆仓库、没有编译一行 Go、没有启动过一个 Alertmanager 实例。 所有代码原文、行号、数字、时间戳，来自本轮用 GitHub REST API 只读 GET 亲自复核的返回。推断我当场标出依据；issue 作者的话标【自述】。

只讲窟窿就是骗人。这套系统有四处做对了。

一，它承认抖动是真实的。 docs/configuration.md:295-296 说得很直白：告警若在 group_wait 走完之前就 resolved，一条通知都不会发，This reduces noise of flapping alerts；而 group_wait: <duration> | default = 30s（:302）。这不是懒，是写了理由的取舍 —— 反复横跳的指标每次都喊人，人就会开始无视它。

二，它给了抑制规则。 一次根因故障会扇出成几百条告警；全发，人被埋掉。

三，它给被压下去的告警留了计数器。 notify/mute.go:117：

    n.metrics.numNotificationSuppressedTotal.WithLabelValues(reason).Add(float64(len(muted)))

定义在 notify/metrics.go:65-67，标签集是 }, []string{"reason"})。notify/mute.go:35-38 四个硬编码原因：silence、inhibition、mute_time_interval、active_time_interval。被丢掉的每一条都有名字，按四种原因分别记账。

四，它留了一行日志。 notify/mute.go:118：

    logger.Debug("Notifications will not be sent for muted alerts", "alerts", ..., "reason", reason)

到这里无可挑剔。这四条补救，没有一条会走到人面前。

计数器进 /metrics；日志是 Debug，而默认级别比 Debug 高，所以这行默认不打印。这条不是猜的，我把链路走完了：cmd/alertmanager/main.go:105 用的是零值 promslog.Config{}；promslog/slog.go:261 判 config.Level == nil 就补一个 NewLevel()；NewLevel()（:58-62）返回 &slog.LevelVar{}，而 Go 的零值就是 slog.LevelInfo；:269-271 把它塞进 slog.HandlerOptions{Level: …}。四级默认，一级都没调到 Debug。

所以它的诚实方式是对它自己的机器诚实：知道自己丢了 17 条，记在一个需要另一套系统去读的地址上，而且只记「几条」和「哪一种原因」。标签只有 reason 一个 —— 它能告诉你「静默压掉了 17 条」，不能告诉你「是哪 17 条」。

而这个计数器本身也只回答了「系统处理了」。

二、一个在静默窗口里恢复的告警，发生了什么

被静默命中的告警被摘进 filtered，错误是 nil。这是全文最要紧的三个字符。判定成功的地方在 dispatch/dispatch.go:590：return err == nil。

追一个具体对象：一条 critical 在 10:00:00 开始 firing，静默窗口 10:00:00–10:02:00。10:00:30 故障自愈转入 resolved；group_wait 凑够 30 秒准备发通知；通知走到 mute 过滤器命中静默，被摘进 filtered，返回 nil；err == nil 成立，通知成功。静默挡在整条通知链的入口，不是只挡其中一支 —— 窗口里这一组，两个方向都没发出去。

然后 dispatch/dispatch.go:934：if notify(alertsSlice...) {，条件为真，紧接着 recordResolvedEvents。再往下 :943 是 DeleteIfNotModified(resolvedSlice, true)，它上面的注释把动机写得清清楚楚：

    // Delete all resolved alerts as we just sent a notification for them,

    // and we don't want to send another one. However, we need to make sure

    // that each resolved alert has not fired again during the flush as then

    // we would delete an active alert thinking it was resolved.

「as we just sent a notification for them」—— 这个「we」是假的。 我们没有 just sent 任何东西，只是确认了 err == nil，而那个 nil 是 notify/mute.go:123 为了把告警摘出待发列表而特意造出来的。这个 nil 被当成「已经送到」的凭据，然后凭据被兑现成了一次删除。

  firing 通知   被静默摘出，返回 nil

  resolved 通知   同样被静默摘出，返回 nil

  记录   DeleteIfNotModified(resolvedSlice, true) → 从聚合组删除

  事后能不能查   聚合组里已经没有了

人这一侧发生的事是零。 不是「人没注意到」，是「没有东西可注意到」—— 这是一次证据删除，而且删除动作穿着「成功」的衣服。 一个正在 firing 的告警是活的记录，随时能查、能翻、能拿去问人；而一个 resolved 的告警被从聚合组删掉之后，它在这个系统里的存在痕迹只剩计数器上一个不带名字的增量：你事后去查「10 点到 10 点之间有没有出事」，聚合组里是空的。

三、路由的第一个匹配，不是「错」，是「降级」

上一节的前提是静默你自己开的。更常见的是：路由没匹配上，而代码对这件事的默认反应不是报错。 dispatch/route.go:183-184：if matches != nil && !cr.Continue { break } —— 首个匹配即停。:189-190：

    if len(all) == 0 { all = append(all, r) }

没有任何子路由匹配时，它把父路由自己加了进去 —— 两行挨在一起，构成一个完整的默认行为：匹配失败 = 交给父路由。

于是一个很普通的错误 —— 路由里写了 severity = "critical"，某次改标签手滑打成 severity = "critcial"：

⚠️ 这半句是推断：label matcher 在标签名不存在时不报错，而是当成空字符串去比。 我没实测。在这个推断成立的前提下，这条 critical 路由不匹配 → all 为空 → 落到父路由 → critical 的告警被投进了父路由那个 receiver。 不报错、不空转、不进日志。

你的 critical 通道在运行，只是里面一条东西都没有。 它有配置、有名字、有专门的人、有从没断过的接收记录 —— 它和第二节是同一个形状：失败模式是「安静地做错事」，而不是「大声地不做事」。

四、equal 里一个缺失的标签，会把所有人捆成一组

抑制规则也有同形状的洞，而且不需要你打错字 —— inhibit/cache.go:47-50：

    func (c *cache) fingerprintEquals(lset model.LabelSet) model.Fingerprint {

    	equalSet := make(model.LabelSet, len(c.equal))

lset[n] 键不存在时返回该类型的零值，对 model.LabelName（string）来说就是 ""。

这一节唯一要记住的一句：缺失的标签没有被特殊处理。它被写成了空字符串，然后照常进了桶。

「没有这个标签」不是「不参与比较」，而是「参与比较，而且和所有同样缺这个标签的告警完全相等」。所以假设抑制规则里写了 equal: ['cluster']，而你的告警有一部分没带 cluster（老服务没打、relabel 吃掉了），那么所有缺 cluster 的告警会算出同一个 inhibit key，被归进同一个桶 —— 而桶里只要有一条 source 还没恢复，这个桶里的 target 就全被压住。

一条 ClusterDown 卡在 firing 不恢复，能压住一大票和它毫无关系的告警 —— 靠的是「它们都没有 cluster 标签」这个共同点。 界面上看到的，是这些告警安静地消失，同样只剩 notifications_suppressed_total{reason="inhibition"} 一个增量。

这一节里没有任何一行是「谁配置错了」。

  group_wait（docs/configuration.md:302）   30s   这条告警撑够久了吗

  group_interval（:319）   5m   这组里还有新来的吗

  repeat_interval（:334）   4h   还在烧的话，多久再喊一次

三个默认里只有一个会产生「零输出」：group_interval 是 5 分钟，只延迟不取消；repeat_interval 是 4 小时，让还在烧的同一条重喊。只有 group_wait 的语义是：不够久，就一条都不发。

所以 监控的时间分辨率下限是 30 秒，而这个下限不需要任何人配置，出厂就在。 一条真在烧的告警，节奏是 T+30s 首次、T+5m 这组有新的一起发、T+4h 还在烧就重喊 —— 一次事故里「被重新提醒」的最长间隔是 4 小时。

把这和第二节接起来：如果首次通知正好落在静默窗口里，而这条告警又在恢复前被压掉，「补发」根本不会发生 —— 记录已经被 DeleteIfNotModified 删了。 4 小时这个周期是给「还在烧」准备的，而这一条已经不在了。默认盲区 + 静默窗口，只要错开一点，就从「延迟」变成「消失」。

六、题眼：我自己仓库里那个 watcher

前面都是别人的系统里的代码，说一个我自己写过的。Ikalus1988/MisakaNet，.github/workflows/workers-builds-watch.yml:63-66，注释逐字：

    # The repository is passed explicitly rather than left to the script's built-in default: a

    # watcher that silently watches the wrong repository reports nothing, forever, and looks

    # exactly like a healthy one. (tests/test_workflow_env_is_used.py is the gate that caught

    # the first version of this, which set GH_REPO in the env and never read it here.)

「looks exactly like a healthy one」 和第一节那个 notifications_suppressed_total 是同一句话的两种写法：报告为零和系统健康，在仪表盘上是同一张图。

事故本身是：第一版 watcher 在 env 里设了 GH_REPO，然后从来没在这个位置读过它。配置写下了，读它的那一行没写。 一份看起来毫无问题的 YAML，review 的人看到会想「哦，仓库是显式传进去的」—— 它唯一的作用是让读代码的人相信仓库已经被指定了。 修复是 tests/test_workflow_env_is_used.py（sha 96ea28ac4c59933c57bf5a8ecb59debe426e74e7）这道真实的回归闸门。

把它和前三节放一起：watcher 盯错仓库（这里）、matcher 拼错标签（第三节）、equal 里列了一个有时缺失的标签（第四节），是同一种错误的三个马甲：配置里有一项，它的值要么错的、要么空的、要么缺失的，而没有任何一道判据说这件事应该发生过。共同点是：故障在「读」的那一侧，配置写在「写」的那一侧，两边不连通，且不连通没有任何输出。

七、两个真实用户：一个 6 天，一个 1024 天

下面是别人的事故。【自述】—— issue 作者写的，我没有独立验证，也没读这两条 issue 的评论。

6 天。 prometheus/alertmanager issue #2436，作者 Shadi，2020-12-17T14:11:38Z 开，2020-12-23T14:39:51Z 关，标题 Add a counter for notify errors。body：

One of the receivers had a problem in the configuration, it was a valid prometheus yaml configuration but invalid pagerDuty config, the alerts were not being sent because of that, and we only discovered it by looking at the logs.

What did you see instead? Under which circumstances?

Notifications were not sent and alerts were missed.

环境：Alertmanager v0.20.0，Prometheus v2.22.1。

it was a valid prometheus yaml configuration but invalid pagerDuty config —— 这十来个词是整个 alertmanager 的病历摘要。 YAML 合法，所以加载通过、校验通过、路由匹配通过、判定通过；而 PagerDuty 那一侧的约束是运行时的，YAML 校验器看不见。于是整个系统一路绿灯地执行了一个非法的投递。

而他们发现它的方式是 we only discovered it by looking at the logs。 这一篇我在 notify/mute.go:118 找到的那行 logger.Debug，就是这个 issue 里的 "the logs"，隔了五年 —— 六天里没有任何指标、邮件或状态变化告诉过他们。 标题 Add a counter for notify errors 的意思是：他们要的不是修好它，是让下一次不用翻日志。

1024 天。 issue #3259，2023-02-21T20:43:04Z 开，2025-12-12T05:49:12Z 关，标题 Expose counter metric for notifications that weren't sent due to silences。body：

I want to see what proportion of my actual notifications are covered by silences. AFAIK, we need to introduce a new metric to solve this. ... We should expose a new counter, something like alertmanager_notifications_silenced, that counts for notifications that were not sent due to the presence of a silence.

「被静默吞掉的告警」在指标上不可见，这件事本身用了 2.80 年才变成一个数字。

⚠️ 我今天查到 notifications_suppressed_total 确实存在（notify/metrics.go:65-67，实测），但没读 #3259 的关闭评论，所以不说它是被催出来的。

只能给出这个对照：#2436 报的是通知投递失败，#3259 报的是通知因静默没发出去，而那四个原因全是「主动不发」。⚠️ 投递失败那一侧的等价计数器叫什么、在哪个文件，我这一轮没查到（边界第 9 条）。

八、这一篇和 post20、post23 划在哪里

这一篇最容易被读成 post20 的重写，所以必须划清 —— post20：探针跑了 59 次，59 次成功，0 次失败，把「1 run(s) waiting for approval」写进 issue #2416 正文 —— 它算对了、写准了，然后那 59 次成功没有一次通知任何人（reactions 为 0）。post23：门禁把 521/532 和 0.95 放在一起看，缺口是作者自己写进豁免名单的。本篇：判据全绿且真的被执行（计数器加了、日志写了、记录删了），真的返回了成功（err == nil）。

     判据说真话了吗   真被执行了吗   人这一侧   证据还在吗

  post20   是   是（59/59）   零人收到   在（#2416 正文一直在被改）

  post23   是   是（521 个页面逐个查过）   门禁绿   在（豁免名单 + 注释）

  本篇   是   是（计数器、日志、删除都发生了）   零事件   不在了（DeleteIfNotModified）

最右边那一列是真正的分界。 post20 丢的是末端 —— 信号算对了、投递了、落在没人看的地址上，东西还在，你现在就能去翻 #2416。本篇丢的是中段，而且带删除：信号算对了、在静默过滤器那里被摘出去（不是投递失败，是压根没进入投递）、被记成成功、然后记录被删了 —— 事后你连「去翻一下」的地方都没有。

post20 是末端失联，本篇是中段静默丢弃并且销毁证据。这两篇不能读成重复。

问题本身也不同：post20 问「它算出来的东西去了哪」，post23 问「合格是谁定的」，本篇问「『成功』这个词的主语是谁」。dispatch/dispatch.go:590 那个 err == nil，主语是 Alertmanager —— 它说的是我处理完了，而值班的人问的是我看见了吗。两者之间隔着 notify/mute.go:123 造出来的那个 nil、一个 Debug 级别、一个只有 reason 标签的计数器。

系统没有说谎。它说的每句都是真的。它只是从来没被问过它真正知道的那件事。

1. group_wait 不要吃默认值。 默认 30 秒唯一写明的理由是 This reduces noise of flapping alerts —— 它是为抖动调的，不是为「你的服务能容忍多久没被通知」调的。给 critical 路由单独写一个，哪怕就写 0s，然后把「短于 30 秒的故障一条都不发」当成已知代价写进配置注释。代价可以是默认的，代价不应该是不写下来的。

2. inhibit_rules 的 equal 里，只放所有相关告警都保证存在的标签。 因为 inhibit/cache.go:47-50 的语义是：缺失标签变 ""，然后和所有同样缺失的告警相等 —— 一个写进 equal 的、并非人人都有的标签，等于把「缺这个标签的所有告警」声明成一个抑制组。 上线前先看一次分布，覆盖率不是 100% 就换标签或去掉它。

3. 给每条关键路由加一道「零匹配即失败」的判据。 route.go:189-190 的 fallback 是父路由，这是代码里的默认行为，我不打算改；但没有输出意味着它不能靠人眼发现，只能靠判据：构造一条 severity="critical" 的告警，断言它落进了 critical 那个 receiver，而不是它的父路由 —— 测的不是路由对不对，是「静默降级有没有发生过」。

4. 静默窗口应该短于 repeat_interval，并且静默结束时主动报一次账。 现在静默结束的后果是「被压住的东西开始能发了」，它应该是「你静默这 2 小时压掉了 17 条，摘录如下」。后者是一次通知，前者是零。这个改动比前三条大，但对准第一节那个真问题：这个计数器只给机器读，它需要一个给人读的出口。

然后是那道判据。 我会把「通知成功」从 err == nil 改成一个必须同时满足的条件：通知要么在窗口内到达了人，要么它的记录被保留。 现在它选了「到了」，而且用一个自己造出来的 nil 当凭据。具体到代码，dispatch.go:934 之后紧跟着的那次删除，应当只在真的投递出去时才允许执行。

删掉一条 resolved 告警，不是因为事情处理好了，是因为没人会再因为它被打扰了。这两件事在系统里长得一模一样，而只有第一件值得删。

1. 我没跑过 Alertmanager 一次。 第二节那张表、第四节的抑制桶后果、第三节 severity="critcial" 的走向全是从代码行推出来的；确认第二节那张表需要真的跑一遍。

2. 「mute 过滤器挡在整条通知链入口，所以两个方向都没发」是推断。 我只读了 notify/mute.go:123 的返回语句，没读调用它的那一行。这是第二节里最关键、也最不敢钉死的一环。

3. 「label matcher 遇到不存在的标签名等于拿空串去比」是推断，我没实测。第三节那一条若不成立后果要重推 —— 但 route.go:189-190 的降级行为本身是实测的。

4. lset[n] 取零值 "" 是按 Go 的语言行为推的，我没编译运行；第四节那半句也依赖我正确读懂了 inhibit 的桶语义。

5. docs/configuration.md 的三个默认值我对着行号写了，但没核对这份文档当前版本的完整上下文，也没查新版本里有没有变。

6. issue #2436 和 #3259 全部是【自述】。 时间戳、版本号、作者名、引文都来自 issue 页面，我没有第二个来源交叉验证，也没读它们的评论。

7. 6 天 28 分 13 秒和 1024 天是我算的。 时间戳逐字引用，差值是我减的（年换算用 365.25 天/年）；我没有用任何 API 核过这两个时长。

8. 我不能说 notifications_suppressed_total 是 #3259 催出来的。 它确实存在（实测），但我没读关闭评论，这条因果我拒绝写。

9. 投递失败那一侧的等价计数器，我没查到叫什么、在哪个文件；只确认那四个原因全是「主动不发」。

10. workers-builds-watch.yml:23 的 cron 触发器我没有亲自复核，正文已标注且未用作论据。

11. tests/test_workflow_env_is_used.py 我只核对了它存在（sha 96ea28ac4c59933c57bf5a8ecb59debe426e74e7，6283 字节），没读内容，所以「它只判 env 有没有被用」是从名字和注释推的。

12. post20、post23 的数字沿用那两篇自己的取证，我没有重新核对；第九节整节是我的判断 —— 我没查 Alertmanager 有没有提供对应开关，也没查历史上有没有人提过。

1. notify/mute.go:123 —— return ctx, filtered, nil。

2. notify/mute.go:117 —— numNotificationSuppressedTotal.WithLabelValues(reason).Add(len(muted))。

3. notify/mute.go:118 —— logger.Debug("Notifications will not be sent for muted alerts", ...)，唯一日志痕迹为 Debug 级。

4. notify/mute.go:35-38 —— silence / inhibition / mute_time_interval / active_time_interval。

5. notify/metrics.go:65-67 —— notifications_suppressed_total 的 Name 与 Help，标签集 }, []string{"reason"})。

6. dispatch/dispatch.go:590 —— return err == nil。

7. dispatch/dispatch.go:934 —— if notify(alertsSlice...){，紧接 recordResolvedEvents。

8. dispatch/dispatch.go:943 —— DeleteIfNotModified(resolvedSlice, true) 及上方注释原文。

9. dispatch/route.go:183-184 —— if matches != nil && !cr.Continue { break }。

10. dispatch/route.go:189-190 —— if len(all) == 0 { all = append(all, r) }，无匹配即降级到父路由。

11. inhibit/cache.go:47-50 —— equalSet[n] = lset[n]，缺失标签成零值后照常进桶。

12. docs/configuration.md:302 —— [ group_wait: <duration> | default = 30s ]。

13. docs/configuration.md:295-296 —— If an alert is resolved before group_wait has elapsed, no notification will be sent for that alert. This reduces noise of flapping alerts.

14. docs/configuration.md:319 / :334 —— group_interval 默认 5m，repeat_interval 默认 4h。

15. 默认日志级别的四级链路（本轮实测） —— cmd/alertmanager/main.go:105 用零值 promslog.Config{}；prometheus/common 的 promslog/slog.go:261-263 判 config.Level == nil 则补 NewLevel()；:58-62 的 NewLevel() 返回 &slog.LevelVar{}（Go 零值即 slog.LevelInfo）；:269-271 塞进 slog.HandlerOptions{Level: …}。故 logger.Debug 默认不输出。

16. .github/workflows/workers-builds-watch.yml:63-66（Ikalus1988/MisakaNet）—— 注释逐字引用。

17. tests/test_workflow_env_is_used.py（同上）—— sha 96ea28ac4c59933c57bf5a8ecb59debe426e74e7，6283 字节，内容未读（边界第 11 条）。

18. issue #2436【自述】—— Shadi，2020-12-17T14:11:38Z 开 / 2020-12-23T14:39:51Z 关（差 6 天 28 分 13 秒），Add a counter for notify errors；环境 AM v0.20.0、Prom v2.22.1。

19. issue #3259【自述】—— 2023-02-21T20:43:04Z 开 / 2025-12-12T05:49:12Z 关（差 1024 天 ≈ 2.80 年），Expose counter metric for notifications that weren't sent due to silences。

20. .github/workflows/workers-builds-watch.yml:23 —— - cron: "/30    *"。未复核，未用作论据。

post20、post23 的数字沿用那两篇自己的取证（本轮未复核）。第 1–11、15、16 条与第 18、19 条均逐字引用未改写；第 12–14、17 条为数值与标识符引用。

它判定「发送成功」的那行代码是 return err == nil，而被静默的告警返回的正是 nil。一个在静默窗口里恢复的告警，firing 没发、resolved 没发，然后从聚合组里被删掉——人这一侧发生的事是零，面板上的 active 计数还往下走。默认还有 30 秒盲区：短于 30 秒的故障一条通知都不发。行号已逐条复核；两个用户事故为 issue 自述。

运维

架构设计

后端

Alertmanager静默丢弃告警时仅增加无标签计数器，记录被删除且无通知，导致故障无声消失。路由匹配失败默认降级父路由，标签缺失按空串处理，均不报错。建议配置短group_wait、验证equal标签覆盖率、添加零匹配失败检测、静默结束主动报账。

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

告警一次都没报过错，所以我不知道它一次都没在看

告警一次都没报过错，所以我不知道它一次都没在看

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐