一、开发语言
zabbix 后端用 C 开发，界面用 PHP 开发，定制化难度很高。
Prometheus 后端用 golang 开发，前端是 Grafana，JSON 编辑即可解决。定制化难度较低。
二、集群规模
zabbix 集群规模上限为 10000 个节点。
Prometheus 支持更大的集群规模，速度也更快。
三、能够监控的环境
zabbix 更适合监控物理机环境。
Prometheus 更适合云环境的监控，对 OpenStack，Kubernetes 有更好的集成。
四、使用的数据库
zabbix 监控数据存储在关系型数据库内，如 MySQL，很难从现有数据中扩展维度。
Prometheus监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合。
五、安装方式
zabbix 安装简单，zabbix-server 一个软件包中包括了所有的服务端功能。
Prometheus 安装相对复杂，监控、告警和界面都分属于不同的组件。
六、使用难度
zabbix 图形化界面比较成熟，界面上基本上能完成全部的配置操作。
Prometheus界面相对较弱，很多配置需要修改配置文件。
七、发展时间
zabbix发展时间更长，对于很多监控场景，都有现成的解决方案。
Prometheus2015 年后开始快速发展，但发展时间较短，成熟度不及 Zabbix。
八、监控数据获取模式
zabbix Zabbix 为代表的传统监控采用的 Push 模型（客户端发送数据给服务端）
Prometheus Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据）
（Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。）
九、client
zabbix zabbix_agent自定义脚本，支持自定义监控项，对监控设计者的格局要求较高
Prometheus 丰富的client库，为各种中间件、应用提供专业的exporter，监控项更全面
十、二次开发
zabbix api适配较为常用，学习成本低
Prometheus提供了Go、Java/Scala、Python、Ruby等sdk,二次开发更便捷
十一、监控项值
zabbix支持数字字符串
Prometheus 支持数字
Prometheus可以在各个层面实现监控，如下
1、基础设施层：监控各个主机服务器资源(包括Kubernetes的Node和非Kubernetes的Node)如CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用等指标。
2、中间件层：监控独立部署于Kubernetes集群之外的中间件，例如：MySQL、Redis、RabbitMQ、ElasticSearch、Nginx等。
3、Kubernetes集群：监控Kubernetes集群本身的关键指标
4、Kubernetes集群上部署的应用：监控部署在Kubernetes集群上的应用
