极豆科技夜莺监控实践：20 个 K8s 集群统一监控与告警治理
夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏，欢迎分享您的落地案例。
公司和业务介绍
极豆科技成立于2014年，站在车企立场，立足产业创新，为车企提供汽车座舱AI及数字化解决方案，提升汽车智能化水平和用户体验，挖掘用户全生命周期价值，赋能车企数字化转型。深耕产业10年，成为众多豪华、合资、自主、新势力等车企Tier1供应商，凭借在行业认知、车企客户资源、数据规模、应用场景等方面的优势，基于多家车企超1000万车辆和用户数据，使用行业领先模型，并对基础模型进行训练和微调，研发一系列座舱大模型应用产品和服务，针对不同场景和用户需求，生成文本、知识库、语音、图像、视频以及多模态的内容，提升座舱智能化体验。
背景与痛点：监控体系的“碎片化”危机
在业务快速扩张过程中，我们管理着20个Kubernetes生产集群，自营业务的Kubernetes集群5个，客户托管代维集群15个，每个集群均独立部署了监控体系：
- 每套集群部署 Prometheus + Grafana + Alertmanager，告警规则散落在各套集群中，管理不便，也不方便后续的统一分析、治理
- 部分客户也需要告警接受媒介，存在多个IM都需要一条告警，且告警需要存在一定的分级。
这种模式很快暴露出以下问题：
| 问题类型 | 具体表现 |
|---|---|
| 资源浪费 | 每套Prometheus需要一定资源 |
| 配置割裂 | 告警规则在每个Alertmanager中独立维护，版本差异率达35% |
| 管理黑洞 | 跨集群故障排查需切换每个Grafana实例，浪费定位问题时间 |
| 消息壁垒 | 告警无交互式操作，存在多人都去处理排查一个告警 |
| 配置紊乱 | 部分客户需要在其对应的IM中得到重要告警通知，导致配置十分紊乱 |
选型思考：为什么是夜莺（Nightingale）？
我们对比了三大技术路线：
| 方案 | 优势 | 劣势 | 评分 |
|---|---|---|---|
| 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 卡片，流程图如下：
最终的效果图如下：
未来计划和期望
- 夜莺支持 opensearch 日志数据源，目前在逐步使用夜莺聚合多个日志数据源的告警。
- 希望夜莺具备更多 AI 的能力，比如自然语言转 promql、自动定位根因等。
夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏。
