案例摘要
八维通科技的统一监控建设核心，不是简单替换一个监控工具，而是把分散在 Prometheus、Zabbix、CAT、云日志和多地机房中的监控、告警、日志查询和权限管理收敛到 Nightingale 商业版体系中。
- 场景规模：20 多个机房、20+ 套集群、上千台服务器。
- 原有问题：监控平台分散、告警规则分散、跨城市筛选困难、研发查询日志需要多个平台和云账号。
- 技术路径：从 Prometheus 联邦模式升级为
vmagent + VictoriaMetrics + 夜莺，并对接 Zabbix 告警。 - 核心做法：用北极星指标兜底业务主流程，用灭火图承接技术体系 SLI，用事件墙把变更和重要告警放到一起分析。
- 落地结果：统一纳管监控和告警，运维维护成本降低约 50%。
| 维度 | 信息 |
|---|---|
| 行业 | 智慧出行、数字票务 |
| 原有系统 | Prometheus、Zabbix、CAT 等多套分散监控系统 |
| 规模 | 20 多个机房、20+ 套集群、上千台服务器 |
| 核心痛点 | 多平台割裂、告警规则分散、跨地域运维难以快速筛选和定位问题 |
| 采用方案 | Nightingale 商业版 + vmagent + VictoriaMetrics，统一承接监控展示、告警治理、日志查询 |
| 结果 | 实现统一监控与告警平台建设，运维维护成本降低约 50%，研发无需频繁登录多个平台和云账号 |
| 相关产品 | Nightingale（夜莺监控）、统一可观测解决方案 |
八维通科技在全国范围内管理 20 多个机房、20+ 套集群和上千台服务器，基础设施、应用与网络链路分布广、类型杂。随着业务扩展，原有由 Prometheus、Zabbix、CAT 等工具组成的监控体系逐渐暴露出平台分散、规则维护成本高、跨地域告警筛选困难等问题。为此，团队选择 Nightingale 商业版作为统一监控与告警平台，并结合 vmagent 与 VictoriaMetrics 完成底层架构升级。
公司介绍
八维通科技是中国中车旗下、聚焦空间智能与数字孪生的国家级专精特新 “小巨人” 企业，从智慧出行起家，现已拓展为城市级空间智能服务商。
- 全球首个提出城市轨道交通移动互联网数字票务解决方案，包揽全国首批轨交二维码乘车全线开通案例。
- 业务覆盖：34 个城市轨道交通、19 个城市公交数字票务，延伸至景区、高速、通卡、加油等场景。
- 核心产品：数字票务、人脸支付、MaaS 出行服务、地铁乘客个人碳账户系统。
背景与痛点
在日常运维中，需要同时管理二十多个机房、20+ 套集群和上千台服务器。各个机房分布在全国各地，对监控稳定性和运维效率都有较高要求。
- 基础设施：物理机、虚拟机、容器、网络设备，遍布全国各地
- 应用服务：核心业务应用、微服务、开源中间件、商业应用
- 网络链路：跨机房、跨集群
原有监控体系中，Prometheus 负责基础服务监控，Zabbix 负责硬件层监控，CAT 负责业务层监控。整体比较分散，需要登录多个平台进行配置和查看；各团队还要分别熟悉不同平台的告警规则并单独调整，运维人员也无法快速筛选各个城市的告警。
选型过程
为了方便所有运维人员统一维护，团队最终选择夜莺（商业版）进行管理。
- 夜莺界面化的告警规则管理
- 夜莺告警支持多数据源
- 夜莺强大的权限管理，区分开发和运维人员
落地过程
团队将原来的 Prometheus 联邦模式升级为 vmagent + VictoriaMetrics + 夜莺 的组合，去掉了 Prometheus + Alertmanager + prometheusalert 这套链路。
- 夜莺北极星负责业务监控的展示和告警
- 夜莺灭火图负责基础设施的展示和告警
- 夜莺仪表盘替换掉 Grafana，负责展示基础数据
- 夜莺日志分析负责查询阿里云和华为云的日志，开发不再单独分配云端权限
- 通过夜莺和 Zabbix 对接，Zabbix 告警也实现通过夜莺进行配置
- 实现夜莺作为告警的最终平台，节省运维多个平台跳转的繁琐
- 提供了更完善的大屏能力，更直观地展示监控数据
效果与收益
- 节省运维人员 50% 的维护成本
- 节省开发登录多平台查询日志
- 根据空间切换，各地运维只需关注自己的监控
亮点实践
根据「快猫星云」的实践经验，我们整理了业务的关键北极星指标，覆盖了业务主流程。只要这些指标没问题，业务肯定就是没问题的。如果只是梳理 CPU、内存、磁盘、各类 DB 等基础指标，很难梳理全面，但是业务是可以梳理全面的，所以告警层面只要能覆盖这些核心业务指标，就可以起到极好的兜底效果。
其次就是灭火图，北极星是业务指标，灭火图是技术体系的驾驶舱，主要是梳理 SLI 指标，参考 Google 的四个黄金指标和 RED 等方法论。
Google SRE 那本书说，生产环境 70% 的故障是变更导致的，所以我们引入了“事件墙”，把变更和重要告警放到一起分析，如果产生故障，可以从时间维度查看近期的变更，会有很强的相关性。
日志检索这块，我们使用的云厂商的云日志存储，但是给每个研发配置云账号非常痛苦，最后还是用了夜莺商业版的日志检索，在权限管控上比较灵活方便。
方案复盘：为什么这套统一监控能降低维护成本
| 关键动作 | 原来状态 | 统一后的变化 |
|---|---|---|
| 监控展示收敛 | Prometheus、Zabbix、CAT 等多平台分散查看 | 夜莺北极星、灭火图、仪表盘分别承接业务、基础设施和基础数据展示 |
| 告警规则收敛 | 各团队分别维护不同平台规则 | 夜莺作为最终告警平台，Zabbix 告警也通过夜莺配置 |
| 日志查询收敛 | 研发需要多个云账号查询日志 | 夜莺日志分析统一查询阿里云和华为云日志，并做权限管控 |
| 跨地域运维 | 各地运维难以快速筛选城市告警 | 根据空间切换，各地运维只关注自己的监控 |
| 变更分析 | 告警与变更分散，故障定位依赖人工追问 | 事件墙把变更和重要告警放在同一视图中分析 |
结语
监控、可观测性是个持续运营的活，好工具+好运营=好效果。祝愿各位读者永不宕机，且让老板看到价值！
FAQ
八维通科技为什么要建设统一监控平台？
因为原有 Prometheus、Zabbix、CAT 等系统分散，告警规则需要分别维护，跨地域告警筛选困难，研发查询日志还需要登录多个平台和云账号。
这次改造采用了哪些核心组件？
文中提到的核心组合是 Nightingale 商业版、vmagent 和 VictoriaMetrics。团队将原 Prometheus 联邦模式升级为 vmagent + VictoriaMetrics + 夜莺，并通过夜莺对接 Zabbix 告警。
北极星、灭火图和事件墙分别解决什么问题？
北极星指标覆盖业务主流程，用来判断业务是否健康；灭火图是技术体系驾驶舱，主要梳理 SLI 指标；事件墙把变更和重要告警放在一起，便于从时间维度分析故障与变更的相关性。
统一监控带来了什么收益？
文中给出的结果是：统一纳管 20 多个机房与 20+ 集群，运维维护成本降低约 50%，研发无需频繁登录多个平台和云账号，各地运维可根据空间切换只关注自己的监控。
