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

作者：吴兆松

出版社：电子工业出版社

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

Zabbix企业级分布式监控系统试读：

前言

笔者在运维从业生涯中用过的监控系统有Cacti、Nagios，以及笔者公司开发的监控告警系统，直到接触了Zabbix，才发现这个灵活而强大的自动化监控工具正是笔者以前所寻找的。Zabbix灵活的设计为用户提供了易用的二次开发接口，让用户既可以使用Zabbix本身提供的功能，又可以自定义更多的监控项功能，从硬件监控，到操作系统，再到服务进程，以及网络设备，其无所不能的监控功能令人叹为观止，笔者不禁要为这么优秀的开源工具而震撼。

在Zabbix的使用过程中，也会遇到很多问题，包括：配置使用、架构设计、性能调优、大规模部署和应用等。由于Zabbix是一个集众多功能于一体的工具，自带的功能实在太多，一般用户往往仅用到其基本的功能，对更高级的功能并未使用到。然而随着使用的加深，会遇到更多的问题，这其中最大的问题是告警和数据存储。本书对这两部分内容都有深入的讲解。

笔者从2012年12月开始学习并使用Zabbix，在此过程中，通过对Zabbix官网的学习，将Zabbix的部署和配置，以及其丰富的功能整理成文档，并对外公开，已在网络上公开过两个版本《Zabbix使用手册V1.4》和《Zabbix使用手册V2.0》，对不少学习Zabbix的朋友有所帮助。为了将Zabbix的功能更加详细地展示出来，于是有了本书的出现。本书以简洁通俗的方式将Zabbix的各项功能展现给读者，使读者即学即用，以此来节省读者宝贵的时间。

本书将不会开源电子书PDF版本，但笔者将来会对《Zabbix使用手册》做更多的更新，本书的所有代码和软件是开源的。另外，笔者开源的Zabbix安装包定制项目对重新打包Zabbix的RPM安装包有一定的参考价值，其地址为https://github.com/itnihao/zabbix-rpm，希望对大家有所帮助。如何阅读本书

本书从运维（OPS）角度对Zabbix的各项功能进行了详细介绍，以自动化运维视角为出发点，对自动化功能、高可用、监控告警、性能调优、Zabbix API、Zabbix协议、RPM安装包定制等进行了深入浅出的探讨。

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

第2部分为中级部分，包括第7~11章，对Zabbix的多种监控方式进行了详述（如IPMI、SNMP、JMX等），对Zabbix的自动化功能进行了深入讲解，介绍了分布式监控系统，并有大量自定义脚本的监控案例，对自动化发现LLD功能进行了深入的讲解，适合对Zabbix有一定基础的读者深入学习。通过对这部分的学习，读者将会深入理解Zabbix的自动化功能。

第3部分为高级部分，包括第12~16章，介绍Zabbix的性能调优，解决Zabbix在使用过程中遇到性能瓶颈的问题，并让读者学会使用Zabbix API、Zabbix协议来扩展Zabbix，从而为构建运维平台提供了更多的扩展性。同时，也讲解了如何定制RPM包，以及如何使用SaltStack来自动化部署和配置，最后用一个实例来讲解如何构建企业级分布式监控系统，适合对Zabbix非常熟悉的读者进行深入应用。通过对这部分的学习，读者应该能够深入理解Zabbix。

第4部分为附录部分，介绍Zabbix的源码安装和Zabbix的升级，仅供读者参考。在介绍Zabbix的安装时，作者极力推荐在RHEL这类系统中使用RPM包的安装方式，但网络中大部分资料都采用源码安装，且在多种书籍中均有使用源码安装的习惯，从而误导了读者，认为源码安装才是真正地懂Linux，以此造成部分用户以使用源码安装为荣，让源码安装具有“优越感”。使用源码安装导致部分初学者连最基本的安装和配置都会遇到很多麻烦，甚至安装一个软件都需要几天才能完成。当然，这里并不排斥使用源码安装，笔者只是为了纠正一个观念，请读者尽量使用自己打包的RPM这种适合大规模安装的方式去部署Zabbix程序。本书将RPM定制的内容作为单独的一章进行介绍，让读者深入理解安装和定制的过程。读者对象● 中/高级Linux系统管理员● 系统运维工程师● 运维开发工程师● 系统集成商● 运维监控系统工程师● 监控系统软件开发（设计）人员● IT管理人员● 架构设计人员勘误和支持

因作者水平有限，书中的错误或不妥之处难免，恳请读者批评、指正。如果读者有任何宝贵的意见或建议，可以发送邮件到zabbix@itnihao.com，我们将尽快给予反馈。

本书所有的代码和安装软件将放在GitHub中托管，地址为https://github.com/itnihao/zabbix-book/，读者可以自行下载并使用。另外，本书的勘误也会在该链接中得到反馈。声明

本书采用的Zabbix版本为2.0和2.2，因此对Zabbix 1.8不再讨论，Zabbix 2.4将在未来两年内会发布，其功能与Zabbix 2.2将有所不同（例如，Zabbix 2.4中的分布式模式会去掉node架构等）。本书采用的操作系统以RHEL（CentOS）、Windows为主，对于其他系统，其配置方法类似，请读者举一反三。本书对部分不重要的内容只是简略地介绍，希望能起到抛砖引玉的作用。

另外，本书在编写过程中，参考了以下网址中的内容，并对官方网站的部分内容进行了翻译和整理，后面不再单独声明。https://www.zabbix.com/documentation/2.2/manualhttps://www.zabbix.org/wiki/http://pengyao.org/zabbix-triggers-functions.html鸣谢

本书在编写过程中得到了众多朋友的支持。在这里要感谢姚炫伟、陈益超、窦喆、冯颖聪等对本书的技术问题进行审校；感谢电子工业出版社编辑任晓露和李利健对本书的精心指导，更正了书稿中的很多错误，本书才得以与读者见面。特别感谢以下朋友对作者的支持与鼓励：伊杨林、吴华、黄小路、芮峰云、罗坤、温宏强、曾兵、范仁更、邝玲、张克元（网名Geek）、沈灿、薛群、李佃田、罗苗、杨晨、焦婷婷、KissPuppet（网名）、司鼎任、汤永全、罗伟、水喜云、唐文军、李彬（网名彬彬）、高鹏程、唐博、罗涛（网名MorningSong）等。注意，以上排名不分先后（使用Linux命令sort -R随机生成排序）。感谢SJCloud公司的全体成员，感谢公司领导金剑、陶永国、付自强在笔者工作期间给予的支持和帮助。

另外，也要感谢史应生、李庆雷、姚仁捷、邓磊、马哥（马永亮）、孙科伟、虚拟的现实（网名）等分享的有关Zabbix的技术文档、视频录制和讲座等内容，这些内容对促进Zabbix在国内的推广和发展有很大帮助。很多网友也写了大量有关Zabbix的博客文章，相关链接会放在本书的GitHub项目中。本书的代码示例规范（1）在Shell环境中使用，Shell命令用黑体加粗。shell# vim /etc/php.ini（2）在MySQL环境中使用，SQL命令用黑体加粗。mysql> flush privileges;（3）在本书中，Zabbix-Server表示zabbix-server服务或进程，其他Zabbix-Agent、Zabbix-Get、Zabbix-Proxy情况类似；代表zabbix-server、zabbix-agent、zabbix-get、zabbix-proxy、zabbix-sender等程序名称本身时，一律采用小写；程序配置文件中的字段，如Hostname=Zabbix proxy、Hostname=Zabbix server，统一采用原配置文件中的风格，后面不再声明。（4）重要参数的解释，用灰色底纹表示。• Proxy name，即Zabbix-Proxy的hostname。• Proxy mode，即Zabbix-Proxy的工作模式，被动或主动，默认是主动模式。作者（网名itnihao）第1部分基础部分第1章　监控系统简介

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

在一个IT环境中会存在各种各样的设备，例如，硬件设备、软件设备，其系统的构成也是非常复杂的，通常由如图1-1所示的模型构成。图1-1

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

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

数据采集的工作模式可以分为被动模式（服务器端到客户端采集数据）和主动模式（客户端主动上报数据到服务器端）。通常，大多数监控系统应该能同时支持这两种模式。被动模式对服务器的开销较大，适合小规模的监控环境；主动模式对服务器的开销较小，适合大规模的监控环境。

采集数据的协议方式可以分为两种：专用客户端采集和公用协议采集（SNMP、SSH、Telnet等），如图1-3所示。图1-3

对于采集到的监控数据，可以将其存储到数据库或者文本或者其他方式，具体采用哪一种，应根据实际需求来决定。

怎么规划监控系统的架构设计呢？下面将详细分析。

对于一般的监控环境，被监控的节点不多，产生的数据较少，采用C/S（Client/Server，客户端/服务器端）架构就足够了，如图1-4所示，这种架构适合于规模较小、处于同一地域的环境。图1-4

对于大规模的监控环境，被监控的节点多，且监控类型多，监控产生的数据和网络连接开销会非常巨大，而且由于跨地域等多种因素，需要分布式的解决方案，常见的方式为C/P/S（Client/Proxy/Server，客户端/代理端/服务器端）架构（如图1-5所示），采用中间代理将大大提高监控服务器端的处理速度，从而能支撑构建大型分布式监控的环境。图1-5

监控系统更重要的功能是告警和故障处理，这对及时解决问题和故障自愈非常重要。告警的时候，需要考虑到故障的有效汇报和集中汇报，防止出现“告警洪水”，即同一类告警信息重复大量地发送。1.3　监控系统的开源软件现状

前面简单介绍了监控的原理，下面看看已有的解决方案。

在监控软件中，开源的解决方案有流量监控（MRTG、Cacti、SmokePing、Graphite等）和性能告警（Nagios、Zabbix、Zenoss Core、Ganglia、OpenTSDB等）可供选择，并且每种软件都有自己的特点和功能，各自的侧重点和目标不完全相同，在设计理念和实现方法上也大同小异，但都具有共同特征，例如，采集数据、分析展示、告警以及简单的故障自动处理。最终都能达到对IT系统服务可用性的一个完全展示。下面将详细介绍各自的特点。1.3.1　MRTG

MRTG（Multi Router Traffic Grapher）是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的Tobias Oetiker与Dave Rand所开发，以GPL授权。

MRTG最早的版本是在1995年春推出的，用Perl语言写成，可跨平台使用，数据采集用SNMP协议，MRTG将收集到的数据通过Web页面以GIF或PNG格式绘制出图像，并以日、周、月为单位分别绘出，可以查询最大值和最小值，如图1-6所示。图1-6

MRTG原本只能绘出网络设备的流量图，后来发展出了各种插件。因此，网络以外的设备也可由MRTG监控，例如，服务器的硬盘使用量、CPU的负载等。1.3.2　Cacti

Cacti（英文含义为仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具，如图1-7所示。它通过snmpget来获取数据，使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。图1-7

Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能）。1.3.3　SmokePing

SmokePing主要用于监视网络性能，包括常规的ping、WWW服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持，特点是绘制的图非常漂亮，网络丢包和延迟用颜色和阴影来表示，支持将多张图叠放在一起，如图1-8所示。其作者（Tobi Oetiker）还开发了MRTG和RRDtool等工具。图1-8

SmokePing的站点为：http://tobi.oetiker.ch/hp/。1.3.4　Graphite

Graphite是一个用于采集网站实时信息并进行统计的开源项目。Graphite服务支持平均每分钟4800次更新操作，采用简单文本协议，具有绘图功能，其即插即用的功能可方便地用于任何需要监控的系统上。Graphite的界面如图1-9所示。图1-9

和其他监控工具不同的是，Graphite本身并不收集具体的数据，这些数据收集的工作通常由第三方工具或插件完成（如Ganglia、Nagios、collectd、statsd、Collectl等）。因此，可以说，Graphite是一个绘图工具。

值得一提的是，Graphite用Python语言编写，采用Django框架，对于熟悉Python的用户（通常是运维人员）来说，将是一个不错的绘图工具选择。

简单地说，Graphite做两件事：存储数据和按需绘图。

Graphite的官方站点为：http://graphite.wikidot.com/。1.3.5　Nagios

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

Nagios可运行在Linux和UNIX平台上，同时提供一个可选的基于浏览器的Web界面，以方便系统管理人员查看网络状态、各种系统问题，以及日志等，如图1-10所示。图1-10

Nagios的功能侧重于监控服务的可用性，能及时根据触发条件告警。

目前，Nagios也占领了一定的市场份额，不过从笔者的观察来看，Nagios并没有与时俱进，已经不能满足于多变的监控需求，架构的扩展性和使用的便捷性有待增强，其高级功能集成在商业版Nagios XI中。1.3.6　Zenoss Core

Zenoss Core（简称Zenoss）是开源企业级IT管理软件，它允许IT管理员依靠单一的Web控制台来监控网络架构的状态和健康度。

Zenoss Core的强大功能来自深入的列表与配置管理数据库，用于发现和管理公司IT环境的各类资产（包括服务器、网络和其他结构设备）。Zenoss可以创建关键资产清单和对应的组件级别（接口、服务、进程、已安装的软件等）。建立好模型后，Zenoss就可以监控和报告IT架构中各种资源的状态和性能状况了。同时还提供与CMDB关联的事件和错误管理系统，以协助提高各类事件和提醒的管理效率，以此提高IT管理人员的效率。

Zenoss Core采用SNMP来采集数据，其界面如图1-11所示。图1-111.3.7　Ganglia

Ganglia是一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用RRDtool存储数据，具有可视化界面，适合于对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统，可以轻松地处理2000个节点的集群环境。该软件的部分截图如图1-12所示。图1-121.3.8　OpenTSDB

开源监控系统OpenTSDB用HBase存储所有时序（无须采样）的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里（如图1-13所示）。OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web化、图形化等。图1-13

在对实时性要求比较高的场合，OpenTSDB是一个很好的选择。它支持秒级别的数据采集，这在其他监控系统中是无法想象的。因得益于其存储系统的选择，所以它支持大数据分析。因此，这个开源软件在未来的环境中会有更多的用户，也会获得更广泛的支持。1.3.9　Zabbix

Zabbix是一个分布式监控系统，支持多种采集方式和采集客户端，有专用的Agent（代理），也可以支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库，然后对其进行分析整理，达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说，它的总体功能做得非常优秀，其界面如图1-14和图1-15所示。图1-14图1-15

该监控工具也是本书的重点，具体功能将在后面详细介绍。

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

前面已经介绍了为什么需要监控系统，下面将深入介绍监控系统的原理。1. 监控系统的诞生

首先来看一下监控系统的使用者都有哪些？

试想一个很小的网站，刚上线也许就只有一个VPS或者一台服务器。随着业务的发展，它逐渐成为一个大型的网站，服务器从一台发展到多台，运维人员从一个发展到多个，业务战线也从一条发展到多条，这时候出现故障的概率就会大大增加。当有一天，你作为该网站的运维人员，你的老板问你为何某个服务不可使用，为何出现故障时，而身为运维人员的你却不知道故障出现在哪里，此时你是不称职的。如果换一个角度，在未发生故障的时候就已经把故障解决了，那你就是幕后英雄。

有一个故事是讲神医扁鹊的。有人对扁鹊说：“你是天下的神医，能治天下各种疑难杂症，很了不起。”而扁鹊却说：“你知道吗？我和我长兄比起来，可差远啦！我长兄给人治病，是治人于病未发之前，在稍见端倪的时候就能防患于未然，而我只能治人病于膏肓之中，往往是病人受尽折磨才来找我。”（引自魏文王问扁鹊——《鹖冠子》世贤第十六）

监控系统就是这么一个“神医”，救人于膏肓之中（发送故障告警，或者自动修复故障），在发生故障之前，监控系统中会隐约显现故障的前期迹象，这也适用于其他事物，即任何事物的发生必有其原因和条件。有经验的人会从这小小的迹象中发现更大的问题，例如，突发的流量增长，突发的访问量增大，某台服务器的瞬间负载变高，都表明了即将出现异常情况。对出现的故障，能及时通知告警和故障的自动修复，对运维人员响应处理故障的速度会大大加快，甚至在异常严重的故障情况下，对及时采用应急预案，有不可或缺的作用。如果没有监控，故障的反馈往往来自用户的报告，然后才由运维人员处理。2. 监控系统的实现

监控系统往往需要对物理硬件和应用软件的性能和参数进行数据汇集，实现集中管理和统一分析。

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

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

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

监控系统需要提供一个API，方便其他功能系统对监控数据进行操作管理，这在业务系统精密的情况下显得特别重要，通常能对外提供API功能的软件，其用户群会更广，产品会越做越好。API一般可以分为RESTful、SOAP等形式，数据类型有JSON、XML等多种。从目前的趋势来看，RESTful已经成为绝大多数API首选的方式。

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

常见的监控系统性能采集指标如表1-1所示。表1-13. 监控系统对时间的要求

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

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

支持对告警内容的分析自动处理，防止误报、漏报，以及防止抖动。这一点对大多数监控系统都是一个值得挑战和研究的课题。例如，一个机房网络发生故障，按照常规告警内容，会收到无数条告警信息，内容是每个设备的故障，而对于更高级的告警信息，我们希望收到的是“某机房存在网络故障，受影响的设备的IP是X.X.X.X~X.X.X.X，受影响的业务是XXX.”，这样做的目的是让告警信息更智能、更有效，防止“告警炸弹”的产生。

简而言之，监控数据的采集、存储、分析和故障报告是每个监控系统的基本功能，其他复杂的附加功能则是监控系统的增值业务。

在本书中，你将会看到以上功能的具体体现，无论你是使用Zabbix，还是自行开发监控系统，本书都具有良好的参考价值。第2章　Zabbix简介

本章对Zabbix的发展历史、客户群、开源模式、软件架构和Zabbix的详细功能等方面进行了详细介绍，使读者对Zabbix有一个全面的认识，读者稍做了解即可，重点为如图2-5所示的Zabbix架构理解。2.1　Zabbix的客户

在国外，有如图2-1所示的用户在使用Zabbix。图2-1注：对于以上信息，读者可以参考http://www.zabbix.com/users.php。

在国内，BAT的部分业务、豆瓣、58同城、PPTV、搜狐、Letv、人人、网易、小米、360等公司都在使用Zabbix。

随着云计算、虚拟化的大规模应用，以及未来移动互联网、物联网等的兴起，Zabbix的使用将越来越广泛，应用场合也越来越多。目前，不少互联网公司、云计算公司、系统集成软件公司、外包服务公司等，都有对Zabbix进行二次开发和大规模使用。所以，可以断言，Zabbix在未来将会引领监控软件的潮流。

Zabbix适合中小型企业、大中型企业的用户使用。单个Server节点可以支持上万台设备，每秒可以处理1.5万次请求，理论上可以支持5万台设备。

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

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

这里暂且把Zabbix的用户分为如下三类（这样分不一定恰当）。● 入门用户：以前从未接触过任何监控系统，也不懂Linux。学会Zabbix的安装和配置即可（安装可以用RPM，源码安装也很容易）。● 中级用户：有Linux基础，熟悉LAMP和LNMP环境搭建、MySQL数据库、Shell脚本，及简单的英文阅读能力，主要难点在于触发器、数据库调优和API的使用。● 高级用户：熟悉PHP、C等一门脚本语言，具备二次开发能力，能修改源码，对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/wikiZabbix体验地址 https://zabbix.org/zabbix/dashboard.php

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

Zabbix SIA公司是Zabbix的官方技术团队成立的公司，其运作模式是商业软件的开源----软件的使用免费，服务收费。其为用户提供咨询、技术支持服务（定制开发、解决方案、人员培训等），如图2-3所示。图2-3注：该图来自史应生的Zabbix讲座《Zabbix监控概述》中的PPT文件截图。2.4　选择Zabbix的理由

对比同类监控产品，有以下理由选择使用Zabbix。

① Zabbix是一个自由开放源代码的产品，用户可以对源代码进行任意修改和二次开发。Zabbix采用GNU General Public License（GPL）version 2开源协议。

② 安装和配置简单，用户仅仅需要一些简单的学习，即可完成监控的搭建工作。

③ 搭建环境简单，基于开源软件构建平台，仅需要Linux、Apache/Nginx、MySQL/PostgreSQL/Oracle、PHP即可，无须专用操作系统支持，也无须专用硬件。

④ Zabbix-Agent完全支持Linux、UNIX、Windows、AIX、BSD和Solaris的监控，Server和Agent都采用C语言编码，对系统的资源占用非常小，数据采集的性能和速度非常快。

⑤ 将数据采集持久存储到数据库，便于对监控数据的二次分析。

⑥ 非常丰富的扩展能力，很轻松地自定义监控项和实现数据采集，几乎能监控所有的数据。例如，可以监控网站的访问次数，监控UPS和天气温度等。毫不夸张地说，在Zabbix的世界里，往往有你想不到的事情，没有办不到的事情。

⑦ 开源社区的运作模式，有各种论坛、邮件列表、IM及时沟通等。

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

Zabbix的版本大致可以分为：1.0、1.1、1.4、1.6、1.8、2.0、2.2这几大发行版本（如图2-4所示）。对外的首个发行版本为Zabbix 1.0 alpha1，其发行时间为2001年4月7日，随着版本的升级，其功能特性也在不断增强和完善。从Zabbix 1.8开始，增强了很多新的功能和特性，如对JMX、自动发现、Low level discovery功能的支持，而当前的Zabbix 2.2则有了进一步的完善，性能相比Zabbix 2.0提高了5倍，成为当前功能最强大的版本，支持对VMware的监控，可以动态加载模板，Web能够模板化配置。下一个版本是2.4，目前Zabbix官方正在规划中。图2-4

Zabbix的通用架构是Client/Server架构，分布式架构为Client/Proxy/Server或Client/Node/Server，Zabbix-Server将采集到的数据持久地存储到数据库中，用前端UI友好地展示给用户，图2-5展示的是用Agent采集数据，Proxy做代理，Server处理数据的架构模式。图2-5

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

Zabbix-Server的处理进程如图2-6所示。图2-62.6　Zabbix的运行流程

Zabbix的运行流程可以用图2-7来表示。图2-72.7　Zabbix的功能特性

Zabbix有常见的商业监控软件所具备的功能，如主机的性能监控、网络设备性能监控、数据库性能监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制、分布式、可扩展能力、API等。（1）数据收集● 可用、性能检测。● 支持Agent、SNMP（包括Trapping和Polling）、IPMI、JMX、

SSH、Telnet等。● 自定义的检测。● 自定义收集数据的频率。● 服务器端/代理端和客户端模式。（2）灵活的触发器

可以定义非常灵活的告警阈值和多种告警相关联的条件。（3）高度可定制的告警● 发送通知，可定制包括告警级别、动作升级、收件人和媒体类型。● 通知可以使用全局宏变量和自定义的变量。● 自动处理功能包括远程命令的自动调用和执行。（4）实时的绘图功能

监控项将数据实时绘制在图形上。（5）Web监控能力

Zabbix可以模拟浏览器请求一个网站，并检查返回值和响应时间。（6）多种可视化的展示● 可以自定义监控的展示图，将多种监控数据集中展示到一张图

中。● 网络拓扑图。● 自定义的Screens和Slide shows可以将多种图形集中展示。● 报表功能。● 资源使用情况的监控展示。（7）历史数据的存储● 数据存储在数据库中。● 历史数据的存放周期可配置。● 定期删除过期的历史数据。（8）配置非常容易

配置比较简单，只需要以下两步即可。

第一步：添加设备。

第二步：应用模板即可完成监控。（9）使用模板● 模板可以分组。● 模板具有可继承性。（10）网络发现● 支持自动发现网络设备和服务器（可以通过配置自动发现服务规

则实现）。● Agent自动注册。● 支持自动发现（Low level discovery）实现动态监控项的批量监

控（支持自定义），内置的自动发现包括文件系统、网络接口、

SNMP OID，可定制自动发现。（11）快速的访问接口● Web页面基于PHP。● 远程访问。● 日志审计。（12）API功能

应用API功能可以方便地和其他系统结合，包括手机客户端的使用。（13）系统权限● 不同的用户展示监控的资源不同。● 对用户的身份认证。（14）程序特性

用C语言编写，其性能和内存开销非常小。（15）大型环境的支持

利用Zabbix-Proxy方式即可轻松构建远程监控。第3章　安装与部署

本章介绍Zabbix的安装和配置，这是在一个Server/Agent的架构环境中进行部署的，采用RPM包安装，适合零基础入门的读者。对于源码安装，请读者参考本书附录部分。另外，还将介绍Zabbix安装的软/硬件环境、容量规划等一些基础知识，对从头开始构建Zabbix监控系统的读者具有实际的指导意义。3.1　安装环境概述

Zabbix服务器运行的环境为Linux(UNIX)+PHP+Web Service+DataBase，这里的Web Service可以为Nginx、Apache，DataBase可以为MySQL、Oracle、PostgreSQL等。3.1.1　硬件条件1. 硬件配置

官方推荐的最小硬件配置如表3-1所示。表3-1

硬件需求与监控的机器数量和监控的数据量大小等有密切关系，对于硬盘的要求，建议采用SAS硬盘RAID10，因为其性能和安全都很好。当然，实际环境中也有可能采用虚拟机来搭建Zabbix监控系统环境。在整个Zabbix监控系统的搭建和维护中，磁盘I/O、数据库性能将成为整个监控系统运行良好的关键因素。2. 磁盘容量大小

Zabbix-Server的数据库大小取决于NVPS（Number of processed values per second），如图3-1所示，NVPS从总体上反映了处理速度，与监控项的数目、监控的类型、取值间隔、History的保留时间和Trends的保留时间有直接关系。图3-1（1）历史数据的保存

NVPS值是每秒处理的平均数量，假设有60000个监控项，刷新周期为60秒，那么每秒需要处理的数据为60000/60=1000（条），表示此时每秒将会向数据库中新增1000条数据，这些数据根据设置的历史存储时间保存。例如，保存周期为90天，每秒处理1000条，计算方法为：

历史数据大小=天数×每秒处理的数据×一天24小时×一小时3600秒×50Bytes

则需要占用的空间为：（90×24×3600）×1000×50=388 800 000 000（B）（约362GB，假设保存为一年，则有362×4=1448GB）（2）趋势数据的保存

每一个Items趋势的数据大约为128B，这取决于数据库类型。

假设有60 000个Items，保存一年的趋势数据，其计算方法为：趋势数据大小=监控项×每天24小时×一年365天×128B

则需要的空间为：60 000×24×365×128=67 276 800 000B（约67GB）（3）事件数据的保存

每个事件占用130 B空间，假设保存一年，则需要的空间为：1×24×3600×365×130=4 099 680 000B（约4GB）

即60 000个监控项，周期为60秒更新数据，保存一年需要362+67+4=443（GB）磁盘空间，实际上，比这占用得更多，需要保存其他更多的数据，因此，应该会超过500GB的数据空间。（4）需要的空间计算方法

磁盘空间的计算方法如表3-2所示。表3-2

所以，总共需要的磁盘空间大小计算公式为：Total space=Configuration + History + Trends + Events

可以看到，由于Items、取值间隔、历史数据等各因素的不同，将会使磁盘空间的使用量不同。对数据库来说，巨大的数据量会造成数据库查询的压力增大，这将在后面探讨。因此，对监控系统进行规划之前，必须要考虑到硬盘性能、监控数据的存放周期等因素。.1.2　软件条件1. Zabbix支持的操作系统平台

Zabbix支持Linux、UNIX、Windows系统，如表3-3所示，列出了Zabbix各模块所能支持的操作系统。表3-3

注意：如果仅仅检测网络服务FTP、SSH、HTTP、DNS、LDAP，无须安装任何客户端，即可支持监控数据的获取。2. 数据库版本的要求

数据库版本的要求如表3-4所示。表3-43. Web前端需要支持的软件环境

Web前端需要支持的软件环境如表3-5所示。表3-5

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

下载完整电子书