【无标题】

监控系统架构选型

对比项	Prometheus	Zabbix	Cacti	Open-Falcon	Nagios
发展	2015年后开始发展迅速，但是相对于Zabbix来说发展时间还是较短，成熟度不及对方	2004年3月发布1.0 稳定版，比Prometheus早了11年，对多种监控场景都有成熟的解决方案	2001年发布，主要作为流量监控工具	Open-Falcon 是一种开源的、企业级的、高可用、可扩展的监控系统	Nagios 是在 1999 年出现的，系统功能比较稳定，成熟度较高
对云环境的支持	更适合云环境的监控，对OpenStack，Kubernetes有更好的集成	新版本开始支持，但不稳定，更适合监	不支持	支持云环境	支持较差，配置繁琐
集群规模	支持10000+的集群规模，而且性能更好	集群规模上限节点为10000	/	支持10000+的集群规模	/
二次开发	提供了Go、Java/Scala、Python、Ruby等丰富的sdk，二次开发很便捷	采用常用的api，学习成本较低	/	/	/
管理	二进制文件启动	LNMP+编译	/	/	/
基础环境	Prometheus自带TSDB，无需安装第三方数据库	基于MySQL启动	/	自带 RDD	自带RDD
数据存储方式	Prometheus TSDB 监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高	MySQL较常用，学习成本低	/	RDD 数据存储方式，还加入了，一致性 Hash 算法进行数据分片	RDD 数据存储方式
性能比较	高（TSDB优于传统数据库）	低（性能取决于使用的数据库）	/	高	中
数据库差别	非关系型数据库，使用倒排索引，查询性能高	关系型数据库，使用Innodb，支持事务	/	/	/
配置	修改配置文件yml，更好的支持自动化配置	图形化修改，学习成本低	文本编辑	web界面	web界面
社区支持	解决问题上暂时还不如Zabbix，但社区活跃度更高，人数增长快，潜力更大	应用广泛，支持较成熟，遇到问题都能找到	/	活跃度低，而且没有团队维护	活跃度低
client	丰富的client库，为各种中间件、应用提供专业的exporter，监控项更全面	zabbix_agent自定义脚本，支持自定义监控项，对监控设计者对格局要求较高	/	/	/
部署难度	只有一个核心server组件，一条命令便可以启动	多种系统，多种监控信息采集方式	/	易部署	部署复杂
是否支持Window	支持	主节点安装包只有Linux	/	/	/
主节点	Prometheus（82M）+node_exporter（9M）+grafana（91M）+alertManager（25M）+prometheus-webhook-dingtalk（8M）≈215M（磁盘占用）；node_exporter(20M)+Prometheus（120M）+prometheus-webhook-dingtalk（20M）≈ 160M（内存占用）。主节点端口：9090，alertmanager：9093，grafana：3000，prometheus-webhook-dingtalk：8060	Mysql（528.8MM）+ 22M + grafana（91MB）≈ 641M（磁盘占用）；MySQL（320M）+ 48M+ 180M≈548M（内存占用）。主节点不支持window。监听端口10051，grafana：3000	/	/	/
Node节点	磁盘占用：9M，内存占用：20M。Linux下需要开启9100端口，window下需要开启9182端口。使用http接口	磁盘占用：zabbix-agent（4M），内存占用：10M。占用端口10050，http接口	/	/	/
第三方数据支持	各种传统数据库、Nosql、消息队列，以及Nginx	同样支持，但社区使用度较低	不支持	部分支持，不支持如tomcat、apache、jetty	不支持
容器支持	不仅支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好的解决方案	新版本开始支持，但不稳定	/	支持	不支持

架构对比：

Prometheus架构图：

Zabbix架构图

Prometheus优缺点

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缺点：

"Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。

Prometheus 默认是 Pull 模型，合理规划网络，尽量不要转发。

对于集群化和水平扩展，官方和社区都没有给出特定方案，需要合理选择 Federate、Cortex、Thanos 等方案。

监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。

Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果。二是查询范围过长要做降采样，势必会造成数据精度丢失，不过这是时序数据的特点，也是不同于日志系统的地方。"

Zabbix优缺点：

Zabbix优势：

数据采集：可用性和性能检测，自动发现，支持agent、snmp、JMX、telnet等多种采集方式，支持主动和被动模式数据传输、支持用户自定义插件，自定义间隔收集数据。
高可用：server对设备性能要求低，支持proxy分布式监控，分布式集中管理，有自动发现功能，可以实现自动化监控，开放式接口，扩展性强，插件编写容易。
告警管理：支持多条件告警，支持多种告警方式，支持多组模版，模版继承。
告警设置：告警周期，告警级别，告警恢复通知，告警暂停，时段阈值，支持维护周期，支持单机停用。
图形化展示：获取到到数值型到数据，可自动生成图，允许自定义创建多监控项视图，网络拓扑，自定义面板展示，自定义IT服务可用性。
历史数据：历史数据查询可配置，内置housekeeping数据清理机制。
安全审计：具备安全对用户审计日志，权限认证，用户可以限制允许维护对列表。
操作快捷：使用了与Nagios/Cacti相比较先进到Web前端技术，可以通过Web界面设置或查看监视结果；或者通过Graphs+Screens的方式可以按需聚合信息。在添加监控项目或者机器到时候十分迅速，操作易用性较好。

Zabbix劣势：

虽然Zabbix拥有完善的文档，活跃的官方社区，但是深入之后就会发现其中文资料相当的少，给到的服务支持是有限的。
监控系统具有持续性和周期性，这就导致当机器量增大的同时，数据量的增大会给数据库的写入带来一定的负担。官网给出的最大单机数为5000台，超过这个范围后就需要增加proxy，这也带来了成本的增加。
Zabbix支持主动和被动两种方式，其中的server主动模式，采集数据有pull方式，但是目标机器量大之后，就会出现积压从而导致数据的采集延迟。
housekeeping虽然可以进行数据清理，但是运行的同时也会给数据库带来不小的压力，因此数据库还是需要优化的。
在数据处理方面，缺少数据汇总功能，这样就无法查看一组服务器的平均值，项目上若是进行二次开发的话，在深度熟悉Zabbix的前提下，还需要分析复杂的MySQL表结构，API开发方面也对能力要求较高。
系统级别报警设置较多，在保证不错过任何重要消息的同时，若是不筛选的话大量的报警邮件也会带来困扰；但自定义的项目报警又涉及到了个人设置，过程比较繁琐。

Prometheus与Zabbix的对比：

其它监控工具

	Cacti	Open-Falcon	Nagios
优点	cacti是很老的一款监控工具了，其实说它是一款流量监控工具更合适，对流量监控比较精准	整个系统无核心单点，易运维，易部署； 历史数据高效查询；生产环境每秒50万次数据收集、告警、存储、绘图，可持续水平扩展；多维度的数据展示，用户自定义Dashboard等功能。	有灵活的配置，可通过自定义shell脚本监控；功能主要通过插件实现，可以根据自己的需求定制安装
缺点	缺点很多，出图不好看，不支持分布式	支持的监控类型较少，不支持常用应用服务器如tomcat、apache、jetty等的监控； 没有专门的运维支持，代码更新较少，社区活跃度低。	但是每个被监听端都需要配置，整体配置复杂，而且出错了没有历史记录可查看很难找到出错原因。同时插件功能安装比较复杂。

Prometheus详细告警流程

1. node_exporter采集数据，采集到主机的运行指标如CPU, 内存，磁盘等信息。然后向外暴露http接口
2. Prometheus server可以通过配置，获取暴露的expexorter中的信息，然后存储到内部的TSDB中
3. Prometheus web UI 或者 Grafana可以通过PromQL解析TSDB中的数据，并展示数据
4. Prometheus 可以通过自定义规则文件向AlertManager发送信息，AlertManger可通过编写配置文件发送邮箱，发送钉钉机器人通过安装prometheus-webhook-dingtalk配置发送

部署：Prometheus实现告警功能需要配置好相关配置文件，各组件间相互对接即可完成，报警规则编写上手难度不大

Zabbix详细告警流程

1. Zabbix-agent采集数据，将采集到的数据（要采集什么根据配置）发送到Zabbix-server中，Zabbix-server会将数据存储到相应数据库中
2. Zabbix-server须在配置中先配置好agent主机，不同主机可以有不同配置，同时可以配置触发条件，触发可发送通知，以上操作全在Zabbix-web中实现
3. Zabbix-web或者Grafana展示相应数据，Grafana配置相对麻烦
4. 短信通知可以通过Zabbix-web配置结合触发器完成，要实现钉钉服务需要部署alertscripts脚本，编写图形客户端完成

部署：Zabbix部署主节点同时需要部署数据库，同时配置多个组件，但后续配置数据采集、短信规则都可以通过图形化界面解决。

总结：部署流程上Prometheus配置文件更多，且更有上手难度。Zabbix除了主节点部署更复杂之外，其余都是可以通过图形化界面配置相对更容易。