本次读后感来自于《深入浅出Prometheus：原理、应用、源码与拓展详解》
书籍链接https://item.jd.com/12573580.html

一 Zabbix

1.简介

Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警

2.核心理念

◎ 主机（Host）：是Zabbix监控的对象抽象，每个监控对象都有一个IP地址，这里的主机不仅限于物理服务器，可能是虚拟机容器或者某个网络设备。
◎ 主机组（Host Group）：是一组主机的集合，主要用于多用户之间的资源隔离，将主机组和用户关联，这样 Zabbix 的不同用户便只对自己管理的资源可见。
◎ 条目（Item）：是一个指标的相关监控数据，每个条目都有一个key去标识，以区分不同的指标。
◎ 应用（Application）：是一组条目的集合，一个条目可以属于一个或多个应用。
◎ 模板（Template）：是 Zabbix里快速配置的利器，用于快速定义被监控主机的预设条目集合，通常包含条目、触发器、视图、应用及服务发现规则，通过将主机关联模板来避免重复配置主机。
◎ 触发器（Trigger）：是Zabbix的告警规则，用于评估某监控对象在某特定条目内接收到的数据是否匹配阈值，如果匹配，则触发器状态将从OK转变为Problem，当数据量再次回到合理范围时，触发器状态又将从 Problem 转变为OK。
◎ 动作（Action）：是Zabbix在某个事件发生后执行的动作。事件主要指告警事件、网络发现新主机加入事件、自动注册（代理）事件和内部事件（监控项不支持）；行为主要包括发送邮件通知、执行远程命令或者执行 Zabbix的附加动作。

3.架构设计

(1)Zabbix Server
Zabbix的核心组件，由C语言编写而成，主要负责接收Agent发送的监控信息，并进行汇总存储。Zabbix Server需要完成以下三个主要工作。
◎ 设备注册。有两种方式可以将监控对象注册到设备中：一种是手动配置Agent地址，但如果需要将机房中的几百台机器一次性加入，则将是很大的工作量；另一种是采用自动发现机制，可以配置整个网段，Server会检测整个网段的主机，并且可以自动配置模板、触发器等一系列相关配置。
◎ 数据收集。这里既包括主动采集，也包括被动接收，采集到的数据首先会被放置在内存中，然后被批量保存在数据库中。
◎ 定期的数据清理及告警触发。通过配置的触发器匹配采集数据，如果满足条件，则发出告警。
(2)Zabbix Database
用于存储所有配置信息，以及由 Zabbix 收集的监控数据。后端数据库支持MySQL、PostgreSQL、Oracle等，通常用到的是MySQL，并提供Zabbix Web页面的数据查询方式。由于采用了关系型数据库存储时序数据，所以Zabbix在监控大规模集群时常常在数据存储方面捉襟见肘。
(3)Zabbix WebZabbix的 GUI组件，由 PHP编写而成，通常与 Server运行在同一台主机上，提供监控数据的展现和系统配置，主要配置包括监控模板、告警等。
(4)Proxy
可选组件，常用于分布式监控环境中，代理Server收集部分被监控端的监控数据并按照一定的频率统一发往Server端。Proxy有自己的数据库，引入Proxy主要是为了解决以下两个问题。
◎ Server和Agent之间网络不连通，这种情况在跨网络、跨机房的场景中经常出现。
◎ 在大规模部署时减轻Server的压力，毕竟在同时连接这么多Agent时，Server需要维护更多的连接。以Proxy模式进行部署时，Agent配置的上游地址是Proxy，而Proxy配置的是Server。
(5)Agent
部署在被监控主机上，负责收集本地数据并发往 Server 端或 Proxy 端，Agent会启动一个名为Agentd的守护进程。
Agent 分为两种模式：主动和被动。

• 主动是指 Agent 主动采集数据并将数据发送到Server/Proxy；
• 被动是指Server每次都主动调用Agent获取数据。
  Agent还能执行用户的自定义脚本，从而完成一些原生 Agent不具备的功能。这里补充讲解 Zabbix 的一个工具，即 Zabbix_sender。(6)Zabbix_sender
  是一个命令行工具，可用于主动向Zabbix服务端发送监控数据，这样可避免 Agent一直等待监控任务完成。

二 Nagios

1.简介

Nagios原名为NetSaint，由Ethan Galstad开发并维护。Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控（CPU、内存、磁盘等）和网络监控（SMTP、POP3、HTTP和NNTP等），当然也支持用户自定义的监控脚本

2.架构设计

Nagios的整体架构非常清晰，它通过Plugin采集各种监控数据，例如针对SNMP监控时，通过SNMPplugin和在监控对象上运行的snmpd通信获取网络信息；它还支持一种更加通用和安全的采集方式NRPE（Nagios Remote Plugin Executor），它首先在远端启动一个NRPE守护进程，用于在远端主机上面运行检测命令，在Nagios服务端用check nrep的plugin插件通过SSL对接到NRPE守护进程，执行相应的监控行为。相比SSH远程执行命令的方式，这种方式更加安全。当然，Nagios也支持SSH的Plugin。

3.监控指标

Nagios数据被保存在RDD（Round Robin Database，环形数据库）中，RDD适用于存储时序数据，支持以下4种监控数据。
◎ gauge：仪表盘数据。
◎ counter：计数器。
◎ absolute：不同时间段的变化率，为正数。
◎ driver：变化率，指当前值和前一个监控数值的比值，有正有负。

RDD的存储原理比较简单，它把整个数据存储空间构建成圆环，指针指向最新的数据位置并且会随着数据读写移动，如果此时没有获取监控数据，RDD就会使用默认的unknown填充，保证数据对齐。每个数据库文件都以.rdd结尾，大小是固定的

三 Open-Falcon

1.简介

Open-Falcon 是小米开源的企业级监控工具，由 Go 语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案

2.架构设计

◎ Falcon-agent：用Go语言开发的Daemon程序，运行在每台Linux服务器上，用于采集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。并且，Agent支持用户自定义的监控脚本，脚本必须返回 Agent 指定的数组格式。Agent采集的数据会通过RPC方式上报到Transfer。为了避免单个Transfer发生故障，Agent支持配置多个Transfer地址，还可以忽略多余的监控指标。Agent本身也可以成为一个 Proxy-gateway代理网关，接收第三方 HTTP请求并将其转发到Transfer中。
◎ Hearthbeat server：简称 HBS（心跳服务），每个 Agent 都会周期性地通过RPC 方式将自己的状态上报给 HBS，主要包括主机名、主机 IP、Agent 版本和插件版本，Agent 还会从 HBS 获取自己需要执行的采集任务和自定义插件。
◎ Transfer：负责接收 Agent 发送的监控数据，并对数据进行整理，在过滤后通过一致性 Hash 算法将数据发送到 Judge 或者 Graph。为了支持存储大量的历史数据，Transfer 还支持 OpenTSDB。Transfer 本身没有状态，可以随意扩展。
◎ Judge：告警模块，Transfer转发到Judge的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警，引入了Redis暂存告警，从而完成告警合并和抑制。
◎ Graph:RRD数据上报、归档、存储的组件。Graph在收到数据以后，会以RRDtool的数据归档方式存储数据，同时提供RPC方式的监控查询接口。
◎ API：主要提供查询接口，不但可以从Graph里读取监控数据，还可以对接MySQL，用于保存告警、用户等信息。
◎ Dashboard：由 Python开发而成，提供 Open-Falcon的数据和告警展现，监控数据来自Graph,Dashboard允许用户自定义监控面板。
◎ Aggregator：聚合组件，聚合某集群下所有机器的某个指标的值，提供一种集群视角的监控体验。通过定时从Graph获取数据，按照集群聚合产生新的监控数据并将监控数据发送到Transfer。

四 开源监控的比对

下面针对 Prometheus、Zabbix、Nagios 和 Open-Falcon 这几种监控系统进行横向对比

1.从开发语言的角度

从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C转移到Go。不得不说，Go凭借简洁的语法和优雅的并发，在Java占据业务开发领域、C 占领底层开发领域的情况下，准确定位中间件开发需求，在当前的开源中间件产品中被广泛应用。

2.从系统成熟程度的角度

从系统成熟度方面来看，Zabbix 和 Nagios 都是老牌的监控系统：Zabbix 是在1998年出现的，Nagios 是在1999年出现的，系统功能比较稳定，成熟度较高。而Prometheus和Open-Falcon都是最近几年才诞生的，虽然功能还在不断迭代、更新，但它们站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。

3.从系统扩展性的角度

从系统扩展性方面来看，Zabbix 和 Open-Falcon 都可以自定义各种监控脚本。Zabbix不仅可以做到主动推送，还可以做到被动拉取；Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。

4.从数据存储的角度

从数据存储方面来看，Zabbix采用关系数据库存储数据，这极大限制了 Zabbix的数据采集性能。Nagios和Open-Falcon都采用了RDD数据存储方式。Open-Falcon还加入了一致性 Hash 算法进行数据分片，并且可以对接到 OpenTSDB，而且Prometheus 自研的一套高性能时序数据库，在 V3版本时可以达到每秒千万级别的数据存储，可通过对接第三方时序数据库扩展对历史数据的存储性能。

5.从社区活跃的角度

从社区活跃度方面来看，目前 Zabbix 和 Nagios 的社区活跃度比较低，尤其是Nagios,Open-Falcon的社区虽然也比较活跃，但基本都是国内的公司在参与。Prometheus的社区活跃度很高，并且得到CNCF的支持，后期的发展值得期待。

6.从容器的支持角度

从容器支持方面来看，由于 Zabbix 和 Nagios 出现得比较早，当时容器还没有诞生，所以它们对容器的支持自然也比较差。Open-Falcon虽然提供了容器监控功能，但支持力度有限。Prometheus的动态发现机制，不仅支持Swarm原生集群，还支持Kubernetes 容器集群监控，是目前容器监控的最佳解决方案。Zabbix 在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。Nagios则在网络监控方面有广泛应用。伴随着容器的发展，Prometheus 开始成为容器监控方面的标配，并将被广泛应用。