Prometheus的优劣势与Zabbix的对比
作者：互联网
Prometheus简要介绍：
Prometheus是一款警报工具包，它是一个独立的开源项目，并且独立于任何公司进行维护。其完整的监控解决方案对传统监控系统对测试和告警模型进行了彻底对颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。继Kubernetes之后，Prometheus是第二个加入Cloud Native Computing Foundation（云原生云计算基金会）托管的项目。
Prometheus的优点：
1、强大的数据模型：Prometheus中有一个内置的时间序列数据库（TSDB），采集到的所有监控数据都会以一种指标的形式存储在里面。除了储存了基本的名称外，还有描述每一个样本的标签。指标名称和一组标签是判定每一条时间序列的唯一标识，且它按照时间的前后顺序去保存一系列的样本值。关于维度的标签有两种来源方式：监控对象的状态或对于环境的定义。基于这些Labels我们可以方便地对监控数据进行聚合，过滤， 裁剪。
2、监控服务的内部运行状态：用户可以通过在应用程序中添加对Prometheus的支持，轻松的获取到服务和应用内部的真实运行状态，这点完全得益于Prometheus丰富的Client库。
3、管理方便：Prometheus唯一需要的就是一个本地磁盘，因为它的核心部分只有一个单独的二进制文件，没有像数据库，缓存等一系列的第三方依赖。这一特性使它不会潜在级联故障的风险。基于Pull模型的架构方式，Prometheus可以在本地电脑，测试环境等任何地方搭建监控系统；在遇到复杂的情况下，它的Service Discovery能力可以动态管理监控目标。
4、强大的查询语言PromQL：PromQL不仅可以轻松回答诸如：预测四小时之后，磁盘空间占用大致会是什么情况这一类的问题，还能实现对监控数据对查询与聚合。
5、高效率运作：大量对监控任务必然就会对应产生大量的数据。面对数以百万的监控指标，Prometheus可以以每秒处理数十万的数据点进行，这就体现出它的高效处理机制。
6、强可扩展性：Prometheus Server可以在数据中心和团队中独立运行，也可以通过Prometheus对于联邦集群的支持使多个独立的实例产生一个逻辑集群。功能分区（sharding）+联邦集群（federation）可以应用在单实例Prometheus Server处理的任务量过大的时候。
7、集成简易：使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等语言的客户端SDK，基于这些SDK可以快速让应用程序纳入到 Prometheus的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持 Prometheus，还能支持Graphite这些其他的监控工具。 同时Prometheus还支持与其他的监控系统进行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。 Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。
8、可视化：通过Prometheus Server中自带的Prometheus UI不仅可以直接对数据进行查询，还可以以图形化对形式展示数据。且它提供的API还可以实现自己的监控可视化UI。
Prometheus的缺点：
1、Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。
2、Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。
3、对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos 等方案。
4、监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。
5、Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果。
Prometheus与Zabbix的对比：
|
对比项 |
Prometheus |
Zabbix |
|
对云环境的支持 |
更适合云环境的监控，对OpenStack,Kubern etes有更好的集成 |
更适合监控物理机环境 |
|
发展 |
2015年后开始发展迅速，但是相对于Zabbix来说发展时间还是较短，成熟度不及对方 |
发展时间长，对多种监控场景都有成熟的解决方案 |
|
集群规模 |
支持更大的集群规模，速度也快 |
集群规模上限节点为10000 |
|
二次开发 |
提供了Go、Java/Scala、Python、Ruby等丰富的sdk，二次开发很便捷 |
采用常用的api，学习成本较低 |
|
管理 |
二进制文件启动 |
LNMP+编译 |
|
数据存储方式 |
Prometheus TSDB 监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高 |
MySQL较常用，学习成本低 |
|
配置 |
配置文件，更好的支持自动化配置 |
图形化，学习成本低 |
|
client |
丰富的client库，为各种中间件、应用提供专业的exporter，监控项更全面 |
zabbix_agent自定义脚本，支持自定义监控项，对监控设计者对格局要求较高 |
标签：可以,Prometheus,支持,Zabbix,集群,监控,数据,优劣势 来源： https://www.cnblogs.com/yutudaoyao/p/15917574.html