Zabbix 监控介绍

1、功能概述

通常所说的监控，会模糊地包含以上下个细分领域的内容：

• 应用性能监控（Application Performance Monitoring）
• 业务交易监控（Business Transaction Monitoring）
• 网络性能监控（Network Monitoring）
• 操作系统监控（System Monitoring）
• 网络站点监控（Website Monitoring）

在任何一个 IT 业务环境中，都会存在各种各样的硬件设备、软件应用等。按照逻辑层次划分，我们可以将其划分

为了及时掌控基础环境和业务应用系统的可用性，需要获取各个组件的运行状态，如 CPU 的利用率、系统的负载、服务的运行、端口的连通、带宽流量、网站访问状态码等信息，而这一切都离不开监控系统的支撑。

2、实现原理

模块组成

一个监控系统的组成大体可以分为两部分：数据采集部分（客户端，Agent）和数据存储分析告警展示部分（服务器端，Server）

采集协议

按照支持的协议方式，监控系统数据采集可以分为两种：专用客户端采集和公用协议采集（SNMP、IPMI、SSH、Telnet等）。

采集模式

监控系统数据采集的工作模式可以分为被动模式（从服务器端到客户端采集数据，pull）和主动模式（客户端主动上报数据到服务器端，push）两种。通常，大多数监控系统都应该能同时支持这两种工作模式，但不同的监控系统由于采集技术不同，仅有部分能够同时支持这两种工作模式。

• 一般来说，被动模式对监控控制端服务器的开销较大，适合小规模的监控环境；
• 主动模式对监控控制端服务器的开销较小，适合大规模的监控环境。

监控指标

监控系统通常都支持一些常见的监控采集指标，如操作系统监控、应用程序监控等。部分常见的监控指标如下：

代理架构

对于大规模的监控环境，被监控节点多且监控类型多，监控产生的数据和网络连接开销非常大，数据采集方式除了使用主动采集模式，还需要使用代理架构，通过代理架构分摊服务器端的性能开销。另外，代理架构还支持跨地域、跨网络的分布式监控。常见的代理架构，即C/P/S（Client/Proxy/Server，客户端/代理端/服务器端，此处的 Client和 Agent意思等同，都表示客户端，下同）架构。采用中间代理将大大提高监控服务器端的处理速度，从而支撑构建大型分布式监控环境，从架构上支持异地多机房的需求。

对于小型的监控环境，被监控节点不多且处于同一地域或网络环境下，监控系统所需采集的监控数据量较少，采用 C/S（Client/Server，客户端/服务器端）架构即可满足监控业务需求。

数据存储

在监控客户端采集数据之后，会将数据上传给监控服务器端，监控服务器端程序将接收到的数据进行存储。通常监控系统会选用以下几种数据存储方式。

（1）本地存储。使用本地磁盘，基于文件的方式存储。

（2）使用时序数据库进行数据存储，如古老的环状数据库（Round Robin Database, RRD）等。近年来，随着时序数据技术的不断发展，出现了比较成熟的时序数据库，如 OpenTSDB （底层存储基于HBase）、Graphite、InfluxDB、Prometheus 等，与直接使用文件的存储方式相比，这些时序数据库更加高效。目前时序数据库领域相关技术的发展速度较快，应用的生态也逐步完善，基于时序数据库的监控系统会逐渐增多。从长远角度来看，使用时序数据库存储监控数据，是必然的发展趋势。

（3）使用数据库管理系统（Database Management System, DBMS）进行数据存储，如常见的MySQL、Oracle、SQL Server 等。使用这种数据库来存储监控数据，当数据量达到一定规模时，其读/写效率均会显著下降，数据库的压力比较大，通常优化方案思路有3种，一是减少数据的存储量；二是优化数据库本身，调整配置参数，优化运行环境；三是使用分布式数据库和数据库集群技术方案。故使用 DBMS 作为数据存储的监控系统，对数据库本身的掌握程度决定了监控系统能否在大规模环境下良好工作。

（4）使用 NoSQL数据库进行数据存储。NoSQL相对于 DBMS这种传统的数据库有着一些天然的优势，单机的QPS通常较高。但NoSQL本身并不是为监控系统设计的，在数据结构存储方面存在一些缺陷，故直接采用NoSQL作为监控数据存储的监控系统产品较少。

（5）使用列存储数据库进行数据存储。列存储数据库由于其设计之初专为大数据而有所考虑，故无须担心其存储容量，底层均有良好的解决方案。但由于其部署、运维均较为复杂，故一般监控系统也不会常采用这种技术作为数据库存储。这方面的数据库代表为HBase。

（6）使用全文搜索引擎数据库进行监控数据存储。这方面的代表是Elasticsearch，其作为监控数据库存储监控数据具有天然的优势，支持集群、分布式部署、容灾，并且集群能够提供较高的性能。目前采用全文搜索引擎数据库进行监控数据存储，典型的代表是 ELK 套件，而Zabbix监控系统也在这方面进行了尝试，在Zabbix 4.0中可以选用Elasticsearch作为数据库存储。

以上我们看到在不同的场合下监控系统对数据的存储要求会不同，因此，有些监控系统产品直接将数据库存储的选项交给了使用者来决定，会同时支持多种方式的数据库存储。

告警功能

监控系统的重要功能是根据设定的阈值进行告警，同时也要求在发生故障时有一定的故障自动化处理功能，对于特殊的告警还需要具备告警的升级功能，将不同级别的告警分成不同的梯度发送给不同的告警接收人。

虽然监控系统的重要功能是告警，但过多地发送告警，对于监控系统的使用效果来说，反而会不理想。因为人的精力是有限的，不可能随时随地等待着故障发生而立即处理故障，当告警过多时，我们需要优化监控系统。

在触发和发送告警时，告警模块需要支持故障的有效汇报和集中汇报，尽量避免出现“告警风暴”，防止同一时间大量发送重复、类似的告警，即告警功能支持对告警内容进行分析和自动处理，防止误报、漏报及抖动。对于大多数监控系统来说，这一点都是一个值得挑战和研究的课题。举一个实际的例子，当机房网络发生故障时，按照常规，用户会收到无数条告警信息，内容是每台设备的故障。但如果将告警聚合，我们希望收到的信息是“某机房存在网络故障，受影响的设备IP地址是X.X.X.X，受影响的业务是XXX”。

事后还需要对告警信息进行统计分析，以方便对系统的运行情况进行分析统计，从而衡量系统的稳定性、可用性。通常使用SLA服务质量指标来衡量。

可扩展性

可扩展性是指监控系统本身具备良好的扩展能力，包括监控方式的扩展、监控能力的扩展、监控数据存储的扩展、分布式的支持等。要求监控系统能够随着不同环境而做出改变和调整，大多数监控系统都具备一定的扩展能力。

对于告警，要求支持多种方式，如短信、邮件、即时通信和其他接口，且具备可定制化能力，可以对第三方告警介质提供可编程接口。这一点在很多场合都非常重要，例如，将告警结果发送到专用的告警分析系统。

监控系统需要根据实际应用的需求，实时/非实时地采集和展示数据。另外，还包括历史趋势数据的展示和分析，以及容量报表、可用性报告的生成。

---

在一个监控系统中，构成要素为监控服务器端程序、数据存储、被采集节点等相关模块，其告警分析和自动故障处理功能由服务器端执行。在数据采集完成之后，需要对采集到的数据进行分析和处理，判断是否有异常、是否符合告警条件。那么如何配置告警条件呢？通常是根据实际的经验值、业务需求来设置告警阈值的。当达到告警条件时，则发送告警信息给管理人员。然而，对于有些故障，我们希望程序能自动处理，减少人工干预，让程序自动修复，只在出现严重故障、程序无法判断时，才发送告警通知管理人员处理。

一个监控系统往往需要集成资产管理系统，资产管理功能可以从逻辑上展示业务用途的信息，通过对其进行数据分析，做到对投资与回报的反馈展示，为资产的合理规划与使用提供依据。

从工作模式来看，监控系统的数据采集可以分为两种：主动监控和被动监控。一个理想的监控系统采集端支持的采集方式越多，其扩展能力越强大，适用的环境场合越多。

监控系统需要具有对外提供API的能力，方便第三方应用系统对监控数据进行操作管理。通常能对外提供 API 功能的软件，意味着其扩展能力更强大，因而会更加受到用户的喜爱。API的方式一般可以分为 RESTful、SOAP等，在 API中使用的数据类型可以为 JSON、XML等。从目前的趋势来看，RESTful已经成为绝大多数API首选的方式。

监控系统需要对故障数据进行分析汇总，从故障数据中分析出现的概率，进而可以积累数据经验，避免以后出现类似的问题。例如，通过分析统计机器硬件导致故障的概率有多大、哪些部件最容易出问题、出问题的影响概率有多大、立即解决问题的概率有多大等问题，在此基础上进行分析汇总，就可以整理出有效的相应故障对策和技术应急方案。

3、开源产品

在监控软件中，开源的解决方案有：

• 流量监控（MRTG、Cacti、SmokePing 等）、
• 性能告警（Nagios、Zabbix、Zenoss Core、Ganglia、Netdata 等）、
• 基于时序数据库存储数据的监控（Graphite、OpenTSDB、InfluxDB、Prometheus、OpenFalcon 等）、
• 基于全文搜索引擎数据库存储数据的监控（如 ELK 套件）可供选择。

上述各监控产品都有自己的特点和功能，其侧重点和目标不完全相同，在设计理念和实现方法上也各有差异，但都具有一些共同特征，例如采集数据、分析展示、告警以及简单的故障自动处理等，最终都能达到对 IT 系统服务可用性的完全展示。需要说明的是，当前的时序数据库侧重于监控数据的存储，其采集需要借助其他工具来实现。时序监控产品的设计理念较为先进，具有很多创新功能，随着其不断发展，将会极大地促进监控领域技术的发展。

Cacti

Cacti官方网站地址：https://www.cacti.net/。

Cacti（仙人掌）是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。其数据采集仅支持SNMP方式，通过snmpget命令来获取监控数据，使用RRDtool命令工具存储历史数据和绘图，并提供数据和用户管理功能，可以根据用户权限查看不同的树状结构、主机设备以及指定的监控数据图，支持与LDAP结合进行用户认证，同时也能自定义模板。对于网络设备的监控，其展示效果非常不错，在10年前，它是广受网络管理员喜欢的监控产品。

Nagios

Nagios官方网站地址：Nagios Open Source | Nagios Open Source。

Nagios是一个插件式的监控系统，可以监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机参数以及服务，同时提供异常告警通知功能等。

Nagios对开源监控系统的影响非常深远，曾经风靡一时，占据开源监控市场的大部分份额，并基于Nagios 产生了很多新的监控产品。近年来，随着其他开源监控软件的崛起，Nagios 逐渐淡出了历史舞台，使用的人群相对减少，但目前仍有一些公司在使用。

Nagios支持客户端的数据采集，通过编写客户端插件，可以获取各种监控数据，并提供了Web管理界面进行数据查询。其产品的主要功能侧重于监控服务的可用性，根据设置的阈值进行告警，但大部分告警逻辑都是通过监控插件实现的。

InfluxDB套件

InfluxDB官方网站地址：InfluxDB Times Series Data Platform | InfluxData。

InfluxDB 并不是一个监控产品，而是一个开源的分布式时序、时间和指标数据库，使用Go 语言开发。其功能是数据指标的存储，不提供告警分析功能和数据采集功能，仅仅是一个数据库，支持 SQL语言查询，其语法和 MySQL类似。随着 InfluxDB时序数据库的功能不断完善，官方也推出了作为监控系统使用的相关套件，分别是 Telegraf（采集数据的客户端）、InfluxDB（存储监控数据）、Kapacitor（告警分析）、Chronograf（监控数据可视化。

Prometheus

Prometheus官方网站地址：Prometheus - Monitoring system & time series database。

Prometheus 是一套开源的系统监控报警框架。Prometheus最初的设计理念受 Google的 Borgmon监控系统所启发，由工作在 SoundCloud的 Google前员工于2012年创建，作为社区开源项目进行开发，2015年正式发布。2016年，Prometheus正式加入Cloud Native ComputingFoundation（CNCF）组织，2018年其成为继Kubernetes从CNCF毕业的第二个项目，其受欢迎程度仅次于Kubernetes。

Prometheus产品得到迅速发展，离不开天时、地利、人和，在2015年前后，微服务概念开始流行，软件架构从单体应用转换为微服务，此时，能够原生支持对容器 Docker、Kubernetes监控的产品会被使用微服务的公司首先接受，而同期的其他监控产品均不直接提供对微服务的监控，故其在微服务领域取得先机。另外，该产品本身的设计较为合理，提供了灵活而强大的查询语句（PromQL）、灵活的告警策略，易于管理，方便扩展，其数据采集使用私有客户端，传输协议使用 HTTP，数据存储使用私有数据库。

OpenFalcon

OpenFalcon官方网站地址：https://book.open-falcon.org/。

OpenFalcon 是一个企业级、高可用、可扩展的开源监控解决方案。OpenFalcon由多个组件构成，重要的组件有数据采集、数据传输、数据存储、告警分析、图形展示等，数据采集使用专用客户端，传输协议为私有的，数据存储支持 OpenTSDB 和RRD两种方式。

Netdata

Netdata官方网站地址：GitHub - netdata/netdata: Monitor your servers, containers, and applications, in high-resolution and in real-time!。

Netdata是 Linux系统实时性能监测工具，以 Web可视化方式展示系统及应用程序的实时运行状态（包括CPU、内存、硬盘输入/输出、网络等Linux性能数据）。

Netdata 数据采集为私有客户端，数据存储为私有格式，也支持多种时间序列后端服务，比如Graphite、OpenTSDB、Prometheus、JSON document DBs，并支持告警功能，在单机监控系统中具有其他监控系统所不具备的优势。其监控界面较为美观。

ELK家族

ELK官方网站地址：Elasticsearch Platform — Find real-time answers at scale | Elastic。

ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件，但并非全部。

Elasticsearch 是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能，是一套开放 REST 和Java API 等结构，提供高效搜索功能，并可扩展的分布式系统。它构建在Apache Lucene搜索引擎库上。

Logstash 是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（如RabbitMQ）和 JMX。它能够以多种方式输出数据，包括电子邮件、WebSocket和Elasticsearch。

Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储 Elasticsearch 指标中的日志数据。它利用 Elasticsearch的 REST接口来检索数据，不仅允许用户创建自己数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。

实际上，随着ELK家族的不断发展，其针对日志采集开发了专用的客户端Beats系列产品，包括Filebeat（日志文件）、Metricbeat（指标）、Packetbeat（网络数据）、Winlogbeat（Windows事件日志）、Auditbeat（审计数据）、Heartbeat（运行时间监控）。

Zabbix

Zabbix是企业级分布式监控系统，是一个开箱即用的成熟解决方案，具备完备的功能。综合其他监控产品来说，它是一个大而全、功能丰富且定制非常灵活的产品，具备其他监控产品的功能，同时提供了其他监控产品所不具备的功能，扩展非常灵活，是企业级监控系统比较合理的选择之一。

从功能上说，Zabbix 支持多种采集方式和采集客户端，有专用的 Agent（代理），也支持SNMP、IPMI、JMX、Telnet、SSH 等多种协议，它将采集到的数据存放到数据库中，可以支持 MySQL、Oracle、PostgreSQL、SQLite、Elasticsearch 等数据库，然后对其进行分析整理，达到条件触发告警，并支持对告警数据的分析统计。Zabbix 具有良好的管理界面。

从以上各种监控系统产品的对比来看，Zabbix都是具有优势的，其具有丰富的基本功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。