《Zabbix企业级分布式监控系统第2版》正式发布

 吴兆松 资深系统工程师，Zabbix监控系统“红宝书”做者，熟悉IT运维领域，对服务器运维、应用运维以及运维（DevOps）平台的构思、设计、开发等都具备十分丰富的经验，尤为擅长IT监控系统的运维和开发，是国内最先一批使用和研究Zabbix的用户，为几十个大型企业构建过Zabbix监控平台体系。从业经历至关丰富，对运维、编程、产品都有深刻的实践，被业内人士戏称为“监控专家”。

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

监控，从中文的字义来看，有两个内容，一是监测，二是控制，重点在第一个字眼“监”上，即监测、预防的意思。监控，对应的英文单词是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运维管理中，平常的工做能够分为三类：一是基础环境搭建；二是维护与更新；三是监控告警与调整优化。在维护与更新的工做中，能够采用手动或自动化工具来实现，都可以知足不一样企业的需求。对于配置统1、基础环境一致的环境，一般会采用统一的配置管理工具，如Puppet、SaltStack、Ansible、Chef等。而有些环境，配置变动不频繁，其无法统一管理，如一年半载可能才发生一次变动，而相同规模的设备很少，在这种状况下，配置管理工具就没法发挥它的优点了。可是对于监控告警系统，不管是互联网公司仍是传统公司，都是必不可少的，由于IT设备并非100%可靠的，就算是100%可靠的设备，也会有人为因素形成服务不可用。所以，集中的监控告警平台建设，是每一个公司IT部门都十分关心的问题，即便是不懂IT技术的公司成员，也知道监控告警系统是必需的。

在了解了IT监控系统的重要性后，咱们来看看具体的监控需求。通常来讲，监控系统的构建能够分为以下几个层面。

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

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

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

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

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

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

在监控系统的构建过程当中，监控系统并非孤立存在的，它每每须要与其余系统打通，造成闭环，让工做的各个环节进行流通。所以，企业在创建监控系统的过程当中，每每是按照标准产品，加上个性化定制来实现的。

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

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

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

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

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

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

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

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

监控系统项目步骤

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

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

3.项目规划蓝图——按部就班：在肯定目标后，须要对整个系统进行详细规划，能够对目标进行一个明确的规划，好比何时取得什么样的成绩，交付什么样的功能，最终创建一个什么样的监控系统。

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

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

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

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

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

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