Prometheus 告警接入 Flashduty，最短路径其实很简单。
不用替换 Prometheus。
不用重写告警规则。
不用先把所有团队和值班表都设计完。
第一步只要做一件事：让 Alertmanager 通过 Webhook 把告警推送到 Flashduty。
告警进来以后，Flashduty 再负责后面的响应链路：生成故障、聚合降噪、分派、通知、认领、升级、时间线和分析。
这篇文章不是讲“Alertmanager 够不够用”。那是另一篇选型文章要讨论的问题。
这篇只解决一个很具体的目标：
用 10 分钟，把第一条 Prometheus 告警接进 Flashduty，并确认它能通知到人。
接入前先确认三件事
不要一上来就改 Alertmanager 配置。
先确认三个前提。
第一，你有权限修改 Alertmanager 配置。
Prometheus 告警通常由 Alertmanager 负责接收、分组、路由和通知。Flashduty 的 Prometheus 集成，本质上是给 Alertmanager 增加一个 Webhook receiver。所以你需要能修改 alertmanager.yml，并能重新加载 Alertmanager 配置。
第二，Alertmanager 能访问 Flashduty 的推送地址。
如果 Alertmanager 部署在内网、Kubernetes 集群或受限网络里，要确认它能访问集成推送地址对应的公网域名。如果不能直连，需要提前准备代理，或者开通网络访问。
第三，Alertmanager 版本不太旧。
Flashduty 文档适配 Alertmanager 0.16.0 及以上版本。大多数当前环境都满足，但老集群最好先确认一下版本。
如果这三件事没问题，接入就很直接。
先选接入方式：专属集成还是共享集成
Flashduty 有两种告警接入方式：专属集成和共享集成。
刚开始试用 Prometheus 告警时，我建议优先用专属集成。
原因很简单：少一个变量。
专属集成是在某个协作空间里创建的。Alertmanager 推送过来的告警会直接进入这个空间，不需要额外配置路由规则。你只要确认告警进来了、故障生成了、分派策略通知到了人，就算跑通第一步。
共享集成适合公司级 Prometheus 或统一 Alertmanager。
如果一个 Alertmanager 覆盖多个业务团队，希望按 team、service、env、severity 等标签把告警分发到不同协作空间，就应该使用共享集成。共享集成会先接收告警，再通过路由规则投递到一个或多个协作空间。
这里有一个重要提醒：
共享集成必须配置路由规则。
如果没有路由规则，告警没有协作空间承接，就可能收不到预期效果。第一次接入时如果只是想验证链路，专属集成更稳。
可以按这个判断：
一个业务、一个团队、一次试用验证：用专属集成。
一个 Alertmanager 覆盖多个团队：用共享集成。
需要按标签分发到不同空间：用共享集成。
不确定怎么选：先用专属集成跑通，再升级为共享集成。
不要一开始就追求全公司统一接入。
先把第一条真实告警跑通。
第一步：在 Flashduty 创建 Prometheus 集成
如果使用专属集成，路径是：
协作空间
→ 进入某个空间详情
→ 集成数据
→ 添加集成
→ 选择 Prometheus
→ 保存
→ 复制推送地址
这个推送地址就是后面要填到 Alertmanager 里的 Webhook URL。
如果使用共享集成，路径是：
集成中心
→ 告警事件
→ 添加集成
→ 选择 Prometheus
→ 填写集成名称
→ 配置默认路由或保存后配置路由
→ 复制推送地址
共享集成创建完成后，建议至少配置一条兜底路由，把无法匹配的告警投递到一个测试空间或 SRE 空间。这样即使标签还不规范，也不会因为路由没命中而误以为 Alertmanager 没推送成功。
推送地址里通常会带 integration_key 这类参数。
复制时要复制完整 URL。
不要只复制域名或路径。
第二步：在 Alertmanager 增加 Flashduty receiver
打开 Alertmanager 配置文件，通常是 alertmanager.yml。
在 receivers 里增加一个 Webhook receiver：
receivers:
- name: flashduty
webhook_configs:
- url: '<Flashduty Prometheus 集成推送地址>'
send_resolved: true
这里最重要的是两点。
第一，把 url 替换成刚才复制的完整推送地址。
第二，建议设置 send_resolved: true。
Prometheus 告警有触发和恢复两个方向。如果不发送恢复事件，Flashduty 可能无法准确感知告警恢复状态，后续故障关闭、恢复时间和 MTTR 判断都会受影响。
如果 Alertmanager 需要通过代理访问 Flashduty，可以增加 http_config.proxy_url：
receivers:
- name: flashduty
webhook_configs:
- url: '<Flashduty Prometheus 集成推送地址>'
send_resolved: true
http_config:
proxy_url: 'http://proxyserver:port'
代理地址按你的网络环境填写。
第三步：把告警路由到 Flashduty
接下来要让 Alertmanager 的 route 使用这个 receiver。
最简单的方式，是把默认 receiver 指向 Flashduty：
route:
receiver: flashduty
但生产环境通常不建议第一步就改默认路由。
如果你已经有飞书、钉钉、企业微信、邮件或其他通知渠道，可以先把 Flashduty 放到子路由里，只接一部分告警。
比如只接 severity=critical 的告警：
route:
receiver: default-receiver
routes:
- matchers:
- severity="critical"
receiver: flashduty
如果你希望旧通知渠道和 Flashduty 并行运行，要注意 Alertmanager 的 continue 语义。
continue: true 只会让告警继续匹配后续同级子路由，不能简单理解成“同时发送给根路由的默认 receiver”。如果你已有一条旧的子路由，可以把 Flashduty 路由放在它前面，并开启 continue: true：
route:
receiver: default-receiver
routes:
- matchers:
- severity="critical"
receiver: flashduty
continue: true
- matchers:
- severity="critical"
receiver: existing-critical-receiver
这样同一条 Critical 告警会先发送到 Flashduty，再继续命中后面的旧通知 receiver。
如果你的旧通知只配置在根路由默认 receiver 上，没有对应子路由，建议先为旧通知补一条明确的子路由，再做并行验证。
试用阶段，我更推荐并行运行。
也就是旧链路继续通知，Flashduty 同时接收同一批告警。等你确认 Flashduty 的接入、分派、通知、认领和升级都稳定，再逐步切换正式响应链路。
如果你只想让某个业务先进入 Flashduty，可以按 service 或 team 标签过滤：
route:
receiver: default-receiver
routes:
- matchers:
- service="payment"
receiver: flashduty
这比全量切换更稳。
第四步：重新加载 Alertmanager 配置
保存配置后，需要让 Alertmanager 重新加载。
常见方式有两种。
一种是向进程发送 SIGHUP 信号。
另一种是调用 reload API：
curl -X POST http://localhost:9093/-/reload
具体用哪种方式，取决于你的部署方式。
如果 Alertmanager 跑在 Kubernetes 里，可能还涉及 ConfigMap 更新、Pod 滚动或 sidecar reload。这里不展开，核心原则只有一个：确认新配置已经生效。
重新加载后，建议检查 Alertmanager 日志。
如果配置 YAML 写错、receiver 名称不匹配、URL 不合法，日志里通常能看到错误。
不要等半小时没告警再回头排查。
第五步：触发一条测试告警
接入是否成功，不要靠猜。
一定要触发一条测试告警。
测试告警应该尽量满足三个条件。
第一，它是真正从 Prometheus 规则触发，经 Alertmanager 推送出来的。
不要只用 curl 模拟一个 Webhook 请求。curl 能测网络，但不能验证 Prometheus 规则、Alertmanager 分组、路由、恢复事件和标签映射。
第二，它要带上关键标签。
至少建议带：
alertname
severity
service
env
team
instance 或 resource
第三，它最好能恢复。
这样你可以验证 send_resolved: true 是否生效，Flashduty 里关联告警和故障状态是否按预期变化。
一个测试规则可以很简单。
比如用 vector(1) 触发一个短期测试告警：
groups:
- name: flashduty-test
rules:
- alert: FlashdutyTestAlert
expr: vector(1)
for: 1m
labels:
severity: warning
service: demo
env: staging
team: sre
annotations:
summary: "Flashduty test alert"
description: "This is a test alert for Flashduty integration."
测试完成后，记得删除或停用这条规则。
如果你不想新增规则，也可以选择一个低风险、可控的已有测试环境告警。
不要拿生产 Critical 规则做第一次验证。
第六步：在 Flashduty 看最新事件时间
测试告警触发后，先看 Flashduty 集成卡片。
如果集成卡片显示了最新事件时间，说明 Flashduty 已经收到 Alertmanager 推送。
这是第一道分界线。
如果最新事件时间没有变化，优先查 Alertmanager：
Prometheus 是否真的触发了告警？
Alertmanager 是否收到了告警？
路由是否命中 Flashduty receiver？
receiver URL 是否完整？
Alertmanager 能否访问推送地址？
是否被代理、防火墙、DNS 或证书问题拦住？
Alertmanager 日志里有没有 webhook 发送失败？
如果集成卡片有最新事件时间，但协作空间里没有看到故障，就要查 Flashduty 侧：
你用的是不是共享集成？
共享集成是否配置了路由规则？
告警是否命中了路由条件？
是否有默认兜底路由？
是否被告警处理 Pipeline 过滤或丢弃？
排查时不要混在一起看。
先确认“有没有收到推送”，再确认“有没有路由到空间”，最后确认“有没有触发分派和通知”。
第七步：检查生成的故障
告警进入协作空间后，Flashduty 会生成故障。
打开故障详情，重点看几件事。
标题是否能看懂。
严重程度是否正确。
标签是否完整。
关联告警是否存在。
时间线里是否有触发和分派记录。
处理人员是否符合预期。
恢复事件是否能合入同一告警。
Prometheus 的标签会被 Flashduty 按“应取尽取”的原则提取出来。后续路由、聚合、降噪、检索和分析都会依赖这些标签。
所以，第一次接入时不要只看“有没有通知”。
还要看标签质量。
如果标签缺失，后面会有很多问题。
例如：
没有 service，很难按业务服务路由。
没有 team，很难按团队分派。
没有 env，生产和测试告警容易混在一起。
没有 severity，Critical 和 Warning 可能无法区分。
没有 resource 或 instance，告警对象分析会变弱。
接入第一天就把标签看清楚，比后面补救轻松很多。
Prometheus 严重程度怎么映射
Flashduty 会从 Prometheus 告警事件标签中依次提取 severity、priority 和 level，作为 Prometheus 自身的告警等级。
如果没有提取到，系统会默认设置为 Warning。
常见映射关系是：
critical -> Critical
warning -> Warning
warn -> Warning
info -> Info
ok -> Ok
所以建议 Prometheus 规则里统一使用 severity 标签。
例如：
labels:
severity: critical
service: payment
env: production
team: payment-sre
不要一部分规则用 severity=critical，另一部分规则用 level=P1，还有一部分规则没有级别。
规则越乱，后续分派和统计越难。
如果历史规则短期内改不了，可以用 Flashduty 的标签增强或告警处理能力做补充和转换。但最好的方式，还是从 Prometheus 规则层面把标签规范起来。
要不要配置 timestamp
默认情况下，Flashduty 会使用当前时间作为事件触发时间。
如果你希望上报 Prometheus 告警发生的准确时间，可以在告警规则的 annotations 里增加 timestamp 字段：
annotations:
timestamp: '{{ with query "time()" }}{{ . | first | value }}{{ end }}'
这不是每个团队第一天都必须做的事。
如果只是跑通链路，先不配也可以。
但如果你很关注时间口径，尤其是希望更准确分析触发时间、认领时间和恢复时间，建议后续补上。
时间口径越准确，MTTA、MTTR 和复盘时间线越可信。
第八步：配置第一条分派策略
告警接进来，只完成了一半。
下一步要验证的是：它会不会通知到正确的人。
在 Flashduty 协作空间里，进入分派策略，先配置一条简单规则。
试用阶段不要做太复杂。
例如：
触发条件：severity=Critical 或 severity=Warning
通知对象：自己或试点值班人
通知方式：App 推送 + IM 单聊
群聊同步：试点业务群
升级规则：10 分钟未认领升级给备份处理人
如果你还没有正式值班表，可以先通知个人。
但这只能用于首次验证。
真正进入生产后，生产告警不应该长期绑定固定个人，而应该通知当前值班表，必要时按主备值班和升级规则处理。
配置完成后，再触发一次测试告警。
这次要验证：
值班人是否收到通知。
通知渠道是否符合预期。
IM 卡片是否能打开故障。
处理人能否认领。
认领后故障进度是否变为处理中。
时间线是否记录通知和认领动作。
如果只是管理员在控制台里看到故障，不算真正跑通。
On-call 的关键是通知到人，并且能留下响应动作。
第九步：先别急着全量切换
第一条 Prometheus 告警接入成功后，很多团队会想马上把所有 Alertmanager 告警都切到 Flashduty。
不建议。
更稳的做法是分阶段。
第一阶段，单业务试点。
只接一个服务或一个团队的告警，验证 Webhook、标签、故障生成、分派和通知。
第二阶段，并行运行。
旧通知渠道继续保留，Flashduty 同时接收告警。这个阶段重点看是否有丢告警、重复告警、标签错误、路由错误和通知不符合预期。
第三阶段，接入值班表和升级。
把固定个人通知改成当前值班人，配置主备和值班升级。验证无人认领时能否自动升级。
第四阶段，开启降噪。
根据告警特点配置规则聚合或智能聚合，把重复告警合并成一条故障。再观察告警压缩效果、Critical 响应比例和夜间中断次数。
第五阶段，推广到更多业务。
如果你用的是共享集成，就逐步补充路由规则；如果一开始用专属集成，也可以在明确标签和空间边界后迁到共享集成。
On-call 平台接入的目标不是“告警都进来了”。
目标是“关键故障能被正确响应”。
Prometheus 标签建议
Prometheus 告警能不能后续治理，标签很关键。
建议至少统一这些标签：
severity：告警级别，例如 critical、warning、info
service：业务服务，例如 payment、order、gateway
env：环境，例如 production、staging、test
team：负责团队，例如 sre、payment-sre、platform
cluster：集群，例如 prod-shanghai-01
instance/resource：告警对象，例如主机、Pod、实例、数据库
check：告警检查项，例如 cpu_idle、http_5xx_rate、disk_usage
其中 severity 影响严重程度映射，service 和 team 影响路由和分派，resource 和 check 会影响告警对象和告警检查项分析。
标签不是越多越好。
关键是稳定、统一、可用于路由和分析。
比如同一个含义不要同时出现 service、app、application 三种写法。否则后面做共享集成路由、告警聚合和分析看板时会很痛苦。
如果历史规则已经很乱，可以先从试点业务开始统一。
不要试图第一天改完所有 Prometheus 规则。
常见问题
常见问题一：Flashduty 没收到告警
先看集成卡片有没有最新事件时间。
如果没有，问题大概率在 Alertmanager 到 Flashduty 之间。
按这个顺序查：
Prometheus 是否触发了告警。
Alertmanager UI 是否能看到这条告警。
Alertmanager route 是否命中 Flashduty receiver。
receiver 名称是否拼写一致。
Webhook URL 是否复制完整，尤其是 query string。
Alertmanager 是否能访问推送地址域名。
代理配置是否正确。
Alertmanager 日志是否有 webhook 发送失败。
不要一开始就改 Flashduty 分派策略。
如果 Flashduty 连事件都没收到，分派策略不会生效。
常见问题二：集成有最新事件，但空间里没有故障
这种情况通常发生在共享集成。
重点检查路由规则。
共享集成需要路由规则把告警投递到协作空间。建议至少配置一个默认路由作为兜底。
还要检查：
路由匹配条件是否写错。
告警标签是否真的存在。
Labels.team、Labels.service 等路径是否和规则一致。
流程控制是否符合预期。
名称映射模式下，标签值对应的协作空间是否存在。
如果路由条件太复杂，先临时改成默认路由，确认告警能进入空间，再逐步加条件。
常见问题三：严重程度不对
先看 Prometheus 告警标签。
Flashduty 会依次提取 severity、priority、level。
如果这些标签都没有，默认就是 Warning。
如果你期望 Critical，但实际是 Warning，常见原因是：
Prometheus 规则没有 severity。
写成了 Severity 或其他大小写不一致的标签。
值写成了内部枚举，例如 P0、P1，没有被直接映射。
Alertmanager 路由或模板没有影响标签，但你以为它会转换。
解决方式有两个。
最好是在 Prometheus 规则里统一 severity。
如果短期改不了，可以在 Flashduty 侧使用标签增强或告警处理 Pipeline 做转换。
常见问题四：收到太多重复故障
先确认这是 Alertmanager 分组问题，还是 Flashduty 聚合问题。
Alertmanager 的 group_by、group_wait、group_interval、repeat_interval 会影响通知分组和重复推送。
Flashduty 则是在告警进入后，把相似告警聚合为故障。你可以在协作空间的降噪配置里开启规则聚合或智能聚合。
不要简单地把所有告警都静默。
更好的方法是：
先保留 Critical 告警可靠触达。
再把重复告警按 service、resource、check 等维度聚合。
对抖动告警启用抖动检测或延迟通知。
对维护窗口使用静默策略。
观察压缩率、响应比例和中断次数。
降噪的目标不是让告警变少。
而是让值班人只被真正需要处理的故障打扰。
常见问题五：通知到了群里，但没人认领
这说明接入成功，但 On-call 机制还没跑通。
群通知只是同步信息。
真正的响应要有处理人、认领和升级。
建议立刻补三件事：
第一，分派给具体人员或值班表，而不是只发群。
第二，Critical 告警配置 App、电话、短信或 IM 单聊，不要只依赖群机器人。
第三，配置未认领升级。比如 10 分钟未认领升级给备值班，30 分钟未关闭升级给负责人。
否则你只是把 Prometheus 告警从一个群转发到了另一个群。
这不是 On-call。
接入成功后，下一步做什么
第一条 Prometheus 告警接入成功后，建议按这个顺序继续。
第一，统一标签。
先把试点业务的 severity、service、env、team、resource、check 补齐。
第二，配置分派策略。
让生产 Critical 告警通知当前值班人，低级别告警只进合适的 IM 群或弱通知渠道。
第三，配置值班表。
不要长期把告警绑给固定个人。至少为生产服务配置主值班和备值班。
第四，配置升级。
无人认领或未关闭时自动升级，避免关键故障被遗漏。
第五，开启降噪。
先用规则聚合处理重复告警，再视情况使用智能聚合、抖动检测、延迟通知和静默策略。
第六，看分析数据。
观察 MTTA、MTTR、响应比例、中断次数、告警检查项 TOP 和告警对象 TOP。用数据判断接入是否真的改善响应效率。
一份 10 分钟接入检查清单
可以把这次接入压缩成一张清单：
[ ] 确认 Alertmanager 版本和配置权限
[ ] 确认 Alertmanager 能访问 Flashduty 推送地址
[ ] 在 Flashduty 创建 Prometheus 专属集成或共享集成
[ ] 复制完整推送地址
[ ] 在 alertmanager.yml 增加 flashduty receiver
[ ] 设置 send_resolved: true
[ ] 在 route 中把测试告警路由到 flashduty receiver
[ ] 重新加载 Alertmanager 配置
[ ] 触发一条真实测试告警
[ ] 在 Flashduty 集成卡片确认最新事件时间
[ ] 在协作空间确认生成故障
[ ] 检查严重程度、标签、关联告警和时间线
[ ] 配置分派策略并验证通知到人
[ ] 让值班人认领一次，确认时间线记录
这张清单跑完，才算真正完成第一步激活。
不是“Webhook 配好了”。
而是“Prometheus 告警已经进入 Flashduty，并且能推动人响应”。
最后：Prometheus 不需要被替换
把 Prometheus 告警接入 Flashduty，不是让你放弃 Prometheus 或 Alertmanager。
Prometheus 继续负责采集指标和触发告警。
Alertmanager 继续负责告警分组、路由和 Webhook 推送。
Flashduty 负责把告警变成可响应、可认领、可升级、可复盘的故障。
这条边界要清楚。
很多团队接入 On-call 平台失败，是因为一开始想做太多。
第一天不需要把所有告警源都接进来。
第一天只要选一个真实业务，接入一条 Prometheus 告警，让它进入正确协作空间，通知到正确的人，并留下认领和处理记录。
跑通这条链路以后，再谈路由、降噪、值班表、升级、分析和复盘。
Flashduty 的价值不是替换你的监控系统。
而是先帮你把 Prometheus 告警接住、分派出去，并确保关键故障真的有人处理。
👉 现在注册试用
资料依据：
- Flashduty 文档：Prometheus 告警集成、入门指南、集成数据、路由规则、分派策略、告警降噪、分析看板。
- Prometheus 接入口径：通过 Alertmanager Webhook receiver 推送到 Flashduty，支持 Alertmanager 0.16.0 及以上版本，建议
send_resolved: true。 - Flashduty 严重程度映射：依次提取
severity、priority、level，critical映射 Critical，warning/warn映射 Warning，info映射 Info，ok映射 Ok；未提取到时默认 Warning。
