Zabbix、Prometheus、Grafana、Nightingale，四个监控如何选型？合集 - 可观测性(40)
调研监控系统的时候，通常会看到这四个产品：Prometheus、Grafana、Zabbix、Nightingale，对新手而言，是个选型难题。本文尝试分别解释其适用场景和优缺点，当然了，每个人的认知都有局限，仅供大家参考。
Zabbix
Zabbix 是老牌监控产品，主要用于资产设备监控，比如监控网络设备、服务器，Zabbix 要求用户在 UI 上主动添加设备，填写连接地址、认证信息。是典型的资产式管理逻辑。
Zabbix 也可以监控 MySQL、Redis、Postgres、Kubernetes 等各类开源组件，但这不是它的长处，采集的指标偏少、海量指标不方便检索。
对于微服务指标监控，Zabbix 就更加不擅长了，这是 Prometheus 生态的天下。
Zabbix 产品经过多年打磨，产品完成度极高，体现在：
- 沉淀了大量的模板，可以开箱即用监控各类网络设备
- 数据采集时的 ETL 处理很完备，因为 SNMP 数据很不规整，促使 Zabbix 沉淀了很多预处理器
- 告警事件的发送链路也有不错的抽象，多种媒介的适配、灵活的消息模板
- 对各类老旧设备的兼容性很好，比如 AIX
Zabbix 仍然服役于大量企业，主要是解决设备监控的场景。
Prometheus
Prometheus 是模仿 Borgmon 诞生的，可谓师出名门，专门为时序数据研发了 TSDB（Time series database），简洁的查询语法、时序数据定义方式，已然成为业内事实标准。
Prometheus 社区有非常多的 Exporter，就是监控采集器，可以采集机器、数据库、中间件等各类监控数据，不同的 Exporter 通常是不同的社区贡献者维护的，所以实际使用时是要部署很多二进制。
可视化方面，Prometheus 仅提供实时 Ad-hoc 查询探索，不提供仪表盘能力，Prometheus 通常和 Grafana 配合使用，由 Grafana 提供仪表盘能力。
告警方面，Prometheus 提供的是 Yaml 文件方式来配置告警规则，没有提供 UI。Prometheus 是单点架构，进程里内置告警引擎，周期性查询自身的监控数据，产生告警事件，告警事件推给 Alertmanager 做后续的去重、静默、抑制、路由、发送。
Prometheus 生态非常开放，吸引了广大贡献者，Prometheus 是当前世界上最流行的监控生态。
实际在落地的时候，如果你们担心单点架构不可靠，或者你们数据量比较大，更建议使用 VictoriaMetrics，VictoriaMetrics 和 Prometheus 接口、协议兼容，姑且可以看作是分布式的 Prometheus。
Prometheus 社区也提供了 SNMP Exporter，也可以监控网络设备，不过相比 Zabbix 的开箱即用，要折腾得多，如果追求统一化平台，可以用 Prometheus 这套体系监控所有数据，如果想追求设备监控的开箱即用，可以两个产品配合使用。
Grafana
Grafana 的用户量是监控、可观测性领域最大的，因为它是可视化领域的老大。虽然 AI 发展迅猛，但是 AI 更擅长的是实时分析、推理，Grafana 不会被 AI 替代，Grafana 相当于是承接了 AI 生成的可视化数据。
Grafana 可以对接多种数据源，最丝滑的是 Prometheus、Mimir、VictoriaMetrics、Tempo、Loki，即：跟自己的产品对接最为丝滑。
Grafana 除了可以对接 Prometheus 查看数据，实际也可以对接 Zabbix 查看，有些人不喜欢 Zabbix 上个时代的 UI 风格，觉得 Grafana 更好看，实际从功能体验来看，我感觉 Zabbix 自身的数据就在 Zabbix 里看图就足够了。
Grafana 实际也可以做告警引擎，对不同的数据源配置告警规则，优点是可以联动多种数据源，缺点是对事件的 Pipeline 处理支持有限，国内使用 Grafana Alerting 的公司比较少。