Zabbix企业级分布式监控系统(第2版)(txt+pdf+epub+mobi电子书下载)

作者：吴兆松

出版社：电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Zabbix企业级分布式监控系统(第2版)试读：

前言

笔者在自己的运维从业生涯中用过的监控系统有Cacti、Nagios等，以及笔者公司开发的监控告警系统，直到接触了Zabbix，才发现这个灵活而强大的自动化监控工具正是笔者所寻找的。随着近年来云计算、容器技术的大规模普及，软件架构已经从单体架构走向微服务架构，对监控的灵活性和可靠性的要求越来越高，出现了更多有趣的监控软件，如Prometheus、Influx家族，这些监控软件解决了在当前环境中面临的一些问题，提供了非常优秀的监控解决方案，但这并不妨碍Zabbix的继续流行。从2012年开始，国内Zabbix的用户群体在逐步扩大，当前Zabbix已经成为运维人员必须掌握的技能之一。究其原因，得益于Zabbix灵活的架构设计、极强的扩展能力、丰富的监控能力、易于与外部集成的能力，从硬件监控，到操作系统，再到服务进程，以及网络设备，其无所不能的监控功能令人叹为观止，相信这也是大多数Zabbix爱好者选择它的主要原因。

当然，在Zabbix的使用过程中，会面临上手容易、精通较难的问题，原因在于Zabbix过于灵活，其配置的颗粒度非常细致，这也会让大多数用户刚接触学习它的时候一头雾水，所以查看官方文档和阅读一本相关书籍的学习方式都是明智的选择。

笔者从2012年开始使用Zabbix，曾公开自己的使用文档，很高兴文档对不少初学Zabbix的朋友有所帮助，但随着向笔者咨询问题的人数增多，其中多数问题是重复的，且笔者解答问题的精力有限，于是萌生出书的想法，在其后的2014年，正式出版了《Zabbix企业级分布式监控系统》一书，并被广大Zabbix爱好者喜爱。时光荏苒，2018年，Zabbix 4.0版本正式发布，所以本书也需要升级换代，在此情况下，笔者对书籍内容进行了大幅度的重构，并对书籍的内容和深度进行了扩展，让本书可以真正成为Zabbix用户的案头首选参考书。本书得以改版，我们的编辑付睿老师功不可没，在2016—2017年的时候，她一直催促笔者更新内容。由于笔者当时是被动更新的，并没有想好新加什么内容，并且笔者基于原有书稿做了一些更新，但内容无法令自己满意，于是就没有继续下去，当时Zabbix是3.0版本。直到2018年，笔者觉得是时候更新内容了。如何阅读本书

本书共分3部分内容，笔者按照从零基础开始学习的路线进行章节编排，从易到难逐步深入，直到读者深入掌握，并且本书对相关的内容和思想进行了拓展，让读者学习到的不仅是Zabbix，而且是一个监控体系。

第1部分为基础部分，包括第1～6章。首先介绍监控系统的原理，让初次接触监控的读者了解监控系统的组成部分，从宏观上认识监控系统。接下来讲解了Zabbix的架构、Zabbix的安装、监控配置、自定义监控项、告警配置、告警脚本等功能。这部分内容适合从零基础开始系统地学习Zabbix监控系统，对稍有经验的使用者来说，重点掌握Zabbix对数据存储的处理（第3章），以及第5章和第6章的内容。

第2部分为中级部分，包括第7～11章。首先对Zabbix的触发器使用以及内部源码实现进行了深入讲解，对Zabbix的多种监控方式进行了详述（如IPMI、SNMP、JMX、ODBC等）。接着，对自动化功能进行了深入讲解，介绍了分布式监控系统，配有大量自定义脚本的监控案例，并对监控项自动发现（LLD）功能进行了深入讲解，其后对Zabbix的数据可视化方案和拓展实现进行了研究，适合对Zabbix有一定基础的读者深入学习。通过对这部分内容的学习，读者将会深入理解Zabbix的整体功能。

第3部分为高级部分，包括第12～16章。首先介绍Zabbix的性能调优，从底层实现机制讲解，从而理解Zabbix在使用过程中遇到性能瓶颈的问题，以及如何解决这些问题，并让读者学会使用Zabbix API来扩展Zabbix，从而为构建运维平台提供了更多的扩展性。同时，这部分也讲解了如何定制RPM包，源码构建安装，使用Elasticsearch作为后端数据存储，以及如何使用SaltStack来自动化部署和配置，通过一个实例来讲解如何构建企业级分布式监控系统。最后一章，探讨了监控系统的整体实现与使用场景，与DevOps、ITIL的整合使用，以及告警轮班等深度场景，让读者在更丰富的场景中使用Zabbix，并理解IT运维中的关键思想，将监控用于更广泛的场景，适合对Zabbix非常熟悉的读者进行深入应用。通过对这部分内容的学习，读者能够深入理解Zabbix，并从更多的角度考虑监控问题。配套代码

书中包含的相关代码，笔者已将其放到GitHub上，地址为https://github.com/zabbix-book，读者可以在生产环境中直接使用相关代码。读者对象

· Linux系统管理员

· 运维监控系统工程师

· 系统运维工程师

· 监控系统软件开发（设计）人员

· 运维开发工程师

· IT管理人员

· 系统集成商

· 架构设计人员勘误支持

尽管笔者和编辑都努力地对书稿进行再三校对，但因笔者水平和时间所限，书中可能存在少许的错误或不妥之处，如读者遇到，还恳请批评、指正。读者若有任何宝贵的意见或建议，可以发送邮件至本书的专题邮箱zabbix_v2@itnihao.com，笔者将尽快给予反馈解答。本书的勘误也会在随书项目中得到反馈。内容声明

本书采用的Zabbix为4.0版本，随着Zabbix版本的更新，本书讲解的大部分使用功能与新版本相比会稍有不同。本书采用的操作系统以Linux（CentOS 7）、Windows为主，对于其他版本的操作系统并未做过多讲解。本书能保证对Zabbix几乎96%以上的功能都有细致讲解，但少许笔者认为不重要的内容并未讲解（也许对部分读者来说却非常重要），如涉及加密证书传输数据的内容，关于这部分内容读者可参考学习官方文档。另外，与本书第1版相比，第2版去掉了Zabbix协议的相关章节。本书在编写过程中，参考了大量官方文档和社区的内容，书中都给出了相关链接，如不慎遗漏，重印、改版的时候会进行增补。

本书并不能完全代替Zabbix的官方文档，读者在读完本书后，建议也阅读Zabbix的官方文档，因为在官方文档中还有更多的细节值得去研究，如将两者结合，效果会更好。示例规范（1）在shell环境中使用，shell命令会加粗显示。（2）在MySQL环境中使用，SQL命令会加粗显示。（3）在本书中，Zabbix-Server表示zabbix_server服务或进程，其他Zabbix-Agent、Zabbix-Get、Zabbix-Proxy的情况类似。联系方式

微博：http://weibo.com/itnihao

邮件：zabbix_v2@itnihao.com

第1章 开篇——监控系统简介

本章阐述监控系统的发展历程、监控系统的原理，以及监控系统的实现过程，对现有的开源监控解决方案进行综合分析，目的是让读者全面了解监控系统，更加深入地学习监控系统的原理，为后面章节的学习做好准备。

1.1 监控系统的功能概述

监控，从中文的字义来看，有两个内容，一是监测，二是控制，重点在第一个字眼“监”上，即监测、预防的意思。

监控，对应的英文单词是Monitoring。按照维基百科对于Monitoring的分类（链接地址是https://en.wikipedia.org/wiki/Monitoring），在计算机领域，可以将其分为5种监控类型。

· 应用性能监控（Application Performance Monitoring）。

· 业务交易监控（Business Transaction Monitoring）。

· 网络性能监控（Network Monitoring）。

· 操作系统监控（System Monitoring）。

· 网络站点监控（Website Monitoring）。

上面5种类型将“监控”这个大概念划分成多个领域。我们通常所说的监控，会模糊地包含以上5个细分领域的内容。

在任何一个IT业务环境中，都会存在各种各样的硬件设备、软件应用等。按照逻辑层次划分，我们可以将其划分为如图1-1所示的模型。图1-1 IT业务架构环境逻辑层次模型

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

1.2 监控系统的实现原理

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

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

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

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

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

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

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

在监控客户端采集数据之后，会将数据上传给监控服务器端，监控服务器端程序将接收到的数据进行存储。通常监控系统会选用以下几种数据存储方式。（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作为数据库存储。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 监控系统的开源产品

前面介绍了通用的监控系统实现原理，下面看看已有的开源监控系统解决方案。

在监控软件中，开源的解决方案有流量监控（MRTG、Cacti、SmokePing等）、性能告警（Nagios、Zabbix、Zenoss Core、Ganglia、Netdata等）、基于时序数据库存储数据的监控（Graphite、OpenTSDB、InfluxDB、Prometheus、OpenFalcon等）、基于全文搜索引擎数据库存储数据的监控（如ELK套件）可供选择。上述各监控产品都有自己的特点和功能，其侧重点和目标不完全相同，在设计理念和实现方法上也各有差异，但都具有一些共同特征，例如采集数据、分析展示、告警以及简单的故障自动处理等，最终都能达到对IT系统服务可用性的完全展示。需要说明的是，当前的时序数据库侧重于监控数据的存储，其采集需要借助其他工具来实现。时序监控产品的设计理念较为先进，具有很多创新功能，随着其不断发展，将会极大地促进监控领域技术的发展。下面我们来分别介绍主流的监控开源产品。对于其他商业监控产品，本书不做介绍。1.3.1 Cacti

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

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

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

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

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

Nagios官方网站地址：https://www.nagios.org/。图1-8 Nagios的界面截图1.3.3 InfluxDB套件

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

InfluxDB官方网站地址：https://www.influxdata.com/。图1-9 InfluxDB套件的架构逻辑示意图1.3.4 Prometheus

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

Prometheus官方网站地址：https://prometheus.io。

Prometheus产品得到迅速发展，离不开天时、地利、人和，在2015年前后，微服务概念开始流行，软件架构从单体应用转换为微服务，此时，能够原生支持对容器Docker、Kubernetes监控的产品会被使用微服务的公司首先接受，而同期的其他监控产品均不直接提供对微服务的监控，故其在微服务领域取得先机。另外，该产品本身的设计较为合理，提供了灵活而强大的查询语句（PromQL）、灵活的告警策略，易于管理，方便扩展，其数据采集使用私有客户端，传输协议使用HTTP，数据存储使用私有数据库。更多的介绍，读者可以查看Prometheus官网或者地址：https://www.ibm.com/developerworks/cn/cloud/library/cl-lo-prometheus-getting-started-and-practice/index.html。图1-10 Prometheus架构示意图1.3.5 OpenFalcon

OpenFalcon是一个企业级、高可用、可扩展的开源监控解决方案。它在GitHub上获得了数千个星（star）、数百次复刻（fork）、上百个代码提交（pull-request），社区用户超过6000人，超过200家公司都在不同程度地使用OpenFalcon。

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

OpenFalcon由多个组件构成，重要的组件有数据采集、数据传输、数据存储、告警分析、图形展示等，数据采集使用专用客户端，传输协议为私有的，数据存储支持OpenTSDB和RRD两种方式，其架构示意图如图1-11所示。图1-11 OpenFalcon架构示意图1.3.6 Netdata

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

Netdata官方网站地址：https://github.com/firehol/netdata。

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

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

ELK官方网站地址：https://www.elastic.co/。

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（运行时间监控），如图1-13所示。图1-13 Beats系列软件1.3.8 Zabbix

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

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

Zabbix监控系统也是本书的主题所在，对于其具体功能将在后续章节中详细讲解。

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

第2章 Zabbix简介

本章将对Zabbix的用户群体、开源模式、软件架构、版本选择和功能特性等进行介绍，使读者对Zabbix有一个全面的认识。对于这些内容，读者稍做了解即可，重点是对Zabbix架构的理解。

2.1 Zabbix的用户群体都有谁

在国外，有如图2-1所示的用户在使用Zabbix。图2-1 Zabbix的用户列表（部分）

注意：以上信息，读者可以通过Zabbix网站http://www.zabbix.com/users.php查看到。

在国内，Zabbix非常流行，中小型公司基本都在使用它，如豆瓣、58同城、美团、大众点评、PPTV、搜狐、Letv、人人、网易、小米、360等公司都在不同的发展阶段使用了Zabbix，且其均承担着监控系统中的重要角色。虽然部分公司随着业务和技术的不断发展而选择了自主开发监控系统，但这并不影响Zabbix对其发展历史的贡献，因为任何一个工具均需要在一定场景下使用，脱离了场景，都谈不上很好地使用。

近年来，随着云计算、虚拟化的大规模应用，移动互联网、物联网等技术的逐步普及，加上人工智能、区块链等技术的发展，对IT系统的健壮性和稳定性的要求会越来越高。而随着对IT系统要求的提高，必然需要很好的监控体系建设，Zabbix正是在这种背景下被广泛使用的，其应用场景也在不断地扩展。目前，很多互联网公司、云计算公司、系统集成软件公司、外包服务公司等，都对Zabbix进行了二次开发和大规模使用。

据Zabbix官方提供的资料显示，单个服务器节点可以支持10万台设备的监控，其每秒可以处理5万次请求（NVPS在有历史数据和触发器的情况下为5万次，而在无历史数据和触发器的情况下则可以达到单机30万次）。随着Zabbix版本的迭代，单机的性能正在逐步提高，这对大多数公司业务监控的应用场景已经足够了。

Zabbix自身的定位是中型企业和大型企业，如果在特大型环境中（如图2-2所示的实例，是一个具有10 024台设备规模的Zabbix环境）使用，需要解决大并发、大压力的问题，这对使用者提出了更高的要求。图2-2 在特大型环境中使用Zabbix

2.2 使用Zabbix需要具备什么基础

Zabbix使用起来非常简单，读者稍加学习即可上手。如果你以前从未接触过任何监控系统，从零基础开始学习，也将是一件相对容易的事情。

这里暂且把对Zabbix的掌握程度分成3个阶段。

· 入门阶段：以前从未接触过任何监控系统，也不熟悉Linux操作系统。在这个阶段，能够熟练地掌握Zabbix的安装和基本配置即可。

· 中级阶段：具备Linux基础，熟悉LAMP和LNMP环境搭建、MySQL数据库、Shell脚本，以及具有简单的英文阅读能力，主要难点在于触发器、数据库调优和API的使用。在这个阶段，读者可以将Zabbix与其他系统进行集成对接。

· 高级阶段：熟悉PHP语言或C语言，具备二次开发能力，能够修改源码，可以对Zabbix从代码级别进行优化和扩展。在这个阶段，读者一般都能熟练地掌握Zabbix的各个功能，已经从使用阶段到了源码级别的研究阶段，因此主要是对编程能力的要求。

随着不断的学习和研究，我们的知识水平也会逐步提高，因为在使用Zabbix的过程中，也会学习其背后的知识和原理，这时候就不止是掌握Zabbix了，而是要掌握一套监控体系的知识。因此，通过不断的积累和沉淀，我们就具备了举一反三、触类旁通的能力。所以，学习Zabbix的过程，将会让我们受益。

2.3 Zabbix是一个什么样的产品

Zabbix官方网站信息如下。

· Zabbix官网：http://www.zabbix.com。

· 官方论坛：http://www.zabbix.com/forum/。

· 代码托管平台：http://sourceforge.net/projects/zabbix/files/。

· Wiki：https://www.zabbix.com/wiki。

· Zabbix体验：https://zabbix.org/zabbix/dashboard.php。

Zabbix是一个企业级的高度集成的开源监控软件，提供了分布式监控解决方案，可以用来监控设备、服务等的可用性和性能。其产品不分企业版和社区版，是一个真正的源码开放产品，用户可以自由下载并使用该软件。

Zabbix SIA是Zabbix技术团队的公司载体，其运作模式是商业软件开源，即软件完全开源，供用户免费使用，但若需要官方提供技术服务，则通过收费的商业模式。其提供的服务范围包括咨询、技术支持、定制开发、解决方案、培训认证等，如图2-3所示。其通过这种模式，维持公司的运转和发展。当然，随着其公司的不断发展和时代的进步，也会出现更多的商业模式，如Zabbix将在后续推出云服务，对于其商业模式，这里不再深究。我们只需要知道，Zabbix SIA公司有稳定的收入来源，因此不用担心其核心团队流失而造成更新无法保障。图2-3 Zabbix SIA公司的服务目录

2.4 为何选择Zabbix作为监控系统

对比同类监控产品，有以下理由选择使用Zabbix。（1）Zabbix是一个自由开放源码的产品，用户可以对源码进行任意修改和二次开发。Zabbix采用GNU General Public License (GPL) version 2开源协议。（2）安装和配置简单，用户仅需要一些简单的学习，即可完成监控系统的搭建工作。（3）搭建环境简单，基于开源软件构建平台，只需要Linux、Apache/Nginx、MySQL/PostgreSQL/Oracle、PHP即可，无需专用操作系统的支持，也无需专用硬件。（4）Zabbix-Agent完全支持Linux、UNIX、Windows、AIX、BSD和Solaris的监控，Zabbix-Server和Zabbix-Agent采用C语言编写，对系统资源的占用非常少，数据采集的性能非常好，速度非常快。（5）可将采集到的数据持久地存储到数据库中，便于对监控数据的二次分析。（6）具有非常强的扩展能力，可以很轻松地自定义监控项和实现数据采集，几乎能监控所有的数据。例如，可以监控网站的访问次数、UPS和天气温度等。毫不夸张地说，在Zabbix的世界里，只有想不到的事情，没有办不到的事情。（7）采用开源社区的运作模式，有各种论坛、邮件列表、IM及时沟通渠道等。（8）由Zabbix授权的公司提供商业服务支持。

因此，如果你是系统管理员、网络管理员和运维人员，想要构建自己的监控系统环境，Zabbix将会是最佳选择；如果你是开发人员，想要基于开源软件开发属于自己的监控系统，Zabbix也是比较好的选择。

2.5 该选用Zabbix的哪个版本

Zabbix有1.0、1.1、1.4、1.6、1.8、2.0、2.2、2.4、3.0、3.2、3.4、4.0（2018年）这几大发行版本。对外的首个发行版本为Zabbix 1.0 alpha1，其发行时间为2001年4月7日。随着版本的升级，其功能特性也在不断地增强和完善。1.X版本，具备较完备的功能；2.X版本，增强了很多新的功能特性，如对JMX、自动发现、LLD（Low Level Discovery）、虚拟化功能的原生支持。至此，Zabbix在国内逐渐流行（2013年前后开始逐渐被大多数公司所接受），成为大多数公司首选的监控系统。3.X版本，对用户体验进行了优化。随着版本的不断迭代，功能持续增强，性能逐步提高。在本书第1版写作时（2013年年末），Zabbix的版本是2.2，而在本书第2版出版时，已经是4.0版本了。

我们来看一看Zabbix官方对各版本的支持策略，如图2-4所示。我们看到，非LTS的版本均为实验版本，每6个月发布一个新版本。因此，对于生产环境版本的选择，我们尽量选择LTS版本，可享受长期更新支持服务，这样即使出现安全漏洞等问题，也会得到更新支持。图2-4 Zabbix版本的支持策略

Zabbix 2.0以后版本的支持时间如图2-5所示。图2-5 Zabbix 2.0以后版本的支持时间

对于版本的命名，每6个月会在LTS版本的基础上增加一个X.2的版本，18个月后，新的LTS版本发布，如图2-6所示。图2-6 LTS的发布周期和版本命名规则

按照产品版本的发布计划，Zabbix 4.0在2018年第3季度发布（本书写作时间为2018年第2～3季度，故截图也是这个时期的)，2019年第1季度发布4.2版本，如图2-7所示。图2-7 版本发布计划

以上图片均来自Zabbix官方网站，地址如下：

https://www.zabbix.com/life_cycle_and_release_policy

2.6 Zabbix的架构是什么样的

Zabbix的通用架构采用客户端/服务器端模式，分布式架构采用客户端/代理端/服务器端模式，Zabbix-Server将采集到的数据持久地存储到数据库中，用前端UI友好地展示给用户。图2-8展示的是客户端采集数据，代理服务器做代理，服务器端处理数据的架构模式。图2-8 Zabbix架构示意图

正如前面所提到的，Zabbix数据的采集不仅可以使用Agent方式，也可以使用其他方式，如采用SNMP、SSH、Telnet、IPMI等多种协议。

Zabbix-Server的内部处理进程如图2-9所示。图2-9 Zabbix-Server的内部处理进程

2.7 Zabbix的功能特性都有哪些

Zabbix具有常见的商业监控软件所具备的功能，如主机性能监控、网络设备性能监控、数据库性能监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制、分布式、可扩展能力、API等。

1.数据收集

· 可用性、性能检测。

· 支持Agent、SNMP（包括Trapping和Polling）、IPMI、JMX、SSH、Telnet等。

· 自定义检测。

· 自定义收集数据的频率。

· 客户端/代理端/服务器端模式。

2.灵活的触发器

可以定义非常灵活的告警阈值和与多种告警相关联的条件。

3.高度可定制的告警

· 发送通知，可定制包括告警级别、动作升级、收件人和媒体类型。

· 通知可以使用全局宏变量和自定义变量。

· 自动处理功能包括远程命令的自动调用和执行。

4.实时的绘图功能

监控项将数据实时绘制在图形上。

5.W eb监控能力

Zabbix可以模拟浏览器请求访问一个网站，并检查返回值和响应时间。

6.多种可视化展示

· 可以自定义监控的展示图，将多种监控数据集中展示到一张图上。

· 网络拓扑图。

· 自定义的Screens和Slide shows可以将多种图形集中展示。

· 报表功能。

· 资源使用情况的监控展示。

7.历史数据的存储

· 将数据存储在数据库中。

· 历史数据的存放周期可配置。

· 定期删除过期的历史数据。

8.配置非常容易

配置比较简单，只需要以下两步即可。（1）添加设备。（2）应用模板即可完成监控。

9.使用模板

· 模板可以分组。

· 模板具有可继承性。

10.网络发现

· 支持自动发现网络设备和服务器（可以通过配置自动发现服务规则实现）。

· Agent自动注册。

· 支持用自动发现（Low Level Discovery）实现动态监控项的批量监控（支持自定义），内置的自动发现包括文件系统、网络接口、SNMP OID，可定制自动发现。

11.快速的访问接口

· Web页面基于PHP。

· 远程访问。

· 日志审计。

12.API功能

应用API功能可以方便地与其他系统结合，包括手机客户端的使用。

13.系统权限

· 不同的用户展示监控的资源不同。

· 用户身份认证。

14.程序特性

服务器端Zabbix-Server和采集端Zabbix-Agent使用C语言编写，其性能非常高，内存开销非常小。

15.大型环境的支持

利用Zabbix-Proxy方式可轻松构建远程监控。

第3章 安装与部署

本章介绍Zabbix的安装与部署。采用RPM包安装，适合零基础入门的读者。对于源码安装的方法，请读者参考本书第15章内容。本章还将介绍安装Zabbix的软/硬件环境、容量规划等一些基础知识，对于从头开始构建Zabbix监控系统的读者具有实际的指导意义。

3.1 安装环境概述

Zabbix-Server服务器运行的环境为Linux(UNIX)+PHP+DataBase，PHP可以与Nginx或Apache组合使用，DataBase可以选择MySQL、Oracle、PostgreSQL等。本章所采用的软件环境由CentOS 7（64位）、httpd、PHP和MariaDB组成。3.1.1 硬件环境需求

1.硬件配置需求

对于最小化的安装环境，官方推荐的硬件配置如表3-1所示。表3-1 硬件配置

上述最小化安装环境中推荐的硬件配置，在实际生产环境中并不能很好地满足需求，需要适当提高硬件配置。具体的服务器硬件配置要求，与监控的机器数量和数据量等关系密切。一般来说，磁盘I/O出现瓶颈的概率更大一些。而选用物理服务器，通常性能会更好。对于大中型规模的环境来说，建议采用物理机来搭建监控环境，硬盘选用SAS/SSD/PCI-E SSD，如果是SAS硬盘，则建议做RAID 10，以保证其读/写性能和物理安全。当然，在实际环境中，也可以采用同等性能的虚拟机、云主机来搭建Zabbix监控环境。在整个Zabbix监控系统的搭建、维护中，磁盘I/O性能、数据库性能是系统良好运行的关键因素。

2.磁盘容量需求

Zabbix-Server所需的磁盘容量取决于监控数据的更新频率、每次更新的数据大小、监控数据存储的历史周期、监控数据删除的策略以及数据库本身日志的大小等的综合因素。衡量数据库写入的一个关键指标是NVPS（New Values Per Second），如图3-1所示，即每秒需要Zabbix-Server处理的数据量。图3-1 关键指标NVPS（1）历史数据所需的空间大小

NVPS值是指每秒处理的平均数据量，通过这个值可以计算出数据存储所需的空间大小。原理为，每条数据都占用大约50B的存储空间，因此NVPS×每条数据的平均大小=历史数据所需的空间大小。历史数据所需的空间大小的计算公式为：历史数据所需的空间大小=天数×每秒处理的数据量×1天24小时×1小时3600s×50B

例如，有60 000个监控项，监控指标数据更新周期为60s，每秒需要处理的数据量为60 000/60=1000（条），历史数据保存90天，则计算方法为：(90×24×3600)×1000×50=388 800 000 000（B），约362GB（2）趋势数据所需的空间大小

按照统计抽样得出的结论，在MySQL中每一个监控项的趋势数据大约为128B。趋势数据所需的空间大小的计算公式为：趋势数据所需的空间大小=监控项×每天24小时×一年365天×128B

假设有60 000个监控项，保存一年的趋势数据，其需要的空间大小为：60 000×24×365×128=67 276 800 000（B），约67GB（3）事件数据所需的空间大小

每个事件都占用130B空间，假设保存事件数据一年，则需要的空间大小为：

试读结束[说明：试读内容隐藏了图片]

下载完整电子书