Zabbix 接入 Flashduty，不是要替换 Zabbix。
Zabbix 继续负责监控主机、网络、数据库、中间件和各种基础设施。Flashduty 负责接住 Zabbix 发出来的告警，把它变成可分派、可认领、可升级、可复盘的故障。
这篇文章只解决一个具体目标：
用 10 分钟，把第一条 Zabbix 告警接入 Flashduty，并确认它能生成故障、通知到人。
如果你已经有一套运行多年的 Zabbix，不需要先重构模板、触发器和主机组。
先跑通一条告警链路。
后面再逐步做标签规范、路由、降噪、值班表和升级策略。
接入前先确认三件事
第一，确认 Zabbix 版本。
Flashduty 的 Zabbix 集成覆盖 Zabbix 3.x 到 7.x，但不同版本的配置方式不一样。
Zabbix 7.x 使用 YAML media type 配置。
Zabbix 6.x 使用 YAML media type 配置。
Zabbix 5.x 使用 XML media type 配置。
Zabbix 3.x 到 4.x 使用脚本方式，需要在 Zabbix Server 上放置脚本。
不要用 7.x 的控制台路径去套 4.x，也不要用旧脚本方式去配置 6.x。
版本先确认清楚，后面会少很多排错时间。
第二，确认你能配置 media type、user 和 action。
Zabbix 通知链路里，media type 是通知通道，user 是接收对象，action 决定什么事件触发通知。Flashduty 接入也遵循这个模型。
你至少需要能：
导入或创建 media type。
给某个 user 关联这个 media type。
创建 Trigger action。
配置 Problem、Recovery、Update 三类操作。
第三，确认 Zabbix Server 能访问 Flashduty 推送地址。
如果 Zabbix Server 在内网，不能访问外网推送地址，需要配置代理。Flashduty 的 Zabbix media type 配置里有 HTTPProxy 参数，可以按实际网络环境填写。
如果这三件事都没问题，接入就很直接。
先选 Flashduty 接入方式
和 Prometheus 一样，Zabbix 接入 Flashduty 也有两种方式：专属集成和共享集成。
第一次接入，建议用专属集成。
路径短，变量少。
专属集成是在某个协作空间里创建的。Zabbix 告警会直接进入这个空间，不需要额外路由规则。你只要确认 Zabbix 事件进来了、故障生成了、分派策略通知到了人，就算完成第一步激活。
共享集成适合公司级 Zabbix。
如果一套 Zabbix 同时覆盖多个业务团队，希望按主机组、业务标签、严重程度或负责人把告警分发到不同协作空间，就应该使用共享集成。共享集成会先接收事件，再通过路由规则投递到对应空间。
可以按这个标准选：
单团队试用：专属集成。
一个业务空间验证：专属集成。
多团队共用 Zabbix：共享集成。
需要按 host_group、team、service 路由：共享集成。
不确定怎么选：先专属集成跑通，再升级共享集成。
不要第一天就把全公司 Zabbix 告警都切过来。
先选一个真实业务或一个测试主机组，把链路跑通。
第一步：在 Flashduty 创建 Zabbix 集成
如果使用专属集成，路径是：
协作空间
→ 进入某个空间详情
→ 集成数据
→ 添加集成
→ 选择 Zabbix
→ 保存
→ 复制推送地址
这个推送地址后面会填到 Zabbix media type 的 URL 参数里。
如果使用共享集成，路径是：
集成中心
→ 告警事件
→ 添加集成
→ 选择 Zabbix
→ 填写集成名称
→ 配置默认路由或保存后配置路由
→ 复制推送地址
共享集成一定要配置路由规则。
建议至少配置一条默认路由，把无法匹配的告警投递到一个测试空间或 SRE 兜底空间。否则你可能会遇到“Zabbix 显示发送成功，但 Flashduty 空间里没有故障”的情况。
复制推送地址时要复制完整 URL。
不要漏掉 query string 参数。
第二步：按 Zabbix 版本配置 media type
Zabbix 里的 media type 可以理解成“通知媒介”。
Flashduty 提供了不同版本的 media type 配置文件。你需要先下载对应版本文件，然后导入 Zabbix。
Zabbix 7.x
下载配置：
wget --header="Referer: https://console.flashcat.cloud" https://download.flashcat.cloud/flashduty/integration/zabbix/zbx_mediatype_flashcat_v7.yml
进入 Zabbix 控制台：
Alert
→ Media Types
→ Import
→ 选择下载的 yml 文件
→ Import
导入后进入这个 media type，补全几个参数：
URL：填写 Flashduty Zabbix 集成推送地址
zabbix_url：填写 Zabbix 控制台地址
HTTPProxy：如果 Zabbix Server 不能直连外网，填写代理地址
保存即可。
Zabbix 5.x 到 6.x
Zabbix 5.x 下载 XML：
wget --header="Referer: https://console.flashcat.cloud" https://download.flashcat.cloud/flashduty/integration/zabbix/zbx_mediatype_flashcat_v5.xml
Zabbix 6.x 下载 YAML：
wget --header="Referer: https://console.flashcat.cloud" https://download.flashcat.cloud/flashduty/integration/zabbix/zbx_mediatype_flashcat_v6.yml
进入 Zabbix 控制台：
Administration
→ Media Types
→ Import
→ 选择下载的配置文件
→ Import
导入后同样补全：
URL：填写 Flashduty Zabbix 集成推送地址
zabbix_url：填写 Zabbix 控制台地址
HTTPProxy：按网络情况填写代理地址，可为空
Zabbix 3.x 到 4.x
老版本使用脚本方式。
先在 Zabbix 控制台创建 media type：
Administration
→ Media Types
→ Create media type
→ Type 选择 Script
→ Script name 填写 send-to-flashduty.sh
参数顺序很重要，不要调整：
第 1 个参数：{ALERT.SUBJECT}
第 2 个参数：{ALERT.MESSAGE}
第 3 个参数：Flashduty Zabbix 集成推送地址
第 4 个参数：Zabbix 控制台地址
第 5 个参数：HTTPProxy，可为空
然后到 Zabbix Server 的告警脚本目录下载脚本。
目录通常是 /usr/lib/zabbix/alertscripts，实际以 Zabbix Server 配置里的 AlertScriptsPath 为准。
cd /usr/lib/zabbix/alertscripts
wget --header="Referer: https://console.flashcat.cloud" https://download.flashcat.cloud/flashduty/integration/zabbix/send-to-flashduty.sh
chmod +x send-to-flashduty.sh
这个脚本依赖 curl 和 jq。
如果 Zabbix Server 上没有这两个命令，需要先安装。
老版本最容易出问题的地方就是脚本权限、脚本路径、参数顺序和依赖命令。
排错时先查这四件事。
第三步：把 media type 关联到 user
media type 创建好以后，还不能直接发通知。
它必须关联到某个 Zabbix user。
这个 user 至少要对相关 host 有 read 权限，否则可能无法正常发送或补全告警信息。首次验证可以先关联到 Admin 用户，等链路跑通后再按权限要求调整。
Zabbix 7.x 的路径通常是：
Users
→ Users
→ 选择 Admin 或目标 user
→ Media
→ Add
Zabbix 5.x 到 6.x 的路径通常是：
Administration
→ Users
→ 选择 Admin 或目标 user
→ Media
→ Add
添加时：
Type：选择刚才导入或创建的 Flashduty media type
Send To：7.x 可填写 Flashduty；5.x/6.x 可填写 N/A
其他配置保持默认
保存 user 配置。
这里有一个常见误区：
这个 user 不是最终值班人。
它只是 Zabbix 侧用来执行通知动作的对象。真正的值班人、主备、升级和通知渠道，后续应该在 Flashduty 的分派策略和值班表里管理。
第四步：创建 Trigger action
接下来配置 Zabbix action。
Zabbix 7.x 路径通常是：
Alerts
→ Actions
→ Trigger actions
→ Create action
Zabbix 5.x 到 6.x 路径通常是：
Configuration
→ Actions
→ Create action
action 名称可以写：
Send To Flashduty
然后在 Operations 里配置三类操作：
Problem operations。
Recovery operations。
Update operations。
每类操作都建议发送到刚才绑定 media type 的 user，并指定只通过 Flashduty media type 发送。
这三类操作都配置很重要。
Problem 表示故障触发。
Recovery 表示故障恢复。
Update 表示故障更新。
如果只配置 Problem，没有配置 Recovery，Flashduty 可能收到触发事件，但收不到恢复事件。后续故障状态、关闭时间、MTTR 和复盘时间线都会受影响。
如果只配置触发，不配置更新，Zabbix 后续补充的信息也可能无法同步。
第一次接入时，建议不要省略这三类操作。
老版本还要补通知内容
如果你使用 Zabbix 3.x 到 4.x 的脚本方式，还需要在 action 的默认消息里追加 Flashduty 需要解析的字段。
Flashduty 文档里提供了一段 -----Flashduty Required Starts----- 到 -----Flashduty Required Ends----- 的内容，里面包含 event_severity、event_name、event_id、event_tags、trigger_id、host_group、host_ip、host_name、item_name、item_value 等字段。
这段内容要完整复制到 Problem、Recovery、Update 三类操作的消息配置里。
不要删字段。
不要改分隔符。
不要只配置 Problem。
老版本脚本方式依赖这段内容解析告警属性。少了它，Flashduty 收到的事件信息会不完整，严重时会影响告警生成和恢复匹配。
第五步：触发一条测试告警
配置完成后，不要只看页面保存成功。
一定要触发一条测试告警。
最稳妥的方式是选择一个测试主机或测试触发器，制造一个可控问题。
测试告警要满足几个条件：
能触发 Problem。
能恢复 Recovery。
不会影响真实生产系统。
严重程度明确。
最好带上主机、主机组、触发器名称和标签。
触发后，在 Zabbix 控制台进入：
Monitoring
→ Problems
→ 找到测试告警
→ 点击 Actions
如果对应 Flashduty 通知的 Status 是 Sent，说明 Zabbix 侧已经执行发送。
然后回到 Flashduty 集成页面。
如果集成卡片显示最新事件时间，说明 Flashduty 已经收到事件。
这是第一道验证。
第六步：检查 Flashduty 是否生成故障
收到事件不等于完成接入。
还要进入对应协作空间，检查是否生成故障。
重点看这些字段：
故障标题是否可读。
严重程度是否正确。
关联告警是否存在。
Zabbix 触发、恢复、更新事件是否合入同一告警。
标签或属性里是否能看到主机、主机组、触发器、检查项等信息。
时间线是否记录触发、分派、通知等动作。
如果你使用的是共享集成，收到事件但没有故障，优先检查路由规则。
共享集成需要把事件投递到协作空间。没有路由规则，或者路由条件写错，就会卡在这里。
建议第一次共享集成接入时，先配置默认路由。
等确认 Zabbix 事件格式和标签质量以后，再按业务规则分流。
Zabbix 严重程度怎么映射
Zabbix 的严重程度会映射到 Flashduty 的标准级别。
常见关系是：
Disaster -> Critical
High -> Critical
Average -> Warning
Warning -> Warning
Information -> Info
Not classified -> Info
所以第一次测试时，建议明确选择一个 severity，不要用 Not classified 之类的默认级别来验证 Critical 通知。
如果你期望电话触达，但测试告警是 Info 级别，而分派策略只给 Critical 打电话，就会误以为通知链路失败。
排查通知问题时，先确认严重程度是否符合分派策略。
第七步：配置第一条分派策略
Zabbix 到 Flashduty 的事件链路跑通以后，下一步要验证通知到人。
在 Flashduty 协作空间里，进入分派策略。
先配置一条简单规则：
触发条件：严重程度为 Critical 或 Warning
通知对象：自己或试点处理人
通知方式：App 推送 + IM 单聊；Critical 可加电话或短信
群聊同步：试点业务群
升级规则：10 分钟未认领升级给备份处理人
如果你还没有值班表，可以先通知固定个人。
但这只是为了验证链路。
生产环境里，Zabbix 告警不应该长期绑定某个固定人。更合理的是通知当前值班表，并配置主备和值班升级。
配置完成后，再触发一次测试告警。
这次不要只看故障是否生成。
要让真实处理人完成一次认领。
验证：
处理人是否收到通知。
通知渠道是否正确。
IM 或 App 能否打开故障详情。
能否认领故障。
认领后故障是否进入处理中。
时间线是否记录通知和认领动作。
On-call 激活的关键不是“Zabbix 显示 Sent”。
而是“有人收到、有人认领、系统留下记录”。
第八步：先别全量推送
Zabbix 环境里的告警通常很多。
接入成功以后，不要马上把所有触发器都通过 Flashduty 强通知。
更稳的方式是分阶段。
第一阶段，接入一个测试主机组或一个业务空间。
只验证链路，不追求全量覆盖。
第二阶段，接入少量高价值告警。
比如生产环境的 Disaster 和 High 级别告警。先验证 Critical 链路是否可靠。
第三阶段，并行运行。
保留原来的 Zabbix 通知方式，同时让 Flashduty 接收同一批告警。观察是否有丢事件、重复事件、恢复事件不匹配和通知不符合预期。
第四阶段，配置分派和值班。
把固定个人改成当前值班人，增加主备升级。
第五阶段，开启降噪。
对重复主机告警、抖动告警、维护窗口告警配置聚合、抖动检测和静默。
第六阶段，推广到更多团队。
如果多团队共用 Zabbix，再使用共享集成和路由规则按团队或服务分流。
这样做比全量切换安全得多。
Zabbix 接入后的标签建议
Zabbix 历史环境里，标签不一定规范。
但 Flashduty 后续的路由、聚合、静默、分派和分析都依赖标签。
建议逐步补齐这些维度：
service：业务服务，例如 payment、order、gateway
team：负责团队，例如 sre、dba、payment-sre
env：环境，例如 production、staging、test
host_group：主机组或业务组
host_name：主机名
host_ip：主机 IP
check：检查项，例如 cpu_idle、disk_usage、agent_ping
severity：严重程度
如果 Zabbix 事件里已有 tags，可以尽量使用已有 tags。
如果缺少关键标签，可以通过 Flashduty 的标签增强补齐。标签增强支持正则提取、映射表和组合等方式。
比如：
从主机组提取 team。
从触发器名称提取 service。
用映射表把主机名映射到负责人或团队。
给某个集成统一补 source=zabbix。
不要试图第一天把所有 Zabbix 模板和触发器都改完。
先从接入的试点范围里统一标签。
常见问题
常见问题一：Zabbix 显示没发送
如果在 Monitoring > Problems > Actions 里看不到 Flashduty 对应发送记录，或者状态不是 Sent，说明问题还在 Zabbix 侧。
优先检查：
Action 是否启用。
Action 条件是否匹配这条 Problem。
Operations 是否配置了正确 user。
Send only to 是否选择了 Flashduty media type。
Problem、Recovery、Update 是否都配置了。
User 是否启用，且是否有 host read 权限。
Media type 是否启用。
对应时间段是否允许发送。
如果是 3.x 到 4.x，还要检查脚本是否可执行、脚本路径是否正确、curl 和 jq 是否存在。
常见问题二：Zabbix 显示 Sent，但 Flashduty 没最新事件
这说明 Zabbix 认为通知已经发出，但 Flashduty 没收到。
重点检查 media type 参数：
URL 是否填写完整推送地址。
推送地址是否复制错了集成。
Zabbix Server 是否能访问外网或 Flashduty 推送域名。
HTTPProxy 是否需要配置。
代理地址是否正确。
Zabbix Server 日志里是否有 Webhook 或脚本错误。
如果你使用 3.x 到 4.x 的脚本方式，还要直接在服务器上测试脚本执行环境。
很多老版本问题不是 Flashduty 没接收，而是脚本根本没有正确跑起来。
常见问题三：Flashduty 有最新事件，但没有故障
这种情况通常发生在共享集成。
优先检查：
是否配置了路由规则。
是否配置了默认路由。
路由条件是否命中当前告警。
名称映射模式下，标签值对应的协作空间是否存在。
是否被告警处理 Pipeline 过滤或丢弃。
排查时可以先临时加一个默认路由，把所有 Zabbix 告警投递到测试空间。
确认能生成故障后，再逐步收紧路由条件。
常见问题四：恢复后故障没有自动关闭
先检查 Zabbix 的 Recovery operations。
如果只配置了 Problem operations，Flashduty 收不到恢复事件，自然无法准确关闭或恢复故障。
还要检查：
Recovery 是否发送给同一个 user。
Send only to 是否仍是 Flashduty media type。
老版本消息模板是否在 Recovery 里也追加了 Flashduty required 字段。
触发事件和恢复事件是否能被识别为同一个问题。
接入时一定要把触发、恢复、更新都测试一遍。
不要只测触发。
常见问题五：通知到了群里，但没人处理
这说明告警接入已经完成，但响应机制还没完成。
群通知只是同步信息。
真正的 On-call 要有处理人、认领和升级。
建议立刻补三件事：
第一，Critical 告警分派给个人或值班表，不要只推群。
第二，配置强触达渠道。比如 App、电话、短信或 IM 单聊。
第三，配置无人认领升级。比如 10 分钟未认领升级给备值班，30 分钟未关闭升级给负责人。
否则你只是把 Zabbix 告警从一个群转发到了另一个群。
这不是告警响应闭环。
接入成功后，下一步做什么
第一条 Zabbix 告警进入 Flashduty 后，建议按这个顺序继续。
第一，统一严重程度。
确认 Zabbix 的 Disaster、High、Average、Warning、Information 是否符合团队实际响应策略。
第二，补齐标签。
先补 service、team、env、host_group、host_name、check。
第三，配置分派策略。
Critical 使用强触达，Warning 使用弱触达或工作时间通知，Info 不进入强通知。
第四，配置值班表。
让生产告警通知当前值班人，而不是固定用户。
第五，配置升级。
无人认领或未关闭时自动升级。
第六，开启降噪。
按主机、主机组、检查项或服务聚合重复告警。对维护窗口配置静默。对抖动告警开启抖动检测。
第七，看分析数据。
关注 MTTA、MTTR、响应比例、中断次数、告警检查项 TOP 和告警对象 TOP。用数据反推 Zabbix 触发器和模板治理。
一份 10 分钟接入检查清单
可以把整个接入压缩成这张清单：
[ ] 确认 Zabbix 版本
[ ] 确认有 media type、user、action 配置权限
[ ] 确认 Zabbix Server 能访问 Flashduty 推送地址
[ ] 在 Flashduty 创建 Zabbix 专属集成或共享集成
[ ] 复制完整推送地址
[ ] 按 Zabbix 版本导入或创建 Flashduty media type
[ ] 补全 URL、zabbix_url、HTTPProxy
[ ] 把 media type 关联到具备 host read 权限的 user
[ ] 创建 Trigger action
[ ] 配置 Problem、Recovery、Update 三类操作
[ ] 触发一条测试告警
[ ] 在 Zabbix Problems 的 Actions 中确认 Status 为 Sent
[ ] 在 Flashduty 集成卡片确认最新事件时间
[ ] 在协作空间确认生成故障
[ ] 检查严重程度、标签、关联告警和时间线
[ ] 配置分派策略并验证通知到人
[ ] 让处理人认领一次，确认时间线记录
这张清单跑完，才算真正完成第一步。
不是“media type 导入成功”。
而是“Zabbix 告警已经进入 Flashduty，并且能推动人响应”。
最后：先接住告警，再治理告警
Zabbix 用户最容易犯的错误，是把接入和治理混在一起。
第一天就想改所有触发器、补所有标签、设计所有路由、配置所有值班表。
这样很容易拖慢试用，也容易因为变量太多而不知道问题出在哪里。
更务实的方式是：
先接入一个业务空间。
先触发一条测试告警。
先确认 Zabbix 显示 Sent。
先确认 Flashduty 收到事件。
先确认生成故障。
先确认能通知到人。
先让处理人认领一次。
这条链路跑通以后，再治理重复告警、补标签、做共享集成路由、配置值班表和升级策略。
Flashduty 的价值不是替代 Zabbix。
而是先帮你把 Zabbix 告警接住、降噪、分派、升级，并确保关键故障真的有人处理。
👉 现在注册试用
资料依据：
- Flashduty 文档：Zabbix 集成、入门指南、集成数据、路由规则、分派策略、告警降噪、分析看板。
- Zabbix 接入口径：通过 media type、user、trigger action 将 Problem、Recovery、Update 事件同步到 Flashduty。
- Flashduty Zabbix 版本说明：Zabbix 7.x 使用 v7 YAML media type；6.x 使用 YAML；5.x 使用 XML；3.x 到 4.x 使用
send-to-flashduty.sh脚本方式，并依赖curl和jq。 - Flashduty 严重程度映射：
Disaster、High映射 Critical；Average、Warning映射 Warning；Information、Not classified映射 Info。
