经常收到网友提问，监控系统选型，到底应该选择 Zabbix 还是 Prometheus？本文谈一下个人看法，希望对你有所启发。
时代决定了基因
Zabbix 是 2001 年左右发布的，那个时代，微服务和 Kubernetes 都不盛行，Zabbix 更多的是关注网络设备、服务器、数据库等传统 IT 基础设施的监控。Zabbix 的创始人是银行运维出身，对于监控相关的各类零碎需求了解的非常透彻。
Prometheus 是 2014 年发布的，相对年轻，依托于之前 Google Borgmon 的先进经验和灵感，Prometheus 在云原生监控领域有着非常好的表现。Prometheus 的创始人是 SoundCloud 的工程师，之前就职于 Google，对 Google Borgmon 有深入的使用经验。Borgmon 是什么？Borgmon 是 Borg 的监控系统，Borg 是 Google 的集群管理系统，Kubernetes 就是 Borg 的开源版本。所以 Prometheus 的设计理念和 Borgmon 有很多相似之处。
所以，Zabbix 一开始就是更多服务于网络设备、服务器的监控，而 Prometheus 则更多服务于微服务、Kubernetes 等新技术的监控。
面向静态资产还是面向动态环境
2001 年那会，企业内部的服务器、网络设备都不会很多，要监控某个服务器或网络设备，就在 Zabbix 页面上把它添加进来就行了，添加的时候绑定模板（模板里包含采集规则、告警规则、预置图表等）、加入 Host Group 即可，非常丝滑。
Zabbix 这种方式可以概括为资产管理式，偏静态，而随着微服务、Kubernetes 体系的发展，IT 变得更加动态了。比如 Redis 部署在 Kubernetes 中，实例数量（随着扩缩容）和位置（由于驱逐、调度等）变化更加频繁，服务一旦重新发布，Pod 的名字就会发生变化，没法把 Pod 类似服务器或网络设备那样添加到监控系统中来静态管理。
所以 Prometheus 体系中，对各种监控对象的管理，主要是采用自动发现的方式来动态获取实例列表，然后做了约定，每个实例都要暴露 /metrics 端点（无法直接暴露的则通过 Exporter 间接暴露），这样一来，整个使用体验和 Zabbix 就截然不同了。
举例，如果你习惯了在 Zabbix 监控中添加监控目标然后就可以采集监控数据，那对于 Prometheus 这种根据发现规则自动发现的方式，就会很不适应。
产品集成度
Zabbix 开始的时代，社区生态比较薄弱，Zabbix 是 All-in-one 的玩法，即你就只需要部署一套 Zabbix，数据采集、可视化、告警等，我全部给你搞定，虽然某些方面做得不出彩，但是它有，它是一个大而全的方案。发展了这么多年，Zabbix 产品自身完成度很高。
Prometheus 发展的年代，人们对大型软件的分层、协同相关的认知提升了很多，而且社区里有很多其他的完备的产品，所以 Prometheus 体系的设计和 Zabbix 截然不同，比如可视化，Prometheus 自身就做得比较弱，主要是交给 Grafana 来处理，而采集，Prometheus 体系也是百花齐放，有各种的 Exporter，告警是自己搞的，开发了 Alertmanager，不过侧重在告警事件的处理（抑制、屏蔽、分组），在告警事件分发层面，还是需要 PagerDuty、FlashDuty 这样的产品来协同体验方为最佳。
Zabbix 未来的演进
Zabbix 也在持续想要增强自身对 Kubernetes、微服务的监控能力，但是社区显然并不买账，绝大部分用户仍然使用 Prometheus 生态来做 Kubernetes、微服务的监控。
Zabbix 的强项还是在服务器和网络设备的监控，尤其是网络设备方面，Zabbix 的采集性能、模板丰富性、社区实践资料等，都远超 Prometheus 生态。
尝试站在 Zabbix 的角度来思考未来的发展，我感觉要扩大能力范围还是很难的，当然，Alexei Vladishev 可能有更多想法，咱们是咸吃萝卜淡操心了。
Prometheus 生态的演进
在讲 Prometheus 的时候，通常我都不是说 Prometheus 本身，而是说 Prometheus 生态，因为你是否使用 Prometheus 进程本身都不一定，举例：
- Exporter：Prometheus 自身提供了几个 Exporter，更多大量的 Exporter 都是社区提供的，甚至还有 Alloy、Cprobe、OTel-Collector 这类想要把 Exporter 整合到一起的项目
- Puller：拉取器，Prometheus 自身就提供了 Scrape 的能力，但是你有更多选择，比如使用 Telegraf、Categraf、vmagent
- TSDB：首推 VictoriaMetrics，已经不建议使用 Prometheus 做时序数据存储了，VictoriaMetrics 和 Prometheus 接口兼容、性能更好、支持集群模式，当然，还有 Thanos、M3、Mimir 等更多选择
- 告警引擎：Prometheus 自身集成了告警引擎，但如果你不是用的 Prometheus 做 TSDB，那你的告警引擎大概率会选择别的，比如 vmalert，或者 Nightingale
Prometheus 生态里，每个细分方面都有替代项目，所以有些公司说是用了 Prometheus，其实它连 Prometheus 进程都没有部署，可能只是用了 Prometheus 的 SDK。这种情况，我们仍然讲他确实是用的 Prometheus 生态，因为他还是遵照了这个生态的玩法。
未来如何演进？Prometheus 采集侧会被 OpenTelemetry 替换掉，存储侧会被 VictoriaMetrics 替换掉么？是有可能的，但显然没法准确预测。对于实践来讲，笔者认为：
- Prometheus 的体系已经很成熟，长期来看，即便风头被抢，对企业而言，继续使用 Prometheus 也没有任何问题
- 如果是新项目，存储方面当然还是建议选用 VictoriaMetrics，YYDS
- 采集层面，新项目要用 OpenTelemetry 么？其实我感觉必要性没有太高，可以等 OpenTelemetry 再成熟一些再做考虑，当然，你们公司有 OpenTelemetry 兜底能力自然是 OK 的。
数据的场景化消费是重点
开源社区的项目要想成功，卡位是极为关键的，把一个细分方向做好做透，是最容易成功的。Zabbix 卡位是设备监控、Prometheus 卡位是动态指标监控。
但是行业的热点，已经不是数据底座了，而是如何用好这些数据，尤其是通过 AI 的能力如何用好这些数据。毕竟，采集数据、数据传输、数据ETL都是脏活累活，而且已经有这么多巨头项目了。
国外的话，有个公司很值得关注，叫 causely，国内的话就是 flashcat，大家都希望把各类可观测性数据做好串联，在上层做故障定位，因为加速故障定位是监控、可观测性数据最大的消费场景。
如何选型
如果你们公司没有大量的网络设备，我感觉选择 Zabbix 的意义不大。Zabbix 是上一个时代的王者，新时代的王者就是 Prometheus，毫无疑问。尤其是你还要考虑职业规划问题，对 Prometheus 更熟悉的话感觉找工作会有帮助。
如果你们真的有很多网络设备，也不见得就不能用 Prometheus，只是需要你这块的知识储备，比如 Zenlayer，全球这么多网络设备，就是从 Zabbix 迁移到了 Flashcat（可以理解为是 Prometheus 的商业产品），他们是因为网络设备太多了，管理复杂度较高，有较高的容量需求，一般来说，几百台或者上千台网络设备用 Zabbix 管理，还是比较舒服的。
One more thing
除了注重工具本身，使用、规范、运营等也很关键，这是一个持续的过程，把工具安装上，只是万里长征第一步。
同样是 Zabbix，有些公司只发挥了其 30% 的能力，有些公司发挥了其 90% 的能力，有些公司只用了其 20% 的能力其中 10% 还没有遵照最佳实践，然后吐槽说这货真难用...
近期文章