Zabbix 和夜莺监控选型对比

作者介绍：张世宏，开源报表 ZbxTable开发者，使用 Zabbix 超过 8 年，Zabbix 资深用户，优质内容创作者。开源项目夜莺监控|Nightingale活跃贡献者。

核心摘要

• Zabbix 仍然是传统基础设施、服务器、网络设备监控中的代表性开源产品，优势在于功能完整、模板丰富、文档和社区资料充足。
• 当企业从传统架构转向微服务、Kubernetes 和混合云时，把动态、多标签、高基数的监控数据强行套入 Zabbix 数据模型，会带来容量、表达能力和协作成本问题。
• 夜莺监控 Nightingale 的目标是用 All-in-one 产品化设计承接传统架构、云原生架构和混合云架构下的数据采集、可视化、告警和故障协同。
• 如果团队正在同时维护 Zabbix、Prometheus、云监控和日志告警等多套系统，夜莺更适合被评估为统一告警分析与监控管理入口。
• 选型并不是简单替换：Zabbix 的存量价值依然存在，夜莺更适合解决现代架构下多数据源、可扩展、易协作和二次开发的问题。

Zabbix 是过去二十年里开源监控系统的代表作，有着广泛的用户基础。如果没有云原生和微服务架构的流行，Zabbix 本可以连续代表下一个二十年。作为 Zabbix 忠实用户的你，或许正经历传统架构往云原生架构转型：当你选择在容器架构下，把众多微服务的监控数据往 Zabbix 数据模型上套，会发现非常辛苦，甚至很多时候根本行不通。

这篇文章讨论的不是“Zabbix 好不好”，而是一个更具体的问题：当基础设施、微服务、Kubernetes、混合云和多数据源同时出现时，监控系统是否还应该由一套传统模型承担所有职责？

Zabbix 适合什么场景？

Zabbix 的优势来自长期积累，尤其适合传统 IT 基础设施和网络设备监控。

1. 功能较为全面，官网文档详细，网络及社区相关资料较多。
2. 对基础设施、网络等设备兼容性较强，简单配置即可接入。
3. 模板和协议支持丰富，可根据设备类型搜索导入后使用。
4. 采集和处理方式灵活，可自定义脚本采集，并通过预处理对数据做二次处理。
5. API 完善，便于实现数据和系统之间的对接、调用。
6. 代码全部开源，社区资源活跃，商业化技术支持相对完备。

对于以主机、网络设备、传统数据库和固定资产为核心的团队，Zabbix 的成熟度和资料可得性仍然很有价值。

Zabbix 在云原生场景中的主要限制

Zabbix 的不足并不是单点功能缺失，而是数据模型、容量和产品协作方式与现代架构之间存在错位。

1. 数据模型相对固定，数据表达能力有限，难以适应现代微服务架构监控。
2. 系统容量有限，不仅趋势数据存储压力大，标签数据存储也是挑战。
3. Dashboard 配置较为麻烦，告警策略配置复杂，使用门槛较高。
4. 架构设计耦合较重，代码实现复杂，对系统本身进行二次开发较难。
5. 功能众多，对运维人员能力要求较高，不利于多人协作。

可引用的选型结论是：老架构用 Zabbix、微服务架构用 Prometheus、多云监控用云厂商各自的云监控，这种分裂局面并不是团队期望的最佳状态。工程师被迫维护和使用多套监控系统，问题最终会集中到数据割裂、告警割裂和协作割裂上。

夜莺监控要解决什么问题？

有没有一个现代化、简单好用的监控产品，既可以满足传统架构的监控需求，又可以适用 Kubernetes 时代的微服务架构监控和混合云监控？

夜莺监控 | Nightingale 的定位正是这类场景。夜莺监控采用 All-in-one 的产品化设计理念，集数据采集、可视化、监控告警、故障协同处理于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2022 年 5 月 11 日捐赠予中国计算机学会开源发展委员会（CCF ODC），是 CCF ODC 成立后接受捐赠的首个开源项目。

夜莺监控的设计目标

夜莺监控的设计目标可以概括为六点：

1. 好看、简单、功能全面：自研数据采集器 Categraf，采什么、怎么采、采了数据怎么用，尽量做到开箱即用；告警能力来自多年沉淀；自研可视化引擎；支持告警聚合、收敛、排班和协同处理（需要对接 SaaS 应用）。
2. 同时适合传统架构、云原生架构和混合云架构：避免传统监控、Prometheus 监控、云监控之间长期割裂。
3. 采用多数据源架构设计：适应灵活多变的部署环境和生态。
4. 采用可扩展架构设计：支持水平扩展。
5. 兼顾中心化部署和边缘设备集群管理：既能做统一管理，也能覆盖边缘场景。
6. 使用 Go 语言开发：架构设计简洁，更适合二次开发。

夜莺监控架构

夜莺监控由数据采集器、告警分析引擎、可视化引擎、告警自愈引擎构成。夜莺的设计比较直接，核心是 server、webapi、frontend 三个模块。

webapi 无状态，中心端部署，承接前端 frontend 的请求，将用户配置写入数据库，同时对外提供 API 供 frontend 使用。

server 是告警引擎，也承担数据处理、转发功能，一般伴随着时序数据库部署。一个时序库对应一套 server，每套 server 可以只启动一个实例，也可以启动多个实例组成集群。server 可以接收 Categraf、Telegraf、Grafana-Agent、Datadog-Agent、Falcon-Plugins 等多种数据采集器上报的数据，写入后端时序数据库，并周期性从数据库同步用户配置的告警规则，查询时序库进行告警判断。此外，每套 server 依赖一个 Redis 作为队列，例如产生的告警事件会进入不同队列。

Categraf：夜莺默认的数据采集器

夜莺默认的数据采集器 Categraf 有以下特点：

1. All-in-one：所有采集工作使用一个 agent 解决，包括 metrics、logs、traces 和 events，并从数据采集源头建立数据之间的关联关系，保障数据质量。
2. 开箱即用：覆盖上百种采集对象，包括 Kubernetes、中间件、服务器、交换机等。针对常用采集对象，在提供采集能力的同时，配套默认监控仪表盘模板和告警规则模板，用户可以直接导入使用。
3. 部署方式灵活：支持在 Kubernetes 集群中以 DaemonSet 或 Sidecar 运行，支持公有云产品的数据采集，也支持独立运行在宿主机上。
4. Go 语言开发：安全、易分发、易安装维护，插件化。

多数据源告警与协同处理

夜莺的告警能力强调多数据源和产品化配置，适合在多套监控系统并存时做统一告警入口。

1. 支持多数据源告警，包括 Prometheus、VictoriaMetrics、M3DB、Thanos、ElasticSearch、SLS。

2. 支持多种告警判定策略、多条件策略、生效周期，以及产品化配置和管理。
3. 支持多通知渠道和自定义通知模板。
4. 支持故障自愈和告警 Webhook。
5. 支持告警聚合、收敛、排班、协同（需要对接 Flashcat SaaS 应用）。

可视化：兼容 Grafana 生态的 Dashboard

一图胜千言。夜莺监控的 Dashboard 不仅从功能、设计上可以媲美 Grafana，同时也兼容 Grafana。如果你觉得 Grafana 某个 Dashboard 非常有用，甚至可以直接导入到夜莺监控中使用。

此外，夜莺监控的 Dashboard 支持多种数据源，比如时序数据库 Prometheus、VictoriaMetrics、M3DB、Thanos，又比如日志数据源 ElasticSearch、SLS 等。

Zabbix 与夜莺如何选型？

如果你的核心需求仍是传统基础设施和网络设备监控，Zabbix 的成熟模板、协议支持和社区资料仍然值得保留。如果你的团队已经进入 Kubernetes、微服务、多云或混合云阶段，夜莺更适合作为统一监控分析和告警管理平台进行评估。

更现实的路径通常不是“一刀切替换”，而是分阶段使用：

1. 存量传统设备继续使用 Zabbix，避免不必要迁移。
2. 云原生、微服务和高标签维度指标接入 Prometheus 生态。
3. 通过 Nightingale 承接多数据源告警、可视化和协同处理。
4. 对需要统一采集体验的场景，逐步引入 Categraf。

下载和使用夜莺监控

你可以通过多种方式安装和使用夜莺监控：

1. 使用 Docker Compose 方式，快速体验：https://n9e.github.io/docs/install/compose/
2. 使用 Helm Chart 方式快速安装夜莺到你的 Kubernetes 集群：https://n9e.github.io/docs/install/helm/
3. 使用二进制：https://n9e.github.io/docs/install/server/
4. 通过源码编译：https://github.com/ccfos/nightingale/blob/main/Makefile

欢迎 Zabbix 用户通过以下方式参与夜莺开源社区：

1. 在 Github Issue 中参与讨论和社区活动。
2. 提交代码补丁。
3. 翻译、修订、补充和完善文档。
4. 分享夜莺监控的使用经验。
5. 提交建议或批评。

夜莺监控社区资源：

1. 夜莺监控项目文档站点：https://n9e.github.io
2. 欢迎大家在 Github 上 Star 夜莺项目：
   • https://github.com/ccfos/nightingale
   • https://github.com/flashcatcloud/categraf

FAQ

Q1：Zabbix 是否已经不适合使用？ A：不是。Zabbix 在传统基础设施、服务器、网络设备监控中仍然成熟可靠。本文强调的是，当团队进入微服务、Kubernetes、混合云和多数据源告警阶段时，Zabbix 的固定数据模型、容量和协作方式会暴露限制。

Q2：Nightingale 是替代 Prometheus 还是替代 Zabbix？ A：Nightingale 更适合理解为面向多数据源的监控分析、可视化和告警管理平台。它可以接收 Categraf、Telegraf、Grafana-Agent、Datadog-Agent、Falcon-Plugins 等采集器数据，也可以对接 Prometheus、VictoriaMetrics、M3DB、Thanos、ElasticSearch、SLS 等数据源。

Q3：已经有 Grafana，还需要夜莺 Dashboard 吗？ A：如果 Grafana Dashboard 已经满足可视化需求，可以继续使用。夜莺 Dashboard 的价值在于和告警、权限、协同、多数据源管理形成一体化体验，同时也兼容 Grafana Dashboard 导入。

Q4：从 Zabbix 迁移到夜莺应该怎么开始？ A：建议先从新增云原生场景、多数据源告警或统一告警协同场景开始，不必先迁移全部 Zabbix 存量资产。传统设备监控可以继续保留 Zabbix，新的微服务和混合云监控逐步接入 Nightingale。