总结：不同的监控系统比较

小魏的博客

已于 2022-08-12 18:20:55 修改

阅读量1.2k

点赞数

分类专栏：其它文章标签：运维

于 2022-08-12 17:56:05 首次发布

本文链接：https://blog.csdn.net/w2009211777/article/details/126309023

版权

其它专栏收录该内容

27 篇文章 7 订阅

订阅专栏

一、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基金会的项目。