1.4.3　5种常见的监控系统

有些技术人员常说：“我刚接触监控的时候就已经是Prometheus的时代了，我都没有接触过Nagios、Zabbix这些上古监控系统。”那么，在Prometheus之前，常见监控系统都是怎样的呢？让我们一起来了解一下。

1.Nagios

Nagios^[1]原名NetSaint，是Nagios Ain’t Gonna Insist On Sainthood的缩写，Sainthood译为圣徒，而Agios是saint希腊语的表示方法。它是由Ethan Galstad开发并维护的一款开源且老牌的监控工具，用C语言编写而成。Nagios虽然开发时被定义为在Linux下使用，但在UNIX下也工作得非常好。

在涉及开源监控时，Nagios会被一些人认为是“行业标准”，这在某种程度上是正确的，因为Nagios是第一个真正称得上专业的监控系统。在Nagios之前，虽然也有一些监控工具，但是这些工具都太“业余”了，以至于它们根本无法与1999年推出的Nagios相提并论。Nagios是监控领域的第一个跨时代产品，且拥有最大的社区和非常多的Fork，如OpsView、OP5、Centreon、Icinga、Naemon、Shinken等。有过多的Fork，意味着在应用插件或工具时会造成混乱，因为每个分支都有不同的理念，随着时间的推移，这使得Nagios与其他分支、父项目（Nagios）出现不兼容的现象。

Nagios能有效监控Windows、Linux和UNIX的主机状态（CPU、内存、磁盘等），以及交换机、路由器等网络设备（SMTP、POP3、HTTP和NNTP等），还有Server、Application、Logging，用户可自定义监控脚本实现对上述对象的监控。Nagios同时提供了一个可选的基于浏览器的Web界面，以方便系统管理人员查看网络状态、各种系统问题以及日志等。

如图1-8所示，Nagios的核心架构主要由Nagios Daemon、Nagios Plugins和NRPE这3个模块构成。

由图1-8可知：

1）Nagios Daemon作为系统的核心组件，负责组织与管理各组件，协调它们共同完成监控任务，并负责监控信息的组织与展示。

2）Nagios Plugins主要指Nagios核心组件自带的组件，还包括一些用户自开发的插件。这些组件监控各项指标，并将采集到的数据回送给Nagios服务器。

3）NRPE（Nagios Remote Plugin Executor）是安装在监控主机客户端上的代理程序（Linux系统是NRPE软件）。通过NRPE可获取监控数据，这些数据会被再回送给Nagios服务器。默认使用的端口是5666。

图1-8　Nagios架构图

Nagios以监控服务和主机为主，但是它本身不包括这部分功能，是通过“插件”生态系统或第三方功能来实现的。在主动模式中，Nagios不需要调用客户端的插件，而是通过自己的插件主动探测客户端的相关信息；在被动模式中，Nagios通过启动客户端上的NRPE来远端管理服务。启动Nagios后，它会周期性自动调用插件以检测服务器状态，同时会维持一个队列，所有插件返回的状态信息都会进入该队列，Nagios每次都会从队首读取信息，处理后再将状态结果呈现出来。被动模式的具体流程如下（见图1-9）。

1）Nagios执行安装在它里面的check_nrpe插件，并告诉check_nrpe检测哪些服务。

2）通过SSL，check_nrpe连接远端机器上的NRPE Daemon。

3）NRPE运行本地的各种插件来检测本地的服务和状态。

4）NRPE把检测结果传给主机端check_nrpe，check_nrpe再把结果送到Nagios状态队列中。

5）Nagios依次读取队列中的信息，再把结果显示出来。

图1-9　Nagios运行流程

Nagios会将获取的数据保存在环形数据库（Round Robin Database，RDD）中。RDD是一种循环使用存储空间的数据库，适用于存储和时间序列相关的数据。RDD数据库在创建的时候就会定义好大小并使数据存储空间形成圆环状，每个数据库文件都以.rdd为后缀，指针指向最新的数据位置并随着数据读写移动。如果没有获取到最新数据，RDD就会使用默认的unknown填充空闲空间，以保证数据对齐。当空间存储满了以后，又从头开始覆盖旧的数据，所以和其他线性增长的数据库不同，RRD的大小可控且不用维护。

Nagios出现于20世纪90年代，它的思想仍然是通过复杂的交错文本文件、脚本和手动程序进行管理，基于文本文件的配置每次进行更改时都需要进行重置，这也使得在文件分布复杂的情况下必须借助第三方工具（例如Chef或Puppet）进行部署，因此Nagios如何进行有效配置管理是一个瓶颈^[2]。为了使用Nagios监控，有必要熟练掌握处理数百个自定义脚本的方法，若这些脚本由不同的人采用不同的风格编写，那么处理脚本的过程几乎会变成某种“黑魔法”。对很多人来说，管理Nagios是非常复杂的，这最终导致Nagios成为软件与定制开发之间的奇怪组合。

Nagios（以及它的一些较新的分支，如Naemon）仍然使用C编写的CGI。这项技术是在20世纪80年代发明的，对其进行扩展或改进会很复杂，哪怕进行简单更改，都需要对整体架构代码打补丁并手动编译。Nagios生态系统是基于每个Fork的不同版本的数百个不同补丁建立的，它简直就是一个集市^[3]，是“集市”模式的范例；而Zabbix和Pandora FMS则恰恰相反，是“大教堂”模式，是模块化的可靠项目，在架构师团队的指导下正在不断发展。

2.Zabbix

Zabbix是一款拥有超过21年的历史、100%免费开源、全世界安装次数超过30万的监控软件（截至2019年），旨在从成千上万的服务器、虚拟机和网络设备中收集指标进行监控，是适用于绝大多数IT基础架构、服务、应用程序、云、资源等的解决方案。Zabbix长期以来一直在瓜分Nagios的蛋糕，但它是一个成熟的系统，而不是简单的Nagios的分支，它的主要特征是对监控具有非常全面的视角，而不是仅仅监控状态，这恰是Nagios存在严重不足的地方。Zabbix的配置文件也不像Nagios那么复杂。

Zabbix是由Alexei Vladishev开源的分布式监控系统，和Nagios一样提供集中的Web管理界面。Zabbix有着非常酷炫的新版官网^[4]和详细的文档使用手册^[5]，企业级的Zabbix具有无限扩展、分布式监控、高可用、强大的安全性等特性。在本书截稿时，Zabbix 4.4版本刚刚发布，这个版本用Go语言编写了全新的Zabbix代理，为Zabbix模板设置了标准，除了为MySQL、PostgreSQL、Oracle、DB2新增了TimescaleDB这种具有线性性能的数据库以外，还提供了高级可视化选项，以及一键式云部署等功能。

图1-10是Zabbix的架构图，Zabbix可以通过Agent及Proxy的形式（见图1-11），比如JVM Agent、IPMI Agent、SNMP Agent等采集主机性能、网络设备性能、数据库性能的相关数据，以及FTP、SNMP、IPMI、JMX、Telnet、SSH等通用协议的相关信息，采集信息会上传到Zabbix的服务端并存储在数据库中，相关人员通过Web管理界面就可查看报表、实时图形化数据、进行7×24小时集中监控、定制告警等。

图1-10　Zabbix架构图

图1-11　Zabbix新版Agent

3.Ganglia

Ganglia直译为神经节、中枢神经，这一名称其实已经反映了作者的设计思路，即将服务器集群理解为生物神经系统，每台服务器都是独立工作的神经节，这些神经节通过多层次树突结构联结起来，既可以横向联合，也可以从低到高逐层传递信息。具体例证就是Ganglia的收集数据可以工作在单播（unicast）^[6]或多播（multicast）^[7]模式下（默认为多播模式）。很多通过cacti或者Zabbix看不出来的集群总体负载问题，都能在Ganglia中体现，其集群的熵图可以明确集群负载状况，这是Ganglia最大的亮点。

Ganglia^[8]是加州大学伯克利分校发起的一个为HPC（高性能计算）集群而设计的开源、可扩展、分布式监控系统，用于测量数以千计的节点。作者于2000年在伯克利分校网站上分享了源码。Ganglia是BSD许可的开源项目，源于加利福尼亚大学的伯克利千年项目，最初是由美国国家高级计算基础设施合作伙伴（NPACI）和美国国家科学基金会RI奖EIA-9802069资助的。Ganglia用于大规模的集群和分布式网格等高性能计算系统。基于XML技术的数据传递可以使系统的状态数据跨越不同的系统平台进行交互，且采用简洁紧凑的XDR方式实现监控数据的压缩和传输。它主要用于实时查看Linux服务器和集群（图形化展示）中的各项性能指标，让用户以集群（按服务器组）和网格（按地理位置）的方式更好地组织服务器。

Ganglia的核心包含gmond、gmetad以及一个Web前端，其主要用来监控系统性能，如CPU使用率、硬盘利用率、I/O负载、网络流量情况等，通过曲线很容易查看每个节点的工作状态，这对合理调整、分配系统资源，提高系统整体性能起到重要作用。Ganglia与Falcon、Zabbix相比，主要区别体现在集群的状态集显示上，Ganglia可以很便捷地对比各主机的性能状态。但随着服务、业务的多样化，Ganglia表现出一些不足：覆盖的监控面有限，且自定义配置监控比较麻烦，在展示页面查找主机烦琐，展示图像粗糙且不精确。

如图1-12所示，Ganglia通过gmond收集数据，数据传输到服务端gmetad，最后在PHP编写的Web UI界面Web前端进行展示。组件之间通过XDR（xml的压缩格式）或者XML格式传递监控数据，以达到监控效果。

图1-12　Ganglia工作原理

图1-12所示的各个模块介绍如下：

·gmond（Ganglia Monitoring Daemon）：双重角色，一方面作为Agent部署在需要监控的服务器上，另一方面作为收发机接收或转发数据包。可以将其理解为部署在每个监控服务器上的用于收集和发送度量数据的守护进程。

·gmetad（Ganglia Meta Daemon）：负责收集所在集群的数据并持久存储到RRD数据库，支持水平扩展。

·Web前端：Ganglia项目提供了一个由PHP编写的通用型Web包，可以将主要实现数据可视化，并能提供一些简单的数据筛选UI。页面不多，大量使用了模板技术。

Ganglia的主要优势反映在收集数据和集中展示数据方面。Ganglia可以将所有数据汇总到一个界面集中展示，并且支持多种数据接口，可以很方便地扩展监控，最为重要的是，Ganglia收集数据非常轻量级，客户端的gmond程序基本不耗费系统资源，而这个特点刚好弥补了Zabbix的不足。gmond带来的系统负载非常少，这使得它可以在集群中各台计算机上轻松运行，而不会影响用户性能。所有这些数据多次收集会影响节点性能。当大量小消息同时出现并造成网络“抖动”时，可以通过让节点时钟保持一致来避免这个问题。

Ganglia对大数据平台的监控更为智能，只需要一个配置文件，即可开通Ganglia对Hadoop、Spark的监控，监控指标有近千个，可以满足对大数据平台的监控需求。

和前面提到的Nagios一样，Ganglia的gmetad收集的时间序列数据通过RRD存储，RRDTool作为绘图引擎使用并生成相应的图形显示，以Web方式直观地提供给客户端。Ganglia也拥有灵活的数据标准和插件生态，可以很方便地在默认监控指标上引用或者定制其他扩展指标。这一特性在大数据领域也获得了认可，Hadoop、Spark等都开放了面向Ganglia的指标集，在GitHub上也有很多现成的扩展插件。

4.Open-Falcon

Falcon是猎鹰、隼的意思，鹰眼具有精准、洞穿的特点。Open-Falcon^[9]是小米开源的监控系统，是为了解决Zabbix的不足而出现的产物，它由Go语言开发而成，小米、滴滴、美团等超过200家公司都在不同程度上使用Open-Falcon。小米同样经历过Zabbix的时代，但是当机器数量、业务量上来以后（尤其是达到上万上报节点），Zabbix在性能、管理成本、易用性、监控统一等方面就有些力不从心了。Open-Falcon具有数据采集免配置、容量水平扩展、告警策略自动发现、告警设置人性化、历史数据高效查询、Dashboard人性化、架构设计高可用等特点。Open-Falcon的文档目前分为0.1和0.2版本，且每个版本都有中、英两个版本^[10]，社区贡献了MySQL、Redis、Windows、交换机、LVS、MongoDB、Memcache、Docker、Mesos、URL监控等多种插件支持，其架构如图1-13所示。

图1-13　Open-Falcon架构

如图1-13所示，使用Open-Falcon需要在Linux服务器上安装Falcon-agent，这是一款用Go语言开发的Daemon程序，用于自发现且采集主机上的各种指标数据，主要包括CPU、磁盘、I/O、Load、内存、网络、端口存活、进程存活、ntp offset（插件）、某个进程资源消耗（插件）、netstat和ss等相关统计项，以及机器内核配置参数等指标，指标数据采集完成后主动上报。Falcon-agent配备了一个proxy-gateway，用户可以使用HTTP接口将数据推送到本机的Gateway，从而将数据转发到服务端。Transfer模块接收到Falcon-agent的数据以后，对数据进行过滤梳理以后通过一致性Hash算法发送到Judge告警判定模块和Graph数据存储归档模块。Heartbeat server（心跳服务）简称HBS，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS，主要包括主机名、主机IP、Agent版本和插件版本，Agent还会从HBS获取需要执行的采集任务和自定义插件。

Open-Falcon具有如下特性：

·强大灵活的数据采集能力：自动发现，支持Falcon-agent、SNMP、用户主动推送、用户自定义插件、OpenTSDB类型的数据模型（timestamp、endpoint、Metric、key-value tags）。

·水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询。

·高效率的告警策略管理：支持高效的portal、策略模板、模板继承和覆盖、多种告警方式、callback调用。

·人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、维护周期。

·高效率的Graph组件：单机支撑200万指标的上报、归档、存储（周期为1分钟）。

·高效的历史数据query组件：采用RRDTool的数据归档策略，秒级返回关于上百个指标一年的历史数据。

·Dashboard：多维度的数据展示，用户可自定义Screen。

·高可用：整个系统无核心单点，易运维，易部署，可水平扩展。

·开发语言：整个系统的后端全部用Golang编写，portal和Dashboard则用Python编写。

5.ZMon

如果公司规模较小，不需要Prometheus这种级别的监控系统，那么可以考虑使用荷兰电商Zalanado公司开源的ZMon^[11]这款天然的分布式监控及告警系统。ZMon和Prometheus一样，都采用拉模式，但需要在监控的目标上安装Check^[12]来抓取指标信息，这些Check都分布在一个个Python编写的Worker上，其可对目标和站点进行Check操作（类似于Prometheus中的Exporter的概念）。Worker采集到的数据在ZMon中采用KairosDB进行存储，KairosDB底层使用的是Cassandra进行存储。KairosDB支持Grafana集成、一般的计算函数、Tag级指标支持、Roll-up预聚合，适用于中大规模DevOps团队自治的场景。从左到右看图1-14所示的架构，ZMon更像是一个任务队列分发的分布式系统，图左侧的用户端生成一些Check和Alert的任务，通过队列分发给图右侧后端可以无限扩展的Worker，这些Worker执行程序检查目标，将告警和数据传递给用户端和存储层KairosDB。

图1-14　ZMon Core+UI+KairosDB Architecture

ZMon具有如下特性：

·支持自定义Check和Alert，团队之间可以共享Check，通过继承重用Alert并定制告警级别。

·支持Dashboard和Grafana。可以根据团队和Tags定义带有小部件和告警过滤器的自定义仪表盘。由于是KairosDB存储，可以直接使用Grafana从KairosDB数据源中绘制数据仪表盘。

·支持Python表达式。Check和Alert都是任意的Python表达式，提供了很大的灵活性和强大的功能。Python可以在平台部署中将很多底层任务和系统完美集成。

·支持推送通知：支持推送技术订阅来实现自告警，可以向电脑桌面和手机发送提醒。

·支持Rest API监控。收集应用程序的API指标之后，ZMon的云UI可以帮助用户直观地了解服务中正在发生的事情，可以呈现出不同的API路径以及相关指标。

·支持对每个实体的告警进行概述。ZMon可以提供告警的全局视野以及每个实体的具体信息，每个实体也可以通过搜索的形式，显示映射到这些实体的所有告警及其当前状态。

·支持试运行和即时评估。比如可以在UI页面始终执行Check和Alert，以试运行的形式快速获取反馈结果。

[1] Nagios官网：https://www.nagios.org/。

[2] 为了正确使用Nagios，你不仅需要Nagios，还需要四五个社区的插件（如check_mk、HighCharts、OMD、NRPE、NSCA、ndoutils、thruk、nagvis），以及其他完整的项目（如Puppet），以便管理配置。当然，还需要管理数千个自定义脚本行。

[3] Nagios有一个巨大的库，但是它的维护成本很低，因为所有插件都是100％开源的，而且没有一家公司来支持或维护它们，分支众多。

[4] Zabbix官网：https://www.zabbix.com/。

[5] Zabbix.orgWiki主页：https://zabbix.org/wiki/Main_Page。

[6] 单播：Gmond收集到的监控数据发送到特定的一台或几台机器上，且可以跨网段发送。

[7] 多播：Gmond收集到的监控数据发送到同一网段内所有的机器上，同时收集同一网段内的所有机器发送过来的监控数据。

[8] 官网：http://ganglia.info/。

[9] 官网：http://open-falcon.org。

[10] 官方文档：https://book.open-falcon.org/zh_0_2/。

[11] ZMon：https://opensource.zalando.com/zmon。

[12] Check：ZMon中对自定义实体执行的Check，和ZMon中的Alert一样都是基于Python脚本写的，其相对于Prometheus的PromQL门槛更高，但更灵活和强大。更多资料参考https://docs.zmon.io/en/latest/user/check-commands.html。