【无标题】
文章目录
- 监控系统架构选型
-
- 架构对比：
-
- Prometheus架构图：
- Zabbix架构图
- Prometheus优缺点
-
- Prometheus的优点：
- Prometheus缺点：
- Zabbix优缺点：
-
- Zabbix优势：
- Zabbix劣势：
- Prometheus与Zabbix的对比：
- Prometheus详细告警流程
- Zabbix详细告警流程
监控系统架构选型
| 对比项 | 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详细告警流程
- node_exporter采集数据，采集到主机的运行指标如CPU, 内存，磁盘等信息。然后向外暴露http接口
- Prometheus server可以通过配置，获取暴露的expexorter中的信息，然后存储到内部的TSDB中
- Prometheus web UI 或者 Grafana可以通过PromQL解析TSDB中的数据，并展示数据
- Prometheus 可以通过自定义规则文件向AlertManager发送信息，AlertManger可通过编写配置文件发送邮箱，发送钉钉机器人通过安装prometheus-webhook-dingtalk配置发送
部署：Prometheus实现告警功能需要配置好相关配置文件，各组件间相互对接即可完成，报警规则编写上手难度不大
Zabbix详细告警流程
- Zabbix-agent采集数据，将采集到的数据（要采集什么根据配置）发送到Zabbix-server中，Zabbix-server会将数据存储到相应数据库中
- Zabbix-server须在配置中先配置好agent主机，不同主机可以有不同配置，同时可以配置触发条件，触发可发送通知，以上操作全在Zabbix-web中实现
- Zabbix-web或者Grafana展示相应数据，Grafana配置相对麻烦
- 短信通知可以通过Zabbix-web配置结合触发器完成，要实现钉钉服务需要部署alertscripts脚本，编写图形客户端完成
部署：Zabbix部署主节点同时需要部署数据库，同时配置多个组件，但后续配置数据采集、短信规则都可以通过图形化界面解决。
总结：部署流程上Prometheus配置文件更多，且更有上手难度。Zabbix除了主节点部署更复杂之外，其余都是可以通过图形化界面配置相对更容易。