夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏，欢迎分享您的落地案例。
极豆科技在 20 个 Kubernetes 生产集群中落地夜莺（Nightingale），把原本分散在多套 Prometheus、Grafana、Alertmanager 中的监控和告警能力收敛到统一平台。核心目标不是简单替换工具，而是解决多集群告警规则分散、跨集群排障低效、多 IM 通知配置混乱和告警重复处理的问题。
核心要点
- 业务规模：20 个 Kubernetes 生产集群，其中自营业务集群 5 个、客户托管代维集群 15 个。
- 原有问题：每个集群独立部署 Prometheus + Grafana + Alertmanager，规则、图表、通知和排障入口割裂。
- 选型结果：采用夜莺统一接入 Prometheus 和 VictoriaMetrics 等数据源，集中管理告警规则、通知渠道和业务组权限。
- 治理方式：基于
cluster标签做动态路由，结合内部告警分发平台进行聚合降噪和 IM 卡片通知。 - 实践效果：正文中记录的效果包括故障定位时间缩短至 15 分钟内、告警误报率下降 76%、关键告警到达率 100%。
公司和业务介绍
极豆科技成立于2014年，站在车企立场，立足产业创新，为车企提供汽车座舱AI及数字化解决方案，提升汽车智能化水平和用户体验，挖掘用户全生命周期价值，赋能车企数字化转型。深耕产业10年，成为众多豪华、合资、自主、新势力等车企Tier1供应商，凭借在行业认知、车企客户资源、数据规模、应用场景等方面的优势，基于多家车企超1000万车辆和用户数据，使用行业领先模型，并对基础模型进行训练和微调，研发一系列座舱大模型应用产品和服务，针对不同场景和用户需求，生成文本、知识库、语音、图像、视频以及多模态的内容，提升座舱智能化体验。
背景与痛点：监控体系的“碎片化”危机
在业务快速扩张过程中，我们管理着 20 个 Kubernetes 生产集群，其中自营业务 Kubernetes 集群 5 个，客户托管代维集群 15 个。早期每个集群均独立部署监控体系：
- 每套集群部署 Prometheus + Grafana + Alertmanager，告警规则散落在各套集群中，管理不便，也不方便后续的统一分析、治理
- 部分客户也需要自己的告警接收媒介，存在一条告警需要同时进入多个 IM 的情况，且不同告警需要分级处理。
这种模式很快暴露出以下问题：
| 问题类型 | 具体表现 |
|---|---|
| 资源浪费 | 每套Prometheus需要一定资源 |
| 配置割裂 | 告警规则在每个Alertmanager中独立维护，版本差异率达35% |
| 管理黑洞 | 跨集群故障排查需切换每个Grafana实例，浪费定位问题时间 |
| 消息壁垒 | 告警无交互式操作，存在多人都去处理排查一个告警 |
| 配置紊乱 | 部分客户需要在其对应的IM中得到重要告警通知，导致配置十分紊乱 |
选型思考：为什么是夜莺（Nightingale）？
我们对比了三大技术路线。选型重点不是单点功能，而是是否能支撑多 Kubernetes 集群、多数据源、多团队权限和多通知渠道的统一治理。
| 方案 | 优势 | 劣势 | 评分 |
|---|---|---|---|
| Thanos | 原生云原生，适合超大规模 | 部署复杂度高，学习曲线陡峭；国内使用较少 | ★★☆ |
| Zabbix + Grafana | 成熟稳定，社区支持广 | K8s监控能力弱，主要侧重设备监控 | ★★ |
| 夜莺 | 多数据源、多集群支持，告警通知灵活 | 最初由滴滴开源，非国际大厂出品 | ★★★★★ |
关键决策因素：
-
成本效率
- 夜莺单集群可对接多数据源，替代原来每套 K8s 独立的监控体系，统一管理
- 资源消耗降低，监控系统本身的运维成本降低
- 与 Prometheus 相同的数据传输协议，既可以接收 Remote Write 数据上报，也可以主动抓取业务暴露的
/metrics数据 - 内置 业务组权限隔离，满足独立运维需求，各个团队可以分别管理自己规则、仪表盘，省的啥事都来找我们团队
-
告警治理能力
- 动态路由：基于
cluster标签自动分发告警，每个 K8s 集群的数据都统一带上cluster标签 - 智能抑制：避免 K8s 节点宕机时产生数百条重复告警，这里用 AI 写了一个简单的告警聚合降噪模块，除了夜莺的告警之外，也一并处理公司内部其他监控系统、安全系统产生的告警事件，统一降噪分发
- 交互式操作：支持在国内主流 IM 中屏蔽告警，夜莺所有的操作都提供 API，使用 API 即可完成屏蔽，可以短期屏蔽一段时间，也可以周期性屏蔽
- 动态路由：基于
最终架构：统一监控平台的落地实践
落地时，我们先把所有数据源接入夜莺。部分 Prometheus 直接作为数据源接入；对于有聚合分析需求的场景，则在 Prometheus 配置 Remote Write 写入 VictoriaMetrics，再把 VictoriaMetrics 作为数据源接入夜莺。
夜莺的核心职能：
| 模块 | 职能 | 业务价值 |
|---|---|---|
| 数据接入层 | 聚合多集群指标，相当于一个 Pushgateway 网关 | 消除跨集群查询门槛，故障定位时间缩短至15分钟内 |
| 告警引擎 | 基于标签的动态路由（如cluster=shanghai → 上海值班组） |
告警误报率下降76%，关键告警到达率100% |
| 可视化告警配置 | 可以在图形化页面配置告警，支持导入导出功能，可列出活跃告警 | 降低使用告警规则使用门槛，各团队自助操作 |
| 多消息通知渠道 | 可以通知企业微信，钉钉，飞书等国内主流IM渠道 | 客户用哪个 IM 都可以收到告警，避免配置文件中进行配置 |
夜莺除了支持 Prometheus、VictoriaMetrics 的告警，也支持 ElasticSearch、Loki 等日志源的告警。上了夜莺之后，我们就下掉了 ESAlert（原本用于 ElasticSearch 的告警），使用一个平台统一管理。
但是夜莺不支持 SkyWalking 的告警，我们就做了一个统一的告警分发中心，同时接收夜莺、SkyWalking、Falco 的告警，做告警聚合降噪。在这个项目中我参考了 Flashduty 和博哥爱运维的大监控告警中心项目，在此致谢。
统一告警分发平台的架构图如下：
告警事件由夜莺产生，做一些 Pipeline 二次处理，然后回调我们的统一告警分发平台（内部叫“谛听”），谛听生成 IM 卡片，流程图如下：
最终的效果图如下：
落地经验
这次实践的关键，不只是把多个数据源接到夜莺，而是先统一标签和告警入口。cluster 标签承担了多集群路由的核心作用；夜莺的业务组权限隔离，让不同团队可以自助维护自己的规则和仪表盘；内部告警分发平台则补齐了跨夜莺、SkyWalking、Falco 的统一降噪和 IM 卡片交互。
对多 Kubernetes 集群团队来说，建议优先处理三件事：
- 统一标签模型：至少保证
cluster、业务、环境、负责人等标签稳定。 - 统一告警入口：先让告警进入同一个平台，再做路由、抑制和升级。
- 统一通知体验：把客户和团队使用的 IM 渠道抽象成通知策略，而不是散落在各个配置文件中。
未来计划和期望
- 夜莺支持 opensearch 日志数据源，目前在逐步使用夜莺聚合多个日志数据源的告警。
- 希望夜莺具备更多 AI 的能力，比如自然语言转 promql、自动定位根因等。
FAQ
Q1：极豆科技为什么没有继续维护每个集群独立的 Prometheus + Grafana + Alertmanager？ A：独立维护会导致规则版本、排障入口、通知配置和权限管理分散。集群数量达到 20 个后，统一治理的收益明显高于继续复制单集群监控栈。
Q2：夜莺在这个方案中替代了哪些能力？ A：夜莺承担多数据源接入、告警规则管理、可视化配置、多消息通知和业务组权限隔离等能力。原本用于 ElasticSearch 告警的 ESAlert 也被统一平台替代。
Q3：为什么还要建设内部告警分发平台？ A：夜莺统一了大部分监控告警，但 SkyWalking、Falco 等来源还需要统一接入、聚合降噪和 IM 卡片交互。因此内部平台用于承接多来源告警的二次处理和分发。
总结
极豆科技的实践说明，多 Kubernetes 集群监控的难点不只是采集数据，而是规则、标签、通知和处理流程的统一。夜莺提供了统一监控和告警治理底座，内部告警分发平台进一步补齐跨系统聚合降噪能力，两者结合后，才能把分散的集群监控变成可协同的统一运维平台。
夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏。
