Prometheus 对比 Zabbix-低调大师

Prometheus 对比 Zabbix

2018-11-04 757

公司要上监控，Prometheus 是最热门的监控解决方案，作为喜新厌旧的程序员，我当然是选择跟风了，但上级更倾向于 Zabbix，那没办法，只能好好对比一番，给出几个靠谱的理由了。

但稍稍深入一点，我就体会到，我之前其实并没有真的理解口口相传的 Prometheus 的优点，这次对比虽然是始于无奈，但还是蛮有意义的，正好总结一下自己粗浅的体会。

1. 对比

先对两者的各自特点进行一下对比：

Zabbix	Prometheus
后端用 C 开发，界面用 PHP 开发，定制化难度很高。	后端用 golang 开发，前端是 Grafana，JSON 编辑即可解决。定制化难度较低。
集群规模上限为 10000 个节点。	支持更大的集群规模，速度也更快。
更适合监控物理机环境。	更适合云环境的监控，对 OpenStack，Kubernetes 有更好的集成。
监控数据存储在关系型数据库内，如 MySQL，很难从现有数据中扩展维度。	监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合。
安装简单，zabbix-server 一个软件包中包括了所有的服务端功能。	安装相对复杂，监控、告警和界面都分属于不同的组件。
图形化界面比较成熟，界面上基本上能完成全部的配置操作。	界面相对较弱，很多配置需要修改配置文件。
发展时间更长，对于很多监控场景，都有现成的解决方案。	2015 年后开始快速发展，但发展时间较短，成熟度不及 Zabbix。

2. 解析

更进一步的分析两者的主要差异：

2.1 图形化还是配置文件

Zabbix 的图形化配置毫无疑问是完爆 Prometheus 的，但这真的是个优势吗？

细想起来还真未必。图形化确实省去了手动改配置文件和命令行的繁琐，但这种努力毫无疑问是已经做出了需要人工介入的假设。但 Prometheus 是为云原生环境而生的，这种情况下，环境是动态变化的，服务器会随时增减，人工介入不太现实，那么图形化在这种情况下意义就不大了，毕竟要做自动化，那就不必要过图形界面这一道了。这么看来 Prometheus 在图形化方面的简约也是有意的取舍。

2.2 时序数据库还是关系型数据

近几年兴起的监控系统大部分都选择了将数据存储在时序型数据库中，Prometheus 用的就是自研的 TSDB，Zabbix 则用的是 MySQL 或 PostgreSQL。对于时序型数据库我了解不多，粗浅的来看，Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。也许这不能简单的理解为两种数据库的特性造成的结果，但至少说明，对专门监控场景进行存储优化，是十分必要的。

2.3 服务发现

大家都知道 Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据），而以 Zabbix 为代表的传统监控采用的 Push 模型（客户端发送数据给服务端）。Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。

2.4 开发语言

Golang 和 C 语言的开发对比，这就不用多解释了，不是一个时代的语言，Golang 占绝对优势。PHP 写界面倒是很常规的选择，但无奈 Grafana 写界面都不用编程语言，JSON 和 YAML 就可以搞定。所以真的要做定制开发，Prometheus 的难度要小很多。

3. 总结

Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。
Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。

比较一番下来，我的建议是，如果是刚刚要上监控系统的话，不用犹豫了，Prometheus 准没错。

但如果已经对传统监控系统有技术积累的话，还是要谨慎考虑：如果监控的是物理机，用 Zabbix 没毛病，或者是环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，那还是 Prometheus 吧，毕竟人家就是干这个的。

4. 参考文档

微信关注我们

原文链接：https://yq.aliyun.com/articles/664669

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

使用NAS动态存储卷创建有状态应用

介绍：目前动态生成NAS存储卷的实现：在一个已有文件系统上，自动生成子文件系统（子目录），并生成目标存储卷（PV）；生成的PV名字为：pvc-${pv-uid} 镜像介绍： registry.cn-hangzhou.aliyuncs.com/acs/alicloud-nas-controller:v3.1.0-k8s1.11 部署：部署前要先创建一个NAS文件系统，并添加挂载点。注意：挂载点需要和集群处于同一个VPC内部。部署模板中，创建Storageclass的时候可以定义reclaimPolicy类型，可以为Retain或者Delete；根据自己NAS挂载点修改NFS_SERVER、server的值； apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name:

2018-11-04

656

在微服务体系当中，监控是必不可少的。当系统环境超过指定的阀值以后，需要提醒指定的运维人员或开发人员进行有效的防范，从而降低系统宕机的风险。在CNCF云计算平台中，Prometheus+Grafana是比较通用的解决方案，在SpringBoot2.0以后metrics默认与micrometer集成，而micrometer有关于Prometheus的MeterRegistry规范的实现，因此我们通过Micrometer这个桥梁能将SpringBoot的监控数据与Prometheus展示出来。然后通过Grafana提供的UI界面进行数据的实时展示。 Prometheus从对应的节点地址获取度量数据并在本地存储所有数据样例根据相关规则将现有数据聚合并记录新的时间序列（或者生成警报）。可以使用Grafana或其他API消费者来可视化收集的数据。 1. 编写SpringBoot项目并用docker启动 1.1 gradle依赖 compile 'org.springframework.boot:spring-boot-starter-actuator' compile 'io.micrometer...

2018-11-04

835

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。