Keep vs PagerDuty AIOps：告警降噪、事件编排和费用

数据库出问题，十几个调用方一起报警，值班群里很快刷满消息。通知确实太多，但直接少发一点也不放心：如果同一时间还有一场无关故障，它会不会一起被折叠掉？

Keep 和 PagerDuty AIOps 都能处理这类事件。选择时，我会先看团队现在怎样值班。服务归属、排班和升级已经在 PagerDuty 里，增加 AIOps 比另起一套事件层少搬很多东西。监控来源杂、通知渠道也已成型，希望自己控制关联和处理流程，Keep 更适合进入候选。

两者最后都要为持续运行付出成本，只是付法不同。商业费用能买到哪些工作，开源部署以后还剩哪些工作，需要接着往下看。

观测云｜2026-10-09 更新。依据官方资料比较，未做真实告警回放或降噪率测试。

已有值班体系的影响

PagerDuty 当前在不同方案下使用 AIOps 或 Signal Intelligence 名称。Incident Management 已有的排班、服务和响应配置是现成资产，加入 AIOps 时可以继续沿用。Keep 的 MIT 许可不覆盖 ee/ 的全部代码，所需企业能力另按方案核对。PagerDuty AIOps、Keep 许可。

因此，已有平台投入会明显影响结果。自建的报价低，并不足以说明值得迁走一套已经稳定运行的值班体系；反过来，团队没有采用 PagerDuty，也无需为了一个去重需求把整套响应流程一起重建。

告警身份怎么定义

同一规则每分钟重复发送一次，通常只需要更新已有告警。两个服务分别报错，则可能属于同一故障，但仍是两条不同告警。前者是去重，后者还需要关联判断。

延伸阅读HolmesGPT vs K8sGPT：集群巡检和故障排查，分别适合谁→

Keep 的指纹去重允许保留告警身份、更新状态和严重程度。更严格的完整重复判断，可以过滤没有实质变化的输入；关联规则再根据属性与条件组织事件。这几步承担不同工作。Keep 去重、关联规则。

指纹设计不合适，后面的处理就会很费劲。只用服务名，生产和测试可能混在一起；把每次发送时间也放进去，每一条又都变成新告警。资源重建后，触发与恢复使用不同身份，还可能留下关不掉的旧事件。

这类问题适合先用明确规则处理。环境、集群、服务和资源身份整理好了，再引入更复杂的关联，才有稳定输入。否则 AI 花不少力气解释的，可能只是字段不一致。

关联错了会发生什么

把五百条通知压成十条，数字很漂亮。可如果数据库故障和另一个服务的证书过期被合成一件事，处理完数据库，证书问题仍然在那里。

PagerDuty 提供多种分组方式，Keep 也支持按属性和逻辑关联。时间接近可以作为线索，却不足以证明同源。服务依赖能提供更多帮助，前提是服务标识一致、拓扑仍然有效。PagerDuty 智能分组、Keep 关联规则。

所以，判断降噪效果至少要知道原本有几场独立故障。如果参考结果是一场数据库故障加一场证书故障，平台最后留下两件，才有继续比较通知数量的基础。误合并和重复通知的代价不同：前者可能延迟处理，后者主要增加干扰。

这也影响规则的取舍。特别关键的业务可以保守一点，多保留独立事件；重复量很大且原因明确的告警，可以更积极地合并。没有一组参数能同时替所有业务决定这个交换。

通知减少以后，账单怎么变

五百条输入，合成十个事件，最后发送十条通知。这三个数字分别对应入口处理、事件组织和人员触达。

PagerDuty AIOps 按其接受并处理的适用事件计量，发往启用 AIOps 的服务或事件编排的输入计入对应范围，维护窗口中接受的事件也可能计入。后端合并以后只剩十件事，不会自动把输入用量改成十条。PagerDuty 事件计量。

因此，降噪节省的首先是人的注意力，账单还要看入口量和所购方案。重复更新、恢复事件和其他输入都有可能影响费用，单看值班群里的消息数，估不准。

Keep 自建则把这笔费用转成运行资源和维护。重复输入仍需经过连接器、处理程序与存储；工作流失败、字段变化、规则升级都需要人处理。用到模型时再增加模型消耗。团队已有这些运行能力，自建增量可以较低；没有负责人，服务器便宜也不等于整个系统便宜。

工作流接到哪里

事件归类完成以后，还要有人接。

延伸阅读SigNoz vs SkyWalking：接入方式、采样和 APM 成本怎么选→

Keep 可以通过告警、定时或手动触发工作流，再配置步骤、条件和动作，适合衔接现有通知、工单及调查系统。凭证、字段映射和目标系统变化，需要持续维护。Keep 工作流。

PagerDuty 的事件编排可以利用既有服务与路由体系。对已经深度使用它的团队，这种衔接能减少一部分自行开发；准备迁走时，这些运行多年的配置也会成为迁移工作。PagerDuty Event Orchestration。

自动动作还容易遇到重复触发。一个事件更新五次，不能因此创建五张工单。动作需要有执行记录和幂等约束，恢复条件也要单独处理。流程显示运行成功，只说明动作调用完成，业务是否恢复还得回到监控数据确认。

什么情况选 Keep

监控来自多个平台，已经有通知和工单渠道，希望把关联规则与自动流程掌握在自己手里，并且有人维护，这种条件下 Keep 很合适。它带来的自由度有实际用途，新增的运行责任也有人承担。

已经使用 PagerDuty 管理服务、排班和升级，主要希望减少现有事件噪声，AIOps 更自然。此时另建 Keep 的收益，要扣掉连接、同步和双平台管理的工作。

如果问题只是某条规则重复通知太频繁，先调整现有规则和通知策略往往就够了。事件关联平台能够解决更复杂的问题，也会增加需要维护的新状态和配置。

观测云告警能覆盖多少

业务已经使用观测云监控时，通知对象、严重程度、升级、重复抑制和聚合都有现成配置。抑制通知后仍可保留事件记录，日常降噪不必以丢弃故障证据为代价。观测云告警策略。

这类需求先用原平台完成，就少了一套事件同步、字段映射和权限配置。跨多个外部平台、复杂跨组织值班的需求，仍然可能需要独立事件系统。进一步希望从事件启动持续调查，可以配置 Obsy Agent Teams 的工具和任务，连接与 AI 使用费用另算。观测云 Obsy AI。

最终要省的是处理故障所需的总投入。少几条消息有价值，少维护一层并不需要的系统，同样有价值。