很多公司的告警不是没有系统。
恰恰相反，是系统太多了。
云上有阿里云、腾讯云、华为云、AWS、Azure；传统主机还在 Zabbix；Kubernetes 和微服务在 Prometheus；大盘用 Grafana；部分业务还有夜莺、Open-Falcon、Sentry、日志平台或自研监控。
每个系统都有自己的通知规则、Webhook、群机器人和负责人配置。
团队一大，这套模式很快会变成灾难：
同一个故障从多个系统重复告警
不同告警发到不同群里
有些告警只发给历史负责人
云资源告警没人认领
Zabbix 告警进了运维群，业务研发不知道
Prometheus 告警进了研发群，SRE 又看不到
复盘时才发现信息散落在三四个系统里
多监控系统并不可怕。
可怕的是没有一个统一的告警响应层。
统一告警，不等于替换监控系统
统一告警平台不应该一上来就替换 Zabbix、Prometheus 或云监控。
监控系统承担的是采集、存储、规则计算和异常检测，每个系统都有自己的优势。
Zabbix：传统主机、网络设备、老系统
Prometheus：云原生指标、Kubernetes、微服务
云监控：云资源、云数据库、负载均衡、对象存储
Grafana：统一大盘和告警规则编排
自研监控：业务特有指标和内部平台
真正需要统一的，是告警发生之后的响应流程：
告警进入哪里？
重复告警如何聚合？
告警分派给哪个团队？
谁是当前值班人？
没人响应时如何升级？
处理过程如何记录？
如何统计 MTTA、MTTR 和噪音来源？
Flashduty 承接的是这一层：它不替换监控系统，而是在监控系统之后建立统一告警响应中心。
各系统各自通知，跨系统故障一定会乱
各系统各自通知，早期很省事。
Prometheus Alertmanager 配一个 Webhook，Zabbix 配一个 Media Type，云监控配一个告警回调，Grafana 配一个 Contact Point，自研系统直接打企业微信机器人。
每个动作都不复杂。
问题是这些配置分散在不同地方。
一台云数据库异常，可能同时触发云监控的 RDS CPU 告警、Prometheus 的接口延迟告警、Zabbix 的主机连接告警、Grafana 的业务错误率告警、日志平台的错误关键字告警。
如果这些告警分别发到不同群里，团队会看到很多“现象”，但很难快速形成一个“故障”。
统一告警的第一步，不是把所有通知接到一个群，而是把所有告警接到一个可以理解告警语义的平台。
先决定专属集成还是共享集成
Flashduty 的告警接入有两种典型方式：专属集成和共享集成。
专属集成：适合一个监控源天然只属于一个业务空间。
共享集成：适合一个监控平台承载多个团队、多个业务、多个标签分流。
如果某个业务团队自己的 Prometheus 只负责订单服务，可以在订单协作空间里创建 Prometheus 专属集成。
如果公司只有一个统一 Zabbix，里面有支付、会员、搜索、网络、数据库等资源，就更适合共享集成：先在集成中心创建全局入口，再用路由规则分发到不同协作空间。
不要一上来就追求统一入口。
团队边界清晰时，可以先从专属集成开始。接入规模变大后，再把共用监控平台迁移到共享集成。
路由规则决定告警归谁处理
统一接入以后，最关键的问题是路由。
告警进了平台，不代表事情结束了。系统必须知道它应该进入哪个协作空间。
路由可以按这些条件做：
team=payment 进支付空间
service=order 进订单空间
env=prod 进生产空间
severity=critical 进入核心值班空间
source=cloud 进入平台或云资源团队
cluster=cn-shanghai-prod 进入华东生产空间
这看起来像配置问题，本质上是组织责任边界问题。
如果你不知道一条告警应该路由到哪里，通常说明服务归属也没有定义清楚。
比较稳的起步方式是：
核心业务空间：支付、订单、交易、会员
平台能力空间：Kubernetes、数据库、中间件、网络
云资源空间：云账号、云数据库、负载均衡、云缓存
兜底空间：接收暂时无法匹配的告警
共享集成一定要有兜底路由。
否则标签不完整或规则没命中的告警，可能直接无人承接。
标签规范比接入速度更重要
很多团队做统一告警时，只关注“能不能接进来”。
Prometheus 能推送，Zabbix 能推送，云监控能回调，Grafana 能发 Webhook。
这只是第一步。
真正决定后续治理质量的是标签。
最少要统一这些字段：
service：告警属于哪个服务
team：告警归哪个团队
env：生产、预发、测试还是开发
severity：严重程度
resource：主机、Pod、数据库实例等具体对象
check：CPU、延迟、错误率等检查项
cluster：集群或地域
owner：责任人或负责人
没有这些标签，统一接入只会变成统一堆积。
不同告警源字段不可能天然一致。Prometheus 通常比较结构化，Zabbix 信息可能在主机、触发器和消息模板里，云监控会带云产品自己的资源 ID，自研系统字段命名也未必统一。
更现实的做法是：源头能加标签就加，源头不方便改就用标签增强。
例如从标题中提取 IP，从资源 ID 映射资源类型，通过 CMDB 查询团队、服务等级和负责人。
Pipeline 负责把脏告警变干净
多源告警接入后，你会发现不是所有告警都值得进入响应流程。
有些标题很难懂，有些严重程度映射不符合业务实际，有些开发环境告警没必要进 On-call，有些无害错误应该直接丢弃，有些云资源 ID 需要改写成业务可读名称。
这时需要在入口做清洗。
Pipeline 可以在路由分发之前做转换和过滤：
把支付服务 Warning 升级成 Critical
把开发环境频繁重启告警直接丢弃
把机器语言标题改写成业务可读标题
在描述里追加日志平台、Grafana 或 Runbook 链接
在机房级故障存在时抑制同一集成内的次生告警
Pipeline 作用在集成层。也就是说，规则一旦生效，会影响通过该集成进入的告警，不需要在每个协作空间里重复配置。
不要把所有告警推到一个大群
很多团队做统一告警，最后还是建一个“监控告警总群”。
所有告警都进来，再靠人看、靠人转发、靠人 @。
这不是统一响应。
这是统一刷屏。
更合理的方式是：
告警源统一接入 Flashduty
入口层做标签增强和 Pipeline 清洗
共享集成按标签路由到不同协作空间
每个协作空间配置值班表、分派策略、通知渠道和升级规则
Critical 进入个人通知和电话升级
Warning 进团队群或只在工作时间通知
Info 更多用于记录和排查
统一告警平台应该做的是分流，而不是汇总噪音。
一个可落地的接入顺序
统一告警不要一口气全量迁移。
更稳的方式是分阶段推进：
1. 选一个高价值告警源，例如生产 Prometheus、核心 Zabbix 主机组或关键云账号
2. 只接生产关键告警，先验证 P1/P2 的触达、分派和升级
3. 设计最小标签规范，先统一 service、team、env、severity、resource、check
4. 配置路由和兜底空间，无法识别的告警先进入兜底空间
5. 配置分派策略，明确 Critical 通知谁、多久无人认领升级给谁
6. 观察两周数据，看告警量、压缩率、未认领故障、MTTA、MTTR 和兜底告警
不要只看“是否收到告警”。
统一接入是否成功，要看关键故障是否能进入正确空间、触达正确的人，并形成闭环。
常见告警源怎么接
不同系统接入方式不一样，但思路一致：把告警事件推送到 Flashduty 生成的集成地址。
Prometheus：通过 Alertmanager webhook_configs 接入，建议开启 send_resolved
Zabbix：通过 Media Type 和 Action 接入，覆盖 Problem、Recovery、Update
Grafana：通过 Webhook Contact Point 和 Notification policies 接入
云监控：通过各云厂商告警回调或 Webhook 接入
自研系统：通过标准 HTTP 接口发送 JSON 告警事件
统一的是响应模型，不是接入方式。
统一接入以后，用数据反推治理
接入不是终点。
接入以后，才真正看得见问题：
哪个告警源噪音最大？
哪个服务重复告警最多？
哪些告警经常无人认领？
哪些团队夜间通知最多？
哪些云资源长期处于 Warning？
哪些告警进入兜底空间但没人归类？
哪些故障 MTTA 很长？
这些问题在各系统各自通知时很难回答。
统一接入后，告警和故障进入同一套响应模型，就可以按团队、服务、来源、标签、人员和时间维度分析。
这才是统一告警的长期价值。
不是把消息集中起来，而是把治理对象集中起来。
结语
云监控、Zabbix、Prometheus、Grafana 和自研监控会长期共存。
这不是坏事。
坏的是每个系统各自通知、各自分派、各自闭环，最后没人能从组织层面管理故障响应。
更现实的路径是：不替换现有监控系统，先把告警统一接入 Flashduty。
用专属集成快速接入单团队告警，用共享集成承接多团队共用监控平台，用标签增强补齐服务、团队、环境和负责人，用 Pipeline 清洗脏告警，用路由规则送到对应协作空间，用分派策略和值班表确保关键故障有人处理，最后用数据看噪音、响应效率和治理效果。
如果团队现在有三套以上监控系统，最好的起点不是开一个“告警总群”，而是做一份告警源接入清单。
列出每个告警源：负责人是谁、覆盖哪些服务、当前发到哪里、是否有恢复事件、是否有 service/team/env/severity 标签、适合专属集成还是共享集成。
这份清单做完，第一批应该接什么就会清楚很多。
