Zabbix 不应该被简单替换。
很多团队用 Zabbix 已经很多年，主机、网络设备、数据库、中间件和机房资源都在里面。监控项、模板、触发器、主机组、权限和运维习惯都沉淀在 Zabbix 里。让一个成熟团队为了改善告警响应而重建监控体系，通常成本很高，也没有必要。
真正需要处理的问题往往不是“Zabbix 不好用”，而是告警从 Zabbix 发出来以后，缺少统一的响应机制。
告警进了邮件、短信、脚本、IM 群或 Webhook，但没人知道谁应该接手；群里有人回复“我看下”，但系统里没有认领状态；同一个根因触发几十条告警，值班人被重复打扰；Critical 告警没人响应时，还要靠人工催；月底复盘时，只能凭感觉判断哪个系统告警最多、哪个团队响应慢。
这类问题不靠替换 Zabbix 解决，而是把 Zabbix 产生的告警接入 Flashduty，让后续的降噪、分派、升级、协同和分析进入同一条响应链路。
先明确边界：Zabbix 负责监控，Flashduty 负责响应
Zabbix 的强项是监控。
它可以采集指标、配置触发器、发现问题、在 Problem 视图中展示异常，并通过 media type 和 action 发送通知。Zabbix 官方手册中，通知配置的核心路径也是 media type、user 和 action：media type 定义通知通道，action 定义事件满足什么条件时执行什么操作，operation 负责发送消息或执行远程命令。
这套机制适合把告警发出去。
但 On-call 响应还需要回答另一组问题：
- 这个告警应该进入哪个团队的处理空间？
- 当前值班人是谁？
- 主值班未认领时，多久升级给备值班？
- 告警恢复、更新和处理动作是否进入同一条时间线？
- 重复告警是否应该合并为同一条故障？
- 哪些 Zabbix 触发器贡献了最多噪音？
- 本月 MTTA、MTTR、响应比例和中断次数是否改善？
这些不是单纯的通知发送问题，而是故障响应管理问题。
更合理的架构是：Zabbix 继续负责监控和触发告警，Flashduty 作为统一告警响应平台，承接 Zabbix 发出的事件，并把事件转换为可分派、可认领、可升级、可分析的故障。
为什么 Zabbix 告警会变成“没人看”
告警没人看，通常不是因为团队完全没有通知，而是通知机制缺少状态和责任。
第一类问题是通知分散。
基础设施告警发到运维群，数据库告警发给 DBA，业务告警发给研发，少数历史系统还在发邮件。告警越多，入口越多，越难确认哪个告警已经有人接手。
第二类问题是重复打扰。
一台核心交换机异常，可能带出多台主机不可达；一个数据库连接池耗尽，可能触发多个应用错误率和超时告警；一次网络抖动，可能在短时间内反复触发和恢复。值班人收到的是几十条通知，但真正要处理的可能只有一个故障。
第三类问题是责任不清。
Zabbix action 可以把通知发给某个用户或用户组，也可以通过升级步骤重复通知或升级到更高层级用户组。但在多团队、主备值班、临时调班、业务 owner 频繁变化的环境里，把“谁今天负责”长期维护在通知规则里，容易变成隐性知识。
第四类问题是缺少可回溯数据。
告警什么时候触发、通知了谁、谁认领、何时关闭、有没有升级、重复通知打断了多少次值班人，这些信息如果散在 Zabbix、邮件、群聊和人工记录里，就很难用来改进告警规则和值班机制。
Flashduty 要补齐的正是这些环节。
如何把 Zabbix 告警接入 Flashduty
Zabbix 接入 Flashduty 的核心方式是 Webhook。
在 Flashduty 侧，先创建 Zabbix 告警集成并获取推送地址。这里有两种选择：
- 专属集成：在某个协作空间里创建 Zabbix 集成，告警直接进入该空间。适合单一团队或首次试用。
- 共享集成：在集成中心创建全局 Zabbix 集成，再通过路由规则把告警分发到不同协作空间。适合多业务团队共用一套 Zabbix 的场景。
如果刚开始验证，建议先用专属集成。路径短、变量少，能快速确认 Zabbix 到 Flashduty 的链路是否打通。
如果公司级 Zabbix 同时承载多条业务线，建议使用共享集成。共享集成可以按标签、属性、严重程度等条件路由，也可以用名称映射模式把某个标签值映射为协作空间名称。例如 team=payment 的告警进入支付空间，team=db 的告警进入数据库空间。
在 Zabbix 侧，配置路径按版本略有差异，但主线一致：
- 创建或导入 Flashduty 对应的 media type。
- 将 media type 关联到一个 user，且该 user 至少需要对相关 host 有 read 权限。
- 创建 trigger action，把通知发送给这个 user，并指定 Flashduty media type。
- 同时配置 Problem、Recovery 和 Update 三类操作，保证触发、恢复和更新事件都能同步。
- 到
Monitoring > Problems查看告警，检查 Actions 中对应发送日志；Flashduty 集成卡片出现最新事件时间后，说明链路已收到事件。
Flashduty 的 Zabbix 接入说明对不同版本提供了不同配置方式。Zabbix 7.x 使用导入 media type 配置的方式；5.x 到 6.x 分别提供 XML/YAML 配置；3.x 到 4.x 使用脚本方式发送，脚本依赖 curl 和 jq。这类版本差异在迁移老 Zabbix 环境时很重要，不要用新版本截图去套旧版本控制台。
接入后，Zabbix 严重程度会映射到 Flashduty 的标准级别：Disaster 和 High 对应 Critical，Average 和 Warning 对应 Warning，Information 和 Not classified 对应 Info。
这一步的目标不是改变 Zabbix 的监控逻辑，而是把 Zabbix 事件稳定送进响应平台。
接入以后，第一件事不是通知更多人，而是降噪
很多团队接入新通知渠道后，会本能地把告警推给更多人。
这通常会让问题更严重。
如果原始告警本来就很多，只是把邮件换成电话、短信或 IM 群，值班人的负担会更重。正确顺序应该是：先把告警接进来，再把重复告警、抖动告警、维护期告警和派生告警处理掉，最后再设计通知策略。
Flashduty 的降噪模型把监控系统推送过来的原始通知称为事件，事件触发告警，相似告警再聚合成故障。值班人主要处理的是故障，而不是逐条处理所有 Zabbix 事件。
这对 Zabbix 用户很关键。
例如，一批主机因为同一个网络问题同时不可达。没有降噪时，值班人可能收到几十条 Zabbix 通知；开启聚合后，多条相似告警可以合入同一条故障，后续告警进入故障但不再重复触发通知。
Flashduty 支持两类聚合方式：
- 智能聚合：基于标题、描述、
labels.service、labels.resource等字段计算相似度，适合快速上手。 - 规则聚合：按指定属性或标签精确匹配，适合对聚合边界要求明确的团队。
除此之外，还可以配置风暴预警、抖动检测、静默策略和抑制策略。
风暴预警用于在合入告警数达到阈值时记录告警风暴事件并触发预警。抖动检测用于识别同一故障频繁触发和恢复，减少反复通知。静默策略适合维护窗口或已知问题，可以按严重程度、标题、描述、集成来源和标签匹配。抑制策略适合根因告警已存在时屏蔽次要告警，例如 Critical 告警存在时抑制同一检查项的 Warning/Info 告警。
对于 Zabbix 场景，建议先做三条基础规则：
- 按主机、检查项或业务标签聚合重复告警。
- 对维护窗口、批量变更、已知低优告警配置静默。
- 对根因明确的高等级告警配置抑制，减少派生 Warning/Info 干扰。
不要一开始就追求复杂规则。先拿最吵的 20 个触发器做治理，效果最明显。
多团队共用 Zabbix 时，用路由规则分流
传统 Zabbix 环境里，一个常见问题是“监控集中，响应分散”。
Zabbix 可能由运维团队统一维护，但告警处理人分布在多个业务团队：支付、交易、账号、订单、数据平台、DBA、网络、安全。所有告警都进一个群，会让每个团队都被无关信息打扰；所有告警都靠运维转派，又会让运维成为人工分发中心。
共享集成和路由规则适合解决这个问题。
共享集成接收统一入口的 Zabbix 事件，然后按规则投递到不同协作空间。路由规则支持按标签、属性等条件匹配，支持精确、通配符和正则匹配，也支持默认路由兜底。流程控制可以选择命中后继续匹配，或命中后停止匹配。
典型设计可以是：
severity=Critical的基础设施告警进入 SRE 空间。team=payment的业务告警进入支付空间。host_group=DB或service=mysql的告警进入 DBA 空间。- 无法识别团队的告警进入默认告警空间，由平台团队二次治理。
如果 Zabbix 原始事件中的标签不够规范，可以用标签增强补齐。Flashduty 支持通过正则提取、组合、映射和删除等方式生成标签，标签后续可以用于路由、筛选、分派、聚合、静默和抑制。
这一步的重点是让告警自动找到负责团队，而不是让一个人每天在群里手动转发。
分派策略要按故障价值设计
所有告警都电话通知，是最容易制造值班疲劳的配置。
分派策略应该按故障价值分层：
- Critical：必须立即处理，使用电话、短信、App、IM 私聊等强触达方式。
- Warning：需要关注，但不一定要打断睡眠，可以优先进入 IM 群或 App。
- Info：只做状态提醒，通常不进入强通知链路。
Flashduty 的分派策略包含触发条件、通知对象、通知方式、延迟窗口、通知模板和升级规则。触发条件可以按标题、级别、标签等筛选；通知对象可以是值班表、团队、个人，也可以组合使用；通知方式支持电话、短信、邮件、App 推送、IM 私聊和群聊。
对 Zabbix 告警来说，一个实用的起步策略是：
- Critical 告警通知当前主值班人，使用电话或短信兜底。
- 10 分钟未认领，升级给备值班人。
- 30 分钟未关闭，升级给对应业务负责人或 SRE 负责人。
- Warning 告警进入团队 IM 群，只在工作时间内通知个人。
- Info 告警先进入故障列表和分析，不触发强通知。
延迟窗口也值得谨慎使用。对于容易自愈的短暂抖动，可以在首次通知前等待一段时间；如果故障在等待期内自动关闭，就不再发送通知。这比把所有瞬时异常都打给值班人更可持续。
值班表不要再靠群公告或 Excel
Zabbix action 可以把通知发送给固定用户或用户组，但真实值班通常不是固定名单。
团队会有主备值班、白班夜班、周末值班、节假日安排、临时调班和请假。值班表如果靠群公告、Excel 或人工记忆维护，很容易出现两个问题：该通知的人没收到，不该被打扰的人一直被打扰。
Flashduty 的值班表用于把故障和当前值班人连接起来。值班规则支持按小时、天、周、月轮换，也支持白班/夜班、主备值班、日期掩码、临时调班和公平轮换。分派策略可以直接通知值班表里的当前值班人，也可以按角色只通知主值班或备值班。
这让 Zabbix 告警不需要知道“今天谁值班”。
Zabbix 只负责把事件发出来；Flashduty 根据当前值班表和分派策略决定通知谁、通过什么渠道通知、无人响应时如何升级。
从“告警已发送”变成“故障已认领”
通知发出不等于故障有人处理。
这是很多 Zabbix 告警体系里最容易被忽略的差异。
在 Flashduty 中，Zabbix 事件触发告警，告警触发故障。故障有处理进度：待处理、处理中、已关闭。人员收到通知后可以认领故障；认领后，故障进入处理中。如果告警自动恢复，故障可以自动关闭；处理人也可以手动关闭、暂缓、合并或重新分派。
故障详情页会记录时间线，包括触发、分派、通知、认领、关闭等动作。这样复盘时不需要翻聊天记录去猜：告警几点发出、谁收到了、谁认领了、是否升级过、关闭发生在什么时候。
对运维负责人来说，这比“Zabbix action 显示 Sent”更进一步。
Sent 只能说明消息发出去了。
已认领 才说明有人承担了响应责任。
用分析看板反推 Zabbix 告警治理
接入 Flashduty 后，不应该只看“有没有收到通知”。
更重要的是用数据反推治理方向。
Flashduty 的分析看板支持按团队、协作空间、个人等维度查看故障数据，指标包括故障数量、MTTA、MTTR、响应比例、响应投入和中断次数。时间维度可以拆分为工作时间、休息时间和睡眠时间。全局维度还可以查看告警检查项和告警对象 TOP 20，并支持下载 PDF 和导出 CSV。
这对 Zabbix 告警治理很直接。
如果某个触发器长期排在 TOP 20，应该回到 Zabbix 检查触发器表达式、阈值、依赖关系和维护窗口。
如果某个主机或主机组长期产生大量 Warning，应该检查资源容量、模板适配或告警阈值。
如果 Critical 告警 MTTA 很长，应该检查值班表、通知渠道和升级策略。
如果睡眠时间中断次数过高，应该检查夜间通知分层和抖动检测。
没有这些数据时，告警治理容易变成争论。
有了这些数据，团队可以按事实优化 Zabbix 规则和 On-call 机制。
10 分钟接入时，建议验证这 8 件事
如果你正在评估是否把 Zabbix 告警接入 Flashduty，不建议先做全量迁移。选一个真实业务空间，用少量高价值告警跑通闭环更有效。
可以按这个清单验证：
- 在 Flashduty 创建 Zabbix 专属集成或共享集成，拿到推送地址。
- 在 Zabbix 导入或创建 Flashduty media type，并补全 URL、Zabbix 控制台地址和代理配置。
- 将 media type 关联到具备 host read 权限的 user。
- 创建 trigger action，并配置 Problem、Recovery、Update 三类操作。
- 触发一条测试告警，确认 Zabbix Actions 显示发送成功，Flashduty 集成卡片出现最新事件时间。
- 检查 Zabbix 严重程度是否正确映射为 Critical、Warning、Info。
- 配置一条分派策略，让 Critical 告警通知当前值班人，并设置未认领升级。
- 开启一条聚合或静默规则，观察重复告警是否减少通知干扰。
这 8 件事跑通以后，再逐步扩大范围：从一个业务空间扩展到多个空间，从少量 Critical 告警扩展到 Warning，从专属集成演进到共享集成和路由规则。
结论：不要替换 Zabbix，先统一告警响应
Zabbix 仍然可以继续做它擅长的事：采集、监控、触发和展示问题。
Flashduty 补的是 Zabbix 告警发出之后的响应链路：统一接入、路由分流、标签增强、告警降噪、值班分派、自动升级、故障认领、时间线和数据分析。
对已经使用 Zabbix 的团队来说，最稳妥的方式不是推倒重来，而是先选一组真实告警接入 Flashduty。用 10 分钟跑通链路，用 14 天观察告警压缩、认领速度、升级有效性和中断次数，再决定是否扩大到更多业务团队。
如果你的 Zabbix 告警已经进群但没人认领，或者夜间告警太多导致值班疲劳，可以从一个协作空间开始试：接入 Zabbix、配置值班表、打开降噪、设置未认领升级，让第一条告警真正进入闭环。
参考资料
- Zabbix 官方文档：Notifications upon events / Media types / Actions / Webhook
https://www.zabbix.com/documentation/current/en/manual/quickstart/notification
https://www.zabbix.com/documentation/current/zh/manual/config/notifications/media/webhook
https://www.zabbix.com/documentation/current/en/manual/config/notifications/action - Flashduty 产品资料：Zabbix 集成、集成数据、路由规则、标签增强、告警降噪、分派策略、值班管理、故障生命周期、分析看板。
