Zabbix监控介绍及原理

zabbix中文社区: http://www.zabbix.org.cn/

Zabbix中文版(4.0版)官方文档: https://www.zabbix.com/documentation/4.0/zh/manual

 

监控基本介绍

使用 SNMP 协议获取主机 CPU、内存、磁盘、网卡流量等数据.

用脚本将获取到的 SNMP 数据存入数据库中,然后再使用一种名为 MRTG 的软件根据获取的数据绘制图表来分析数据的变化。

 

MRTG(Multi Router Traffic Grapher),顾名思义,这款软件最初是设计用于监控网络链路流量负载的。它可以用过 SNMP 获取到设备的流量信息,并根据这些信息绘制成图表并保存为 PNG 格式的图片,再将这些 PNG 图片以HTML 页面的方式显示给用户.

 

不过,MRTG 展示的页面和图表曲线相对简陋,它在一张图片中最多只能绘制两个数据的变化曲线,并且由于是 PNG 格式的静态图片,所以无法针对某一时间进行细化展示。为了解决这个问题,人们又开发了 RRDTOOL 工具.

 

不过,直接使用 RRDTOOL 绘图操作起来很麻烦。同时,现如今的数据中心动辄成百上千的设备,一个个的去提取、绘制、监控显然是不现实的事情.

 

Cacti 

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

 

Nagios 

是一款开源的免费网络监控报警服务,能有效监控 Windows、Linux 和 Unix 的主机状态,交换机、路由器和防火墙等网络设置,打印机、网络投影、网络摄像等设备。在系统或服务状态异常时发出邮件或短信报警第一时间通知运维人员,在状态恢复后发出正常的邮件或短信通知。Nagios 有完善的插件功能,可以方便的根据应用服务扩展功能。

 

Nagios 已经可以支持由数万台服务器或上千台网络设备组成的云技术平台的监控,它可以充分发挥自动化运维技术特点在设备和人力资源减少成本。只是 Nagios 无法将多个相同应用集群的数据集合起来,也不能监控到集群中特殊节点的迁移和恢复。

 

一个新的监控服务根据这个需求被设计出来,它就是 Ganglia。

Ganglia 是 UC Berkeley 发起的一个开源集群监视项目,设计用于测量数以千计的节点。Ganglia 的核心包含 gmond、gmetad 以及一个 Web 前端。

主要是用来监控系统性能,如:CPU 、内存、硬盘利用率, I/O 负载、网络流量情况等,通过曲线很容易见到每个节点的工作状态,对合理调整、分配系统资源,提高系统整体性能起到重要作用,目前是监控HADOOP 的官方推荐服务。

 

Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix 能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。

 

优点:

开源,无软件成本投入

Server 对设备性能要求低

支持设备多,自带多种监控模板

支持分布式集中管理,有自动发现功能,可以实现自动化监控

开放式接口,扩展性强,插件编写容易

当监控的 item 比较多服务器队列比较大时可以采用被动状态,被监控客户端主动 从server 端去下载需要监控的 item 然后取数据上传到 server 端。 这种方式对服务器的负载比较小。

Api 的支持,方便与其他系统结合

 

缺点:

需在被监控主机上安装agent,所有数据都存在数据库里, 产生的数据量很大,瓶颈主要在数据库。

 

 

想要用好zabbix进行监控，那么我们首要需要了解下zabbix这个软件的实现原理及它的架构。

建议多阅读官方文档。

一.zabbix架构图

二.zabbix组件

zabbix由以下几个组件部分构成：

1、Zabbix Server：负责接收agent发送的报告信息的核心组件，所有配置，统计数据及操作数据均由其组织进行；

2、Database Storage：专用于存储所有配置信息，以及由zabbix收集的数据；

3、Web interface：zabbix的GUI接口，通常与Server运行在同一台主机上；

4、Proxy：可选组件，常用于监控节点很多的分布式环境中，代理server收集部分数据转发到server，可以减轻server的压力；

5、Agent：部署在被监控主机上，负责收集本地数据并发往Server端或Proxy端；

 

三.相关术语

主机（host）：要监控的网络设备，可由IP或DNS名称指定；

主机组（host group）：主机的逻辑容器，可以包含主机和模板，但同一个组织内的主机和模板不能互相链接；主机组通常在给用户或用户组指派监控权限时使用；

监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是zabbix进行数据收集的核心，相对某个监控对象，每个item都由"key"标识；

触发器（trigger）：一个表达式，用于评估某监控对象的特定item内接收到的数据是否在合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从"OK"转变为"Problem"，当数据再次恢复到合理范围，又转变为"OK"；

事件（event）：触发一个值得关注的事情，比如触发器状态转变，新的agent或重新上线的agent的自动注册等；

动作（action）：指对于特定事件事先定义的处理方法，如发送通知，执行脚本等；

报警媒介类型（media）：发送通知的手段或者通道，如Email、Jabber或者SMS等；

模板（template）：用于快速定义被监控主机的预设条目集合，通常包含了item、trigger、graph、screen、application以及low-level discovery rule；模板可以直接链接至某个主机；

前端（frontend）：Zabbix的web接口

应用 (application) : 一组监控项组成的逻辑分组

 

 

四.监控流程

一个监控系统运行的大概的流程是这样的：

agentd需要安装到被监控的主机上，它负责定期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展现和绘图。

这里agentd收集数据分为主动和被动两种模式：

主动：agent请求server获取主动的监控项列表，并主动将监控项内需要检测的数据提交给server/proxy

被动：server向agent请求获取监控项的数据，agent返回数据。

 

【主动监测】通信过程如下：  在客户端角度

zabbix首先向ServerActive配置的IP请求获取active items，获取并提交active items数据值server或者proxy。很多人会提出疑问：zabbix多久获取一次active items？它会根据配置文件中的RefreshActiveChecks的频率进行，如果获取失败，那么将会在60秒之后重试。分两个部分：

 获取ACTIVE ITEMS列表

• Agent打开TCP连接

• Agent请求items检测列表

• Server返回items列表

• Agent 处理响应

• 关闭TCP连接

• Agent开始收集数据

主动检测提交数据过程如下：

• Agent建立TCP连接

• Agent提交items列表收集的数据

• Server处理数据，并返回响应状态

• 关闭TCP连接

 

【被动监测】通信过程如下：

• Server打开一个TCP连接

• Server发送请求agent.ping\n

• Agent接收到请求并且响应

• Server处理接收到的数据1

• 关闭TCP连接

从以上过程我们可以看出来，被动模式每次都需要打开一个tcp连接，这样当监控项越来越多时，就会出现server端性能问题了。

还有人会问，那实际监控中是用主动的还是被动的呢？这里主要涉及两个地方：

1、新建监控项目时，选择的是zabbix代理还是zabbix端点代理程式（主动式），前者是被动模式，后者是主动模式。

2、agentd配置文件中StartAgents参数的设置，如果为0，表示禁止被动模式，否则开启。一般建议不要设置为0，因为监控项目很多时，可以部分使用主动，部分使用被动模式。