30 秒结论
- 继续用 Prometheus + Alertmanager，如果
团队习惯 GitOps、规则数量能记在脑子里、告警通过 webhook 送进 PagerDuty 这类值班系统就够了。这套组合成熟、省组件，没有理由为换而换。
- 换夜莺，如果
规则要交给非 SRE 的业务团队在页面上维护，权限要按业务组划分，值班的人需要电话短信，或者数据已经不只在 Prometheus 里：日志在 ES、业务指标在 MySQL。
- 两套并行，如果
想先验证再决定。夜莺把 Prometheus 注册成数据源就能判定同一批规则，Alertmanager 继续发通知，按通知渠道逐个切换，任何一步都能在一分钟内回退。
规则写在 YAML 里，靠 GitOps 管。
规则配在页面上，按业务组分权限。
它擅长什么
Prometheus 依然是最好的时序底座之一，Alertmanager 的分组与静默模型设计得很干净。规模不大、团队习惯 GitOps、告警规则数量可控时，这套组合完全够用，而且不用多引入组件。
什么时候换夜莺
当告警规则要交给非 SRE 的业务团队维护、需要按业务组分权限、需要电话短信这类媒介，或者数据不只在 Prometheus 里的时候，夜莺更省事——它就是把这几件事做厚的。
换的信号
- 告警规则要交给非 SRE 的业务团队维护
- 凌晨三点得有人接电话，webhook 叫不醒人
- 数据已经不全在 Prometheus 里了
rules.yml + alertmanager.yml
- alert: MysqlReplicaLag expr: mysql_slave_lag_seconds > 30 for: 5m labels: { team: dba }route: receiver: dba-webhook group_by: [alertname]
夜莺 · 告警规则
- 名称
- MySQL 副本延迟
- 条件
- mysql_slave_lag_seconds > 30，持续 5m
- 业务组
- DBA
- 通知
- 电话、短信、钉钉
- 谁能改
- DBA 组
- 你
- 一句话创建：mysql-prod 副本延迟超过 30 秒持续 5 分钟，电话通知 DBA 组
- 夜莺 AI
- PromQL 和阈值已生成。业务组我不猜，请从下拉里选一个，选好就创建。
逐项对照
| 能力对比 | 夜莺 v9 | Prometheus + Alertmanager |
|---|---|---|
| 数据源 | 内置: 指标、日志、SQL，10+ 类型 | 不支持: 只判定 Prometheus 自身的数据 |
| 规则在哪配 | 内置: 页面配置，按业务组归属，可整份导入 rules.yml | 不支持: YAML 文件 + reload，没有页面编辑 |
| 规则语法 | 内置: PromQL 不变，阈值写在表达式里 | 内置: PromQL |
| 通知聚合 | 不支持: 一次通知一个事件，不按标签合并成一条消息 | 内置: group_by / group_wait / group_interval |
| 跨规则抑制 | 部分支持或需扩展: 同一规则多档阈值内置抑制；跨规则要用事件 Pipeline 改写 | 内置: inhibit_rules |
| 静默 / 屏蔽 | 内置: 固定时间与周期时间，可只屏蔽通知保留事件，带业务组边界 | 部分支持或需扩展: 一次性 Silence；周期静默靠路由上的 mute_time_intervals |
| 通知媒介 | 内置: 20 种内置，含电话、短信、钉钉、飞书、企业微信 | 部分支持或需扩展: 邮件、Slack、PagerDuty、Telegram、企业微信、webhook 等；电话、短信、钉钉、飞书要靠第三方 |
| 订阅与协同 | 内置: 订阅规则、超时抄送、事件 Pipeline 处理器 | 不支持: 无 |
| 权限 | 内置: 用户、团队、业务组 RBAC | 不支持: 没有认证和权限模型 |
| 仪表盘 | 部分支持或需扩展: 内置仪表盘，可按 URL 嵌入 Grafana 面板 | 不支持: 只有表达式浏览器，通常配 Grafana |
| 告警自愈 | 内置: ibex 脚本执行 | 不支持: 无 |
| AI / MCP | 内置: 内置助手与 74 个 MCP 工具 | 不支持: 无 |
| 许可证 | 内置: Apache-2.0 | 内置: Apache-2.0，CNCF 毕业项目 |
- 内置
- 部分支持或需扩展
- 不支持
基于各项目 2026 年 8 月开源版本的公开能力，只作选型参考。我们尽量把对方的长处写清楚——选型建议不老实，社区口碑也就没了。
对象怎么对应
一份 rules.yml 加一份 alertmanager.yml，拆开后每一项落到哪里。完整的逐条对应、拍平路由树的方法和四个不对称之处，见迁移文档。
| Prometheus / Alertmanager | 夜莺 |
|---|---|
| rules.yml 里的告警规则 | 告警规则，整份粘进「导入 Prometheus 告警规则」 |
| 记录规则 | 不动，继续由 Prometheus 计算 |
| receivers[] | 通知媒介 + 通知规则里的通知配置 |
| route 路由树 | 拍平：每条从根到叶的路径 AND 成一份通知配置 |
| group_by / group_wait / group_interval | 没有对应物，一次通知只装一个事件 |
| inhibit_rules | 没有声明式对应物，用事件 Pipeline 的丢弃处理器改写 |
| Silence | 屏蔽规则，必须属于一个业务组 |
| Alertmanager 集群 | 多个告警引擎实例按规则分片，不需要 gossip |
两个最容易踩的坑：夜莺通知配置的「适用级别」一个都不勾等于谁都不匹配；事件缺少某个标签时，!= 和 !~ 也判为不匹配，而 Alertmanager 把缺失标签当空串。
关于这组对比的常见问题
要替换 Prometheus 吗？
不用。夜莺不存时序数据，Prometheus 继续抓取和存储，夜莺把它注册成数据源，按周期发 instant query 做判定。Thanos、Mimir、VictoriaMetrics 同样直接接。
alertmanager.yml 能自动转换吗？
告警规则能：rules.yml 整份粘进「规则管理 → 导入 → 导入 Prometheus 告警规则」。路由、接收器和静默要按迁移文档逐条重建，因为夜莺是平铺的通知规则，不是路由树。
夜莺能接收 Alertmanager 发出的 webhook 吗？
不能。夜莺没有入站告警接口，只有指标写入口，所以不能把 Alertmanager 挂在前面当转发器过渡，规则只能在夜莺里重建。
Alertmanager 的告警分组在夜莺里怎么办？
夜莺一次通知只装一个事件，不按标签把多条告警合并成一条消息。降噪靠规则层面的合并（一条规则覆盖查询返回的所有序列）、屏蔽规则和订阅规则。如果值班流程强依赖分组消息，这是切换前要先认下的差异。
切换要停 Alertmanager 吗？
最后一步才停。前面所有步骤里 Prometheus 和 Alertmanager 都正常运行：夜莺的规则先禁用导入，挑一个业务组做金丝雀，并行比对，最后从 rule_files 里摘掉告警规则，再停 Alertmanager。