一、zabbix

优点：

• 产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。

• 采集方式丰富：支持 Agent、SNMP、JMX、SSH 等多种采集方式，以及主动和被动的数据传输方式。

• 较强的扩展性：支持 Proxy 分布式监控，有 Agent 自动发现功能，插件式架构支持用户自定义数据采集脚本。

• 配置管理方便：能通过 Web 界面进行监控和告警配置，操作方便，上手简单。

缺点：

• 性能瓶颈：基于Mysql存储。机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是 5000 台。最新版已经开始支持时序数据库，成熟度还不高。

• 数据模型不强大：不支持 Tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。

• 二次开发难度大：Zabbix 采用的是 C 语言，二次开发往往需要熟悉它的数据表结构，且要自己做内存管理，二次开发要求较高，很容易出BUG

• 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），Zabbix 没有提供对应的 SDK，需要通过插件式的脚本实现此功能。

二、Open-Falcon

小米于2015年开源的企业级、高可用、可扩展的监控解决方案。整个系统后端采用golang开发，portal和dashboard使用python开发。

优点：

• 内置指标采集：agent默认采集服务器上200多个基础指标（包括：cpu, memory, disk, network等）
• 支持定义插件：用户可以自定义插件脚本采集和上报业务数据
• 多维度数据模型：类似于openTSDB的数据模型，监控数据项中引入tag，支持多维度的聚合统计和告警规则配置
• 强大的存储能力：采用RRDTool作为数据存储，单机支持200W+指标的上报、归档、存储（1分钟周期数据）
• 高效的数据查询：得益于RRDTool的数据归档策略，支持秒级返回上百个指标的一年历史数据（已完成下采样的数据）
• 水平扩展能力：核心组件之间通过rpc连接，完全可以对各组件单独扩缩容

缺点：

• 整体发展一般：社区活跃度不高，大部分公司基于开源版本做了二次开发
• 部署配置较复杂：组件和依赖服务较多，需要对整体架构有清晰认识
• Mysql依赖严重：各类配置和指标索引都依赖Mysql进行数据同步（默认使用mysql，如果要修改配置存储的位置，需要二次开发），并且受Mysql性能影响

三、Prometheus

Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期开源版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目。

优点：

• 配置管理简单：Prometheus核心部分只有一个server端，单独的二进制程序运行，不依赖任何第三方组件；
• 强大的数据模型：每一条监控数据由指标名称（metric）和一组标签（labels）组成，方便多维度查询和统计
• 丰富的查询语句：内置了强大数据查询语言PromQL
• 易于集成：社区提供了大量的第三方组件的监控数据采集程序（exporter），用户也可以通过client library实现特定监控数据的格式化的输出
• 性能优异：单进程可以支持百万级别指标采集、存储和告警
• 存储需求低：借鉴于Gorilla的时序数据压缩算法，内置的TSDB存储引擎可以到达11倍的压缩比
• 开放性高：用户可以通过remote write/read将Prometheus数据与其他数据库进行联动

缺点：

• 水平扩展问题：Prometheus本身不支持集群化方案，需要借助其他组件来实现，比如：kvass， thanos等
• 缺少用户管理：任何人都可以直接访问Prometheus数据