本文主要阐述监控系统的发展历程、监控系统的原理，以及监控系统的项目实践，目的是让大家全面了解监控系统。

监控，从中文的字义来看，有两个内容，一是监测，二是控制，重点在第一个字眼“监”上，即监测、预防的意思。监控，对应的英文单词是Monitoring。按照维基百科对于Monitoring的分类，在计算机领域，可以将其分为应用性能监控、业务交易监控、网络性能监控、操作系统监控、网络站点监控5种。上面5种类型将“监控”这个大概念划分成多个领域。我们通常所说的监控，会模糊地包含以上5个细分领域的内容。在任何一个IT业务环境中，都会存在各种各样的硬件设备、软件应用等。按照逻辑层次划分，我们可以将其划分为如图1所示的模型。

图1 IT业务架构环境逻辑层次模型

多种应用构成了复杂的IT业务系统，如何保证这些资源正常运转，是各公司内IT部门的重要职责。要让这些应用能够稳定地运行，则需要专业的IT人员进行规划、设计、架构、维护和调优。在这个过程中，为了及时掌控基础环境和业务应用系统的可用性，需要获取各个组件的运行状态，如CPU的利用率、系统的负载、服务的运行、端口的连通、带宽流量、网站访问状态码等信息，而这一切都离不开监控系统的支撑。

模块组成

一个监控系统的组成大体可以分为两部分：数据采集部分（客户端，Agent）和数据存储分析告警展示部分（服务器端，Server），如图2所示。这两部分构成了监控系统的基本模型。

图2 监控系统的基本模型

采集协议

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

图3 监控系统数据采集协议分类

采集模式

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

图4 监控系统数据采集的工作模式

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

监控指标

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

表1 部分常见的监控指标

代理架构

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

图5 监控系统的代理架构

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

数据存储

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

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

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

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

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

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

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

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

告警功能

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

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

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

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

可扩展性

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

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

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

总结归纳

以上我们共同学习了监控系统的组成、监控架构的设计、监控指标的采集、监控数据的存储、监控告警的发送和分析，并探讨了监控系统的可扩展性。通过对这些方面的探讨，我们对监控有了一个全面的认识。

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

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

图6 监控系统与资产管理系统的集成

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

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

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

监控系统项目概述

在大型的IT架构环境中，IT系统的组成部分通常是跨区域分布在多个省市的；跨节点，多IDC，网络线路分为电信、联通、移动等；业务类型众多、系统构成复杂、业务需求多样，是这种大型环境的特点。在互联网业务中，新旧替代的速度是非常迅速的，因此，监控系统要能满足业务不断变化的需求。

在这种环境中构建监控系统，首先要做的事情是掌握全局信息，以及需要考虑业务未来的发展趋势。接下来是选择合适的技术方案，通常，这个技术方案既要能满足于当前业务需要，又要能满足于不断增长的业务需求，所以进行合理的规划和预测，加上一定的理论和实践经验，才能设计出一套比较完美的解决方案。

在大规模的监控系统中，需要考虑以下因素。

1.分布式架构是首要考虑因素。要求系统架构具备分布式的设计，原则是将中心节点压力分散在各边缘节点上，使其尽可能监控更多的设备。

2.数据存储扩展的问题。节点数量增加到一定规模后，给监控数据的存储带来了十分严峻的挑战，数据存储扩展的问题是整个监控系统能否正常工作的前提条件。

3.高可用性和健壮性、稳定可靠的系统架构、冗余的灾备，是大型监控系统必备条件。

4.提供API的能力，易于与第三方集成。在大型环境中，一个孤立的监控系统会给其他业务系统造成很大的麻烦，通常需要花费更多的精力进行改造，使其为其他系统提供所需的数据。

5.具备自动化功能。自动化是解放繁重的体力劳动最有效的方式，未来的运维一定更智能、更偏向于业务，以业务为核心，而不是仅仅解决系统的底层问题。

以上观点适用于任何监控系统，而不仅仅是Zabbix。

监控系统项目背景

在企业的生命历程中，在不同阶段突显的矛盾均有不同体现。在初始阶段，以业务的原型实现为主；在发展阶段，以满足业务增长需求为主；在稳定阶段，以优化业务成本和发展为主。而技术在不同阶段所具有的作用也是不同的，以业务为驱动的公司，技术通常起辅助支撑作用；以技术为命脉的公司，技术为其核心资源；以互联网为代表的公司，往往是技术和业务协调发展，以满足企业的成长发展需要，对技术从业人员的要求非常高，通常技术更新换代速度较快，要求技术人员能够根据不同的业务，采用不同的技术方案；以传统业务为代表的公司，往往是业务发展在前，技术落地在后，其技术决策周期往往较长，管理者以求稳定大局为主，故大多数技术人员都比较保守，不会轻易采用较新的技术。在明白这个前提下，针对自己所在公司的特点，对于监控系统的构建往往会考虑得更全面。

在IT运维管理中，日常的工作可以分为三类：一是基础环境搭建；二是维护与更新；三是监控告警与调整优化。在维护与更新的工作中，可以采用手动或自动化工具来实现，均可以满足不同企业的需求。对于配置统一、基础环境一致的环境，通常会采用统一的配置管理工具，如Puppet、SaltStack、Ansible、Chef等。而有些环境，配置变更不频繁，其没法统一管理，如一年半载可能才发生一次变更，而相同规模的设备不多，在这种情况下，配置管理工具就无法发挥它的优势了。但是对于监控告警系统，无论是互联网公司还是传统公司，都是必不可少的，因为IT设备并不是100%可靠的，就算是100%可靠的设备，也会有人为因素造成服务不可用。因此，集中的监控告警平台建设，是每个公司IT部门都十分关心的问题，即使是不懂IT技术的公司成员，也知道监控告警系统是必需的。

在了解了IT监控系统的重要性后，我们来看看具体的监控需求。一般来说，监控系统的构建可以分为如下几个层面。

基础架构设施的监控，包括硬件服务器、存储、网络、虚拟化等。

应用存活与基本性能的监控，包括数据库、Web应用、中间件、消息队列、缓存等。

代码内部的工作状态监控，这属于监控的细分领域，需要采用其他技术来实现，如采用开源的PinPoint、Zipkin、CAT、OpenTraceing等APM监控工具，这种层面的监控，需要软件工程师在编写业务代码时，采用业务监控指标的埋点，进行整个业务调用链的监控，一般需要软件架构师来规划设计，项目的整体推动实现过程通常较难。

日志流监控，监控应用设备和应用软件的日志，并从日志中提取相关的指标进行分析，其实现方式有开源的套件ELK等。

在Zabbix能够支持的监控范围中，上面提到的部分功能被支持。所以，在构建监控系统之前，必须明白监控的具体需求范围，以免范围扩大，从而造成需求蔓延和监控系统使用效果满意度的下降。

在通常意义的监控建设项目中，一般的需求有：建立基于网络、存储、虚拟化、应用、数据库系统、缓存、消息队列等的监控预警体系，设备和服务的宕机、恢复均需要实时反馈给运维团队。监控目标触发预警后可以设置重复的轮询作业确认问题是否存在。设置合理的预警级别，根据预警的重要程度、紧急程度、问题处理程度，预警反馈给不同级别的人员。

在监控系统的构建过程中，监控系统并不是孤立存在的，它往往需要与其他系统打通，形成闭环，让工作的各个环节进行流通。因此，企业在建立监控系统的过程中，往往是按照标准产品，加上个性化定制来实现的。

在IT运维管理框架中，往往从逻辑结构上划分为五个平台和一个中心配置库（简称“五台一库”），分别是集中监控平台、流程管理平台、数据展现平台、自动化操作平台、历史数据分析平台和配置管理数据库（CMDB）。它们的功能如下。

监控平台：构建整个IT监控架构，实现集中事件管理，并为面向业务的监控管理打下基础。

流程管理平台：整合并标准化运维的日常工作，将日常的工作规范化，并透明化。

数据展现平台：建设统一报表平台和统一门户平台，将有效增强数据利用和展示效果。

自动化操作平台：完成对整个IT操作的集中管控和自动化。

历史数据分析平台：集中存放历史数据，提供后期统一分析及规划。

配置管理数据库：记录完整的、准确的IT环境中各组件的信息和彼此间的关联关系，作为唯一、可信的数据源，为周边系统提供支撑数据。

因此，在这种背景环境下，我们需要重新审视企业中的IT监控系统项目。无论是高速发展的互联网企业，还是平稳发展的传统企业，抑或是金融保险企业，其构建监控系统的目的都一样，都是通过监控系统发现故障与问题，并及时通知相关负责人，一线工程师能够根据故障报告快速处理，并对处理的过程和结果进行整理分析，形成知识积累，对于可以预见的常规故障，制定出应急方案。

监控系统项目步骤

1.梳理现有环境——知己知彼：在接手监控系统构建项目之前，需要梳理现有的环境，从基础设施、应用系统、日志分析、应用性能等多个维度进行分析。

2.确定监控目标——愿景宏大：确定监控系统的目标，是监控网络设备、服务器还是应用，以便采取相应的策略。

3.项目规划蓝图——循序渐进：在确定目标后，需要对整个系统进行详细规划，可以对目标进行一个明确的规划，比如什么时候取得什么样的成绩，交付什么样的功能，最终建立一个什么样的监控系统。

4.功能逐步深入——精益求精：采用精益的思维模式，先从小的功能做起，解决当前环境中的主要矛盾，然后逐步扩大环境，从本团队做起，再推广到其他团队，最后推广至全公司。

5.吸取百家之长——资源整合：与其他系统进行整合，比如与CMDB整合、与ITSM服务流程整合、与自动化运维工具整合、与代码发布整合。

6.不断总结成长——取长补短：通过对环境的不断验证，总结过去的经验，不断简化整个监控流程，并定制出符合实际需求的监控功能。

本文节选自新版Zabbix红宝书《Zabbix企业级分布式监控系统（第2版）》，采用最新稳定版本Zabbix 4.0并配备大量真实监控案例，是升级版的最大亮点。

本书基于最新稳定版本Zabbix 4.0，对Zabbix的各项功能进行了详细而深入的讲解，让读者真正通过一本书就能够完全掌握Zabbix监控系统的核心技术。

本书第1版内容收获了大量读者好评，是一本实战性很强的工具书，读者将其称为监控领域的“红宝书”，书中所写内容均可以在生产环境中直接应用。而在第2版中，采纳了以往读者的宝贵意见，增加了作者的最新研究成果，扩充了大量内容，但继续保持由浅入深、由易到难的写作风格。