分布式监控系统——Zabbix（1）

分布式监控系统——Zabbix（1）

前言

为何需要监控系统？

在一个IT环境中会存在各种各样的设备，例如：硬件设备，软件设备，其系统的构成也是非常复杂的，如下图：

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

一、监控系统的开源软件

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

1.Cacti

Cacti是一套基于 PHP、MySQL、SNMP及RRD Tool 开发的监测图形分析工具，Cacti是使用轮询的方式由主服务器向设备发送数据请求来获取设备上状态数据信息的，如果设备不断增多,这个轮询的过程就非常的耗时，轮询的结果就不能即时的反应设备的状态了。Cacti监控关注的是对数据的展示，却不关注数据异常后的反馈。如果凌晨 3点的时候设备的某个数据出现异常，除非监控人员在屏幕前发现这个异常变化，否则是没有任何报警机制能够让我们知道出现了异常。

2.Nagios

• Nagios 是一款开源的免费网络监控报警服务,能有效监控Windows、Linux和 Unix 的主机状态,交换机、路由器和防火墙等网络设置,打印机、网络投影、网络摄像等设备。在系统或服务状态异常时发出邮件或短信报警第一时间通知运维人员,在状态恢复后发出正常的邮件或短信通知。Nagios有完善的插件功能,可以方便的根据应用服务扩展功能。
• Nagios 已经可以支持由数万台服务器或上千台网络设备组成的云技术平台的监控,它可以充分发挥自动化运维技术特点在设备和人力资源减少成本。只是Nagios无法将多个相同应用集群的数据集合起来,也不能监控到集群中特殊节点的迁移和恢复。

3.Ganglia

• Ganglia 是 UC Berkeley发起的一个开源集群监视项目,设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web 前端。
• 主要是用来监控系统性能,如:CPU、内存、硬盘利用率, I/O负载、网络流量情况等,通过曲线很容易见到每个节点的工作状态,对合理调整、分配系统资源,提高系统整体性能起到重要作用,目前是监控HADOOP的官方推荐服务。

4.Zabbix

• Zabbix 是一个基于 WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix 能监视各种风格参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
• Zabbix是由Alexei Vladishev创建，目前由 Zabbix SIA在持续开发和支持。
• Zabbix 是一个企业级的分布式开源监控方案。
• Zabbix 是一款能够监控各种网络参数以及服务器健康性和完整性的软件。
• Zabbix 使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。这些功能使得Zabbix成为容量规划的理想方案。
• Zabbix 支持主动轮询和被动捕获。
• Zabbix所有的报告、统计信息和配置参数都可以通过基于Web的前端页面进行访问。基于Web的前端页面可以确保您从任何方面评估网络状态和服务器的健康性。
• Zabbix是免费的。Zabbix是根据GPL通用公共许可证第2版编写和发行的。这意味着它的源代码都是免费发行的，可供公众任意使用，商业支持由Zabbix公司提供。

5.区别

• nagios 图形不是特别好，也可以安装图形插件，但是也不怎么好看
• nagios 一般情况下如果需要图形可以和 cacti配合使用
• cacti的监控是轮询监控,效率低，图形相对nagios比较好看
• zabbix和 nagios 因为是并发监控，对cpu的要求更高
• zabbix 在性能和功能上都强大很多
• zabbix 的图形相当漂亮
• 支持多种监控方式 zabbix-agent snmp等等
• 支持分布式监控,能监控的 agent 非常多
• zabbix有图形的web 配置界面，配置简洁
• zabbix支持自动发现功能

二、Zabbix监控介绍

1.zabbix监控架构

2.zabbix优点

• 开源,无软件成本投入
• Server 对设备性能要求低
• 支持设备多,自带多种监控模板
• 支持分布式集中管理,有自动发现功能,可以实现自动化监控
• 开放式接口,扩展性强,插件编写容易
• 当监控的 item 比较多服务器队列比较大时可以采用被动状态,被监控客户端主动从server端去下载需要监控的 item 然后取数据上传到 server端。这种方式对服务器的负载比较小。
• Api 的支持,方便与其他系统结合

3.zabbix的缺点

• 需在被监控主机上安装 agent,所有数据都存在数据库里，产生的数据据很大,瓶颈主要在数据库。
• 项目批量修改不方便
• 社区虽然成熟，但是中文资料相对较少，服务支持有限
• 入门容易，能实现基础的监控，但是深层次需求需要非常熟悉Zabbix并进行大量的二次定制开发难度较大
• 系统级别报警设置相对比较多，如果不筛选的话报警邮件会很多；并且自定义的项目报警需要自己设置，过程比较繁琐
• 缺少数据汇总功能，如无法查看一组服务器平均值，需进行二次开发。

4.zabbix监控系统监控对象

• 数据库：Mysql，MariaDB，Oracle，SQL server agent
• 应用软件：Nginx，Apache，PHP，Tomcat agent

• 集群：LVS，Keepalive，HAproxy，RHCS，FS agent
• 虚拟化：VMware，KVM，XEN，docker，k8s agent
• 操作系统：Linux，Unix，Windows性能参数 agent

• 硬件：服务器，存储，网络设备 IPMI
• 网络：网络环境（内网环境，外网环境） SNMP

5.zabbix监控方式

1、被动模式

被动检测：相对于agent而言；agent，server向agetn请求获取配置的个监控项相关的数据，agent接收请求，获取数据并响应给server。

2、主动模式

主动监测：相对于agent而言；agent（active），agent向server请求与自己相关的监控项配置，主动的将server配置的监控项相关的数据发送给server。

主动监控能极大节约监控server的资源。

6.zabbix架构

zabbix由几个主要的软件组件构成，这些组件的功能如下。

1. zabbix server

   zabbix server是agent程序报告系统可用性，系统完整性和统计的核心组件，是所有配置信息、统计信息和操作数据的核心存储器。

2. zabbix数据库存储

   所有配置信息和zabbix收到的数据都被存储在数据库中。

3. zabbix web界面

   为了从任何地方和平台都可以轻松地访问zabbix，我们提供基于web的zabbix界面，该界面是zabbix server的一部分，通常（但不一定）跟zabbix server运行在同一台物理机器上。

   如果使用SQLite，zabbix web界面必须要跟zabbix server运行在同一台物理机器上。

4. zabbix proxy代理服务器

   zabbix proxy可以替zabbix server手机性能和可用性数据，proxy代理服务器是zabbix软件可选择部署的一部分；当然，proxy代理服务器可以帮助单台zabbix server分担负载压力。

5. zabbix agent

   zabbix agents监控代理部署在监控目标上，能够主动监控本地资源和应用程序，并将收集到的数据报告给zabbix server。

6. zabbix数据流

   监控方面，为了创建一个监控项（item）用于采集数据，必须先创建一个主机（host）

   告警方面，在监控项里创建触发器（trigger），通过触发器来触发告警动作（action）。因此，如果你想收到server XCPU负载过高的告警，必须满足：

   ①为server X创建一个host并关联一个用于对CPU进行监控的监控项（item）

   ②创建一个trigger，设置成当CPU负载过高时会触发

   ③trigger被触发，发送告警邮件

虽然看起来有很多步骤，但是使用模板的话操作起来其实很简单，zabbix这样的设计使得配置机制非常灵活易用。

7.zabbix常用术语的含义

1. 主机（host）

   一台你想监控的网络设备，用IP或域名表示。

2. 主机组（host group）

   主机的逻辑组：它包含主机和模板，一个主机组里的主机和模板之间并没有任何直接的关联，通常在给不同用户组的主机分配权限时候使用主机组。

3. 监控项（item）

   想要接收的主机的特定数据，一个度量数据。

4. 触发器（trigger）

   一个被用于定义问题阈值和“评估”监控项接收到的数据的逻辑表达式

   当接收到的数据高于阈值时，触发器从“OK”变成“Problem”状态，当接受到的数据低于阈值时，触发器保留/返回一个“OK”的状态。

5. 事件（event）

   单词发生的需要注意的事情，例如触发器状态改变或发现有监控代理自动注册。

6. 异常（problem）

   一个处在“异常”状态的触发器。

7. 动作（action）

   一个对事件做出反应的预定义的操作。

8. 升级（escakation）

   一个在动作内执行操作的自定义场景：发送通知/执行远程命令的序列。

9. 媒介（media）

   发送告警通知的手段：告警通知的途径。

10. 通知（notification）

    利用已选择的媒体途径把跟事件相关的信息发给用户。

11. 远程命令（remote command）

    一个预定义好的，满足一定条件的情况下，可以在被监控主机上自动执行的命令。

12. 模板（template）

    一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用，LLD，Web场景）的集合。

    模板的任务就是加快对主机监控任务的实施；也可以使监控任务的批量修改更简单。模板是直接关联到每台单独的主机上。

13. 应用（application）

    一组监控箱组成的逻辑分组。

14. web场景（web scenario）

    利用一个或多个HTTP请求来检查网站的可用性。

15. 前端（frontend）

    zabbix提供的web界面。

16. zabbix API

    zabbix API允许你使用JSON RPC协议（是一个无状态且轻量级的远程过程调用（RPC）传送协议，其传递内容透过JSON为主）来创建，更新和获取Zabbix对象（如主机、监控项、图形和其它）信息或者执行任何其他的自定义的任务。

17. zabbix server

    zabbix软件实现监控的核心程序，主要功能是与zabbix proxies和Agents进行交互、触发器计算、发送告警通知、并将数据集中保存等。

18. zabbix agent

    一个部署在监控对象上的，能够主动监控本地资源和应用的程序。

    zabbix agent部署在监控的目标上主动监测本地的资源和应用（硬件驱动，内存，处理器统计等）。

    zabbix agent手机本地的操作信息并将数据报告给zabbixserver用于进一步处理。一旦出现异常（比如硬盘空间已满或者有崩溃的服务进程

19. 被动（passive）和主动（active）检查

    zabbix agents可以执行被动和主动两种检查方式

    1. 被动检查（passive check）模式中agent应答数据请求，zabbix server（或者proxy）询问agent数据，如CPU的负载情况，然后zabbix agent回送结果。
    2. 主动检查（active checks）处理过程将相对复杂。agent必须首先从zabbix server索取监控项列表以进行独立处理，然后周期性地发送新的值给server。

    执行被动或主动检查是通过选择相应的监测项目类型拉配置的。item type.zabbix agent处理监控项类型有zabbix agent和zabbix agent（server）。

20. zabbix proxy

    • 一个帮助zabbix server收集数据，分担zabbix server的负载的程序。
    • zabbix proxy是一个可以从一个或多个受监控设备收集监控数据，并将信息发送到zabbix server的进程，基本上是代表zabbix server工作的。所有收集的数据都在本地进行缓存，然后传送到proxy所属的zabbix server。
    • 部署proxy是可选的，但是可能非常有益于分散单个zabbix server的负载。如果只有proxy收集数据，server上的进程就会减少cpu消耗和磁盘I/O负载。
    • zabbix proxy是完成远程区域、分支机构、没有本地管理员的网络的集中监控的理想解决方案。
    • zabbix proxy需要使用独立的数据库。

END