1.ZabbixZabbix的核心组件主要是Agent和Server，其中Agent主要负责收集数据并以主动或被动的方式发送给Server/Proxy。此外，为了扩展监控Item，Agent还支持自定义脚本的执行。Server主要负责接收Agent发送过来的监控信息，汇总存储，触发告警等。由于Zabbix使用关系型数据存储时序数据，在监控大数据时往往会在数据存储方面捉襟见肘。规模集群。所以从Zabbix4.2开始就支持了TimescaleDB时序数据库，但是成熟度还不高。2.falconfalcon-agent是一个用Go语言开发的Daemon程序。它运行在每台Linux服务器上，用于收集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等。等，目前支持200多个监控指标。此外，Agent支持用户自定义监控脚本。心跳服务器简称为HBS心跳服务。每个Agent都会通过RPC定期向HBS报告自己的状态，主要包括主机名、主机IP、Agent版本和插件版本。Agent还将从HBS获取执行所需的集合。任务和自定义插件。Transfer负责接收Agent发送过来的监控数据，整理数据，过滤后通过一致性Hash算法发送给Judge或Graph。Graph是一个基于RRD的数据报告、归档和存储组件。Graph收到数据后，会存储在rrdtool的数据归档方法中，同时提供RPC监控查询接口。在Judge报警模块中，TransfertoJudge转发的数据会触发用户设置的报警规则，如果满足则触发邮件、微信或回调接口。这里为了避免重复告警，引入Redis暂存告警，完成告警的合并和抑制。Dashboard是面向用户的监控数据查询和告警配置界面。3.prometheusPrometheusServer负责定时抓取目标上的metrics（指标）数据，并保存到本地存储。Prometheus采用拉取（pull）的方式获取数据，不仅降低了客户端的复杂度，客户端只需要收集数据而无需了解服务端的情况，服务端可以更方便的进行横向扩展。如果监控数据达到告警阈值，PrometheusServer会通过HTTP将告警发送给告警模块alertmanger，告警抑制后触发email或webhook。Prometheus支持PromQL以提供多维度的数据模型和灵活的查询。通过将监控指标关联多个标签，实现监控数据任意维度的组合聚合。对比：开发语言方便易部署（promehteus）系统成熟度（zabbix）20多年系统扩展性Zabbix和Open-Falcon可以自定义各种监控脚本，Zabbix既可以主动推送，也可以被动拉取，Prometheus定义了一套监控数据规范，通过各种exporter扩展系统采集能力。数据存储Zabbix采用关系型数据库存储，极大地限制了Zabbixcollection的性能。Nagios和Open-Falcon都使用RDD数据存储。Prometheus自研高性能时序数据库，在V3版本可以达到每秒千万级的数据存储，通过对接第三方时序数据库扩展历史数据的存储；配置复杂度Prometheus只有一个核心服务器组件，其他系统配置相对麻烦，尤其是Open-Falcon。社区活跃度Prometheus在这方面有绝对优势，社区最活跃，而且有CNCF支持。容器支持Prometheus已经成为容器监控的主导和标准配置。Prometheus功能介绍（1）Prometheus指标类型Counter（计数器）：计数统计，累计多长时间或累计多少次等，其特点是只增不减，如HTTP访问总量;Gauge（仪表板）：数据是瞬时值。如果当前内存使用情况，它会随时间变化。如果需要知道某个请求在一定时间内的响应时间，通常的做法是使用平均响应时间，但这并不能体现数据的长尾效应。比如HTTP服务器的正常响应时间是30ms，但很少有请求需要3s。通过平均响应时间很难识别长尾效应，所以Prometheus引入了Histogram和Summary。直方图：服务器的分位数，不同区间的样本个数，比如班级成绩，60分以下9个样本，70分以下10个样本，80分以下50个样本。Summary（摘要）：客户端的分数，直接在客户端传分数，或者以班级分数为例：0.8分是80分，0.9分是85分，0.99分是98分（二）客户端申请prometheus的方法集成客户端，通过exporter方法提供metrics接口查询（3）prometheus的存储方法Prometheus提供了两种数据持久化方法：一种是本地存储，通过Prometheus自带的tsdb（时序数据库），保存数据到本地磁盘，出于性能考虑，推荐使用SSD。不过本地存储的容量毕竟有限，建议不要保存超过1个月的数据。Prometheus本地存储已经改进多年。从Prometheus2.0开始，V3版本的tsdb性能非常高，可以支持单机每秒1000万个指标的采集。另一种是远程存储，适用于大量历史监控数据的存储和查询。Prometheus通过中间层适配器的转换，将数据保存到远程存储中。Adapter实现了Prometheus存储的远程写入和远程读取接口，将数据转换为远程存储支持的数据格式。目前远程存储主要有OpenTSDB、InfluxDB、Elasticsearch、M3db、Kafka等，其中M3db是目前非常流行的后端存储。(4)prometheus的查询方式类似于关系型数据库的SQL。Prometheus还内置了数据查询语言PromQL，为时序数据提供了丰富的查询、聚合和逻辑运算能力。PromQL主要包括指标名称、过滤器、函数和参数。并且指标可以进行数据操作。(5)prometheus的监控方式Prometheus中配置监控对象的方式有两种，一种是通过静态文件配置，另一种是动态发现机制，自动注册监控对象。Prometheus动态发现目前支持Kubernetes、etcd、Consul等多种服务发现机制。动态发现机制可以减少运维人员的手动配置，这在容器运行环境中尤为重要。容器集群通常有几千甚至几万的规模。每个容器都需要单独配置监控项。不仅工作量大，而且容器变化频繁，使得后续维护极其麻烦。对于Kubernetes环境的动态发现，Prometheus通过watchkubernetesapi动态获取当前集群中所有服务和容器的状态，从而动态调整监控对象。为了扩展单个Prometheus的收集和存储能力，Prometheus引入了“联邦”的概念。多个Prometheus节点形成一个两层的联邦结构。如图所示，上层是联邦节点，负责定时从下层Prometheus节点获取数据并进行汇总。部署多个联邦节点的目的是为了实现高可用，联邦机制可以分为两种，一种是跨服务联邦，一种是层次联邦。跨服务联邦，从不同来源抓取特定服务的监控数据，然后做聚合处理；层次联邦，就像一棵树，更高层级的prometheus服务从大量的二级服务器收集聚合的时间序列数据，然后统一制定告警规则和分发触发事件。此外，prometheus可以依托Thanos插件服务，实现prometheus集群和长期数据存储功能。有兴趣的可以多了解一下。其实prometheus2.0中remote-wirte和remote-read接口的使用本身就已经解决了长期数据存储的问题。预计3.0会有更大的改进，尤其是prometheus的集群。
