带你了解zabbix

监控系统

1、为何需要监控系统

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

2、监控系统的实现

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

       对于采集到的监控数据，可以将其存储到数据库或者文本或者其他方式，具体采用哪一种，应根据实际需求来决定。
怎么规划监控系统的架构设计呢？下面将详细分析。
对于一般的监控环境，被监控的节点不多，产生的数据较少，采用C/S（Client/Server，客户端/服务器端）架构就足够了

       对于大规模的监控环境，被监控的节点多，且监控类型多，监控产生的数据和网络连接开销会非常巨大，而且由于跨地域等多种因素，需要分布式的解决方案，常见的方式为C/P/S（Client/Proxy/Server，客户端/代理端/服务器端）架构

3、监控系统的开源软件现状

（1）MRTG

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

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

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

（2）Cacti

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

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

（3）Nagios

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

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

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

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

 （4）Ganglia

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

（5）Zabbix

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

4、监控系统的原理

（1）监控系统的诞生

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

（2）监控系统的实现

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

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

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

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

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

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

（3）监控系统的时间要求

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

 （4）监控系统的告警需求

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

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

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