Prometheus告警通知如何自定义，告警方式怎么配置？
实现自定义 Prometheus 告警通知方式，核心是把 Alertmanager 的 receiver、route 和模板配好，再用一个稳定的 Webhook 接收端把告警送到企业微信、飞书、工单或短信通道。默认邮件只能兜底，真到值班和故障复盘，通知得能分组、能抑制、能带上下文。
默认告警通知为什么总在关键时刻掉链子
你如果真在生产环境值过班，会发现默认邮件通知的问题很具体：一个磁盘告警刷出几十封邮件，同一条告警反复发，恢复通知又迟迟不来。值班的人被淹没，真正需要处理的 critical 告警反而被刷过去。
常见问题集中在几处：
- 告警没有按集群、团队、级别分组，所有通知挤在一个邮箱里。
- 重复告警没有抑制，同一实例的 warning 和 critical 同时轰炸。
- 通知里只有告警名，没有 dashboard、runbook 和值班人，收到也不知道下一步做什么。
- 恢复通知缺失，故障处理完还要手动确认哪些告警已经恢复。
行业共识认为，告警通知的目标是让对的人在对的时间做对的动作。数量多不等于覆盖全，通知链路要先解决“可路由”和“可执行”。
Prometheus告警通知方式怎么选：先看告警链路和团队边界
Prometheus 负责评估告警规则，Alertmanager 负责去重、分组、抑制、静默和路由，最后把通知交给 receiver。自定义通知方式，本质上是在 receiver 这一层做选择。
Prometheus自定义告警通知对比：原生receiver和Webhook中转差在哪
| 方式 | 实现成本 | 可控性 | 适合场景 | 注意点 |
|---|---|---|---|---|
| Alertmanager 原生 receiver | 低 | 中 | 邮件、Slack、PagerDuty、简单 webhook | 消息格式固定，企业微信、飞书等 IM 适配弱 |
| 自建 Webhook 中转 | 中 | 高 | 企业微信、飞书、钉钉、工单、短信通道 | 要处理鉴权、限流、重试和幂等 |
| 商业化告警平台 | 高 | 中高 | 多团队、值班升级、电话通知、审计 | 按告警量或坐席计费，注意数据边界 |
按 Prometheus 官方文档，Alertmanager 的 webhook_configs 会把告警以 JSON POST 到指定地址。企业微信、飞书、钉钉的消息格式和 Alertmanager 默认推送格式不一致，所以常见做法是加一层接收端做转换。
Prometheus告警如何接入企业微信：用Webhook做一层中转
操作路径不复杂，关键是接收端别写成一次性脚本。
- 在企业微信群里添加群机器人，拿到 webhook 地址。群机器人有频率限制，接收端要加队列。
- 写一个接收端服务，解析 Alertmanager 推送的 JSON。JSON 里有 version、status、alerts 数组，每个 alert 带 labels、annotations、startsAt、endsAt 和 fingerprint。
- 把告警转成企业微信消息格式，例如 {“msgtype”:”markdown”,”markdown”:{“content”:”…”}}。content 里放告警名、级别、实例、摘要和