监控之美——监控之美-监控系统选型分析及误区探讨

朱政科

读完需要

29

分钟

速读仅需 10 分钟

本文摘自于朱政科撰写的《Prometheus 云原生监控：运维与开发实战》，重点介绍了在监控系统选型中应该考虑的问题。

上一期监控之美——Prometheus云原生监控介绍了云原生监控的原理，
在本文中，你将会了解监控应用程序的黑盒和白盒方法，也会了解监控执行检查的拉取和推送方式，还会了解常见的监控系统以及进行监控系统选型时应该注意的问题。

1

   

黑盒监控和白盒监控

《SRE: Google 运维解密》一书中指出，监控系统需要有效支持白盒监控和黑盒监控；还有一种类似的观点认为，监控系统必须支持探针（Probing）和内省（Introspection）。

黑盒监控，对应探针的概念，常见的有 HTTP 探针、TCP 探针等，可以在系统或者服务发生故障时快速通知相关人员进行处理。探针位于应用程序的外部，通过监听端口是否有响应且返回正确的数据或状态码等外部特征来监控应用程序。Nagios 就是一个主要基于黑盒/探针的监控系统。

白盒监控，对应内省的概念，通过白盒能够了解监控对象内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。白盒监控可以直接将事件、日志和指标发送到监控工具，它具有比黑盒监控更丰富的应用程序上下文信息。MDD 理念主要对应的就是基于白盒的监控系统。

2

   

监控检查的两种模式—拉取和推送

监控系统执行监控检查的模式主要有拉取（Pull）和推送（Push）两种。这两种模式究竟哪种更好？对此，监控领域内部存在相当大的争议。

拉取模式（简称拉模式），是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值，由于有拉取间隔，因此并不能准确获取数值状态的变化，只能看到拉取间隔内的变化，因此可能会产生一些毛刺现象，需要进一步进行数据处理。监控和性能测试更关注 p95/p99 位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的，这部分内容我们会在后续章节详细介绍。

拉模式的优点是告警可以按照策略分片，告警模块只需要拉取自己需要的数据，且可以完美支持聚合场景；拉模式的缺点在于监控数据体量非常庞大，对存储有较高的要求，实战中可能还需要考虑数据的冷热分离。

推送模式（简称推模式），是应用程序基于事件主动将数据推向监控系统的方式。推模式的优点是实时性好，一旦触发一个事件就可以立刻收集发送信息。但是推模式的缺点也很明显，由于事件的不可预知性，大量的数据推送到监控系统，解析和暂存会消耗大量的内存，这可能对监控的进程产生影响。由于消息是推送过来的，所以主动权在推送方。在这种模式下，由于网络等迟迟没有得到确认，所以在 ack 等情况下很容易造成数据重复。这是因为推模式在进行推送中，如果发送失败，为了防止内存撑爆，系统会将数据持久化到文件或者队列。因此采用推模式时，若产生了重复数据，就需要进行去重等操作，对于这些技术细节，需要仔细打磨。

Prometheus 在收集数据时，主要采用拉模式（服务端主动去客户端拉取数据），当然它也支持接收推送到 Pushgateway 的事件；而以 Zabbix 为代表的传统监控系统采用推模式（客户端发送数据给服务端）。

拉模式在云原生环境中有比较大的优势，原因是在分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成对所有要监控节点的服务发现，此时直接去拉取需要的数据就好了；

推模式虽然可以省去服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这无形中加大了部署的难度。推模式在 OpenStack 和 Kubernetes 等环境中使用比较少。

3

   

5 种常见的监控系统

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

3.1

   

Nagios

Nagios 原名 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。

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 依次读取队列中的信息，再把结果显示出来。

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

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

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

3.2

   

Zabbix

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

Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，和 Nagios 一样提供集中的 Web 管理界面。Zabbix 有着非常酷炫的新版官网和详细的文档使用手册，企业级的 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 的服务端并