说明：Prometheus 生态的告警出口 Alertmanager 接入声光语音终端：webhook_configs 直连自定义 API 或转发器，route 分级、group 参数与终端播报队列的分工、inhibit_rules 抑制风暴、resolve 配对恢复事件。附完整 alertmanager.yml 与联调命令。配置项以所用 Alertmanager 版本为准，不放站外链接。
一、痛点：云原生监控的告警，现场依然静悄悄
Prometheus 抓指标、Alertmanager 管路由，这套体系把"发现"做得很好------但告警出口十有八九是钉钉/企业微信机器人。问题与 Zabbix 篇如出一辙：消息到了手机，没到现场。机房断电、磁盘写满、证书临期，大屏上红成一片，值班室安静如常。
Alertmanager 接声光终端有个天然优势：它已经内置了告警治理最重的两件事------分组（group）与抑制（inhibit） 。接入设计的关键，是把"谁负责降噪"这件事想清楚：Alertmanager 管聚合与抑制，终端管灯色与播报节奏，两层各司其职，不要重复建设。
二、两级降噪分工：先分清谁管什么
| 治理手段 | 归属 | 说明 |
|---|---|---|
| 分组聚合（group_by / group_wait） | Alertmanager | 风暴时把 200 条同类告警合成 1 条再外发 |
| 抑制（inhibit_rules） | Alertmanager | 机房级故障抑制其下所有主机的小告警 |
| 静默（silence） | Alertmanager | 维护窗口期间整片静音 |
| 灯色分级、TTS 文案、重复次数 | 终端 | 通知组统一语义，不随告警源变化 |
| 队列与跳过 | 终端 | 极端风暴下的最后防线 |
反模式是两边抢活：在 Alertmanager 里用 repeat_interval 疯狂重发"确保终端收到"，又在终端配无限循环------两边叠加的结果就是喇叭念经。原则：Alertmanager 重发要克制（4 小时量级），终端重复按通知组语义走。
三、完整配置：alertmanager.yml
yaml
route:
receiver: bolin-warning # 默认兜底
group_by: ["alertname", "place"]
group_wait: 30s # 等同类聚齐再发，牺牲30s换降噪
group_interval: 5m
repeat_interval: 4h # 未恢复的重发周期，别配成分钟级
routes:
- match_re: {severity: "critical|disaster"}
receiver: bolin-critical
group_wait: 5s # critical 少聚快发
repeat_interval: 30m
receivers:
- name: bolin-critical
webhook_configs:
- url: "http://192.168.0.66/api/api/user_msg/am-critical"
send_resolved: true # 恢复事件必须送，否则红灯不转绿
- name: bolin-warning
webhook_configs:
- url: "http://192.168.0.66/api/api/user_msg/am-warning"
send_resolved: true
inhibit_rules:
# 同一 place 下，critical 存在时抑制 warning，防止喇叭被小告警刷屏
- source_match_re: {severity: "critical|disaster"}
target_match: {severity: "warning"}
equal: ["place"]三个设计点：
- 两个 receiver 对应终端上两个自定义 API 地址（或同一地址不同参数）------分级映射在路由层就完成，终端页面把两个地址映射到 critical / warning 通知组即可，转发器都不用写；
send_resolved: true是恢复配对的前提 。Alertmanager 的恢复事件是同一条 alert 带status=resolved重发，终端侧（或自定义 API 映射）按status字段决定播恢复还是播告警；group_wait: 30s不是故障。看到告警延迟 30 秒先查是不是自己在 group_wait 里等同类------critical 路由单独收紧到 5s，兼顾降噪与速度。
四、告警规则侧：labels 是路由的原料
Alertmanager 的分级与抑制都靠 labels，规则里就要把字段埋好：
yaml
groups:
- name: host-alerts
rules:
- alert: DiskWillFillIn4Hours
expr: predict_linear(node_filesystem_avail_bytes[6h], 4*3600) < 0
labels:
severity: warning
place: "机房B-机柜07" # inhibit 的 equal 键与播报文案共用
annotations:
description: "磁盘预计 4 小时内写满，当前剩余 {{ $value | humanize }}"place 这个 label 一鱼三吃：inhibit 的配对键、分组键、播报文案的位置名。位置命名直接用终端 TTS 里想听到的说法------label 是"机房B-机柜07"，喇叭念的就是它，别到转发器里再做一次翻译。
五、联调三步：不等真实故障
bash
# 1. 配置语法检查
amtool check-config alertmanager.yml
# 2. 模拟一条 critical 告警直接打终端的自定义 API，先验证终端侧
curl -X POST "http://192.168.0.66/api/api/user_msg/am-critical" \
-H "Content-Type: application/json" \
-d '{"alerts":[{"status":"firing","labels":{"alertname":"测试","place":"机房B-机柜07","severity":"critical"},"annotations":{"description":"联调测试"}}]}'
# 3. 恢复事件：同 alert 带 status=resolved 重发，验证绿灯与循环终止三步全绿，再把 Alertmanager 的真实路由接上。真实告警触发后，用 Alertmanager 自带的 /api/v2/alerts 与终端播报日志两侧对账，确认链路无丢包。
六、常见坑
repeat_interval配成分钟级 → 未恢复事件反复推送，与终端重复播报叠加成噪音，4 小时量级起步；send_resolved没开 → 永远没有恢复事件，绿灯不存在，循环播报无法终止；group_wait被当故障 → 告警"延迟 30 秒"其实是聚合等待，critical 路由单独收紧即可；- inhibit 不生效 →
equal键在 source 与 target 的 labels 上不一致（一个有place一个没有），抑制规则形同虚设； - severity 拼写不统一 → 规则里
critical/Critical/crit混用，路由 match_re 匹配不全； - 所有告警走一个 receiver → 分级失效，喇叭一视同仁地急报，warn 稀释了 crit；
- annotations 没写 description → 转发器只能播 alertname 这类内部代号，喇叭念
DiskWillFillIn4Hours； - 维护期不配静默 → 升级窗口告警狂响，用 amtool 或界面建 silence，比拔线体面。
七、验收清单
-
amtool check-config通过，/api/v2/alerts可见测试告警； - critical 与 warning 各自走进正确 receiver，终端灯色与播报符合通知组语义；
- 同 place 的 critical 触发时，其下 warning 被抑制，喇叭不刷屏；
-
send_resolved生效：恢复事件绿灯一次，循环播报终止； - group_wait / repeat_interval 与终端重复次数无叠加噪音；
- 规则 labels 的 place 命名与播报文案一致，无需二次翻译；
- 维护窗口 silence 流程有文档，升级演练走一次。
八、小结
Alertmanager 接声光终端的本质，是把云原生监控里最成熟的告警治理能力，接到物理世界最直接的通知介质上 。设计的核心是分工：Alertmanager 用 route / group / inhibit 把该聚的聚、该压的压，终端用通知组把该响的响、该亮的亮------send_resolved 打通恢复配对，place label 贯通抑制与文案，两行配置换来整条链路的语义一致。
至此本系列覆盖了两大主流监控体系：Zabbix 篇是传统机房的地基，本篇是云原生体系的标准件。无论哪条路，终点都是同一个------告警响起的地方，正好站着能处理它的人。