我们为什么需要监控?

严格来说，线上的服务器没有监控，是不允许上线的，在真实的生产环境中，我们运维工作，需要时时刻刻了解我们线上平台的运行状态，服务器出现故障的时候方便我们更直观的去依靠监控平台去排除问题。

Zabbix: 融合Cacti和Nagios的大部分功能, 通过WEB界面提供分布式的网络监控

Zabbix是什么？

Zabbix是一个基于Web界面的分布式系统监控的企业级开源软件。可以监视各种系统与设备的参数，保障服务器及设备的安全运营。

Zabbix的功能和特性

（1）安装与配置简单。

（2）可视化web管理界面。

（3）免费开源。

（4）支持中文。

（5）自动发现。

（6）分布式监控。

（7）实时绘图。

Zabbix的架构

1.  Zabbix Server：负责接收Agent发送的报告信息，组织所有配置、数据和操作。

2.  Database Storage：存储配置信息以及收集到的数据。

3.  Web Interface：Zabbix的GUI 接口，通常与Server运行在同一台机器上。

4.  Proxy：可选组件，常用于分布式监控环境中。

5.  Agent：部署在被监控主机上，负责收集数据发送给Server。

zabbix的工作流程

一般情况下，我们将zabbix agent部署到被监控主机上，由agent采集数据，报告给负责监控的中心主机，中心主机也就是master/agent模型中的master，负责监控的中心主机被称为zabbix server，zabbix server将从agent端接收到的信息存储于zabbix的数据库中，我们把zabbix的数据库端称为zabbix database， 如果管理员需要查看各种监控信息，则需要zabbix的GUI，zabbix的GUI是一种Web GUI，我们称之为zabbixweb，zabbix web是使用php编写的，所以，如果想要使用zabbix web展示相关监控信息，需要依赖LAMP环境，不管是zabbix   server ，或是zabbix web，他们都需要连接到zabbix database获取相关数据，zabbix的进程

默认情况下zabbix包含5个程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server，另外一个zabbix_java_gateway是可选，这个需要另外安装。下面来分别介绍下他们各自的作用。

zabbix_agentd客户端守护进程，此进程收集客户端数据，例如cpu负载、内存、硬盘使用情况等。 

zabbix_getzabbix工具，单独使用的命令，通常在server或者proxy端执行获取远程客户端信息的命令。通常用于排错。例如在server端获取不到客户端的内存数据，我们可以使用zabbix_get获取客户端的内容的方式来做故障排查。 

zabbix_senderzabbix工具，用于发送数据给server或者proxy，通常用于耗时比较长的检查。很多检查非常耗时间，导致zabbix超时。于是我们在脚本执行完毕之后，使用sender主动提交数据。 

zabbix_serverzabbix服务端守护程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server 

备注：当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据。 

zabbix_proxyzabbix代理守护进程。功能类似server，唯一不同的是它只是一个中转站，它需要把收集到的数据提交/被提交到server里。为什么要用代理？代理是做什么的？卖个关子，请继续关注运维生存时间zabbix教程系列。 

zabbix_java_gatewayzabbix2.0之后引入的一个功能。顾名思义：Java网关，类似agentd，但是只用于Java方面。需要特别注意的是，它只能主动去获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy。

当监控规模变得庞大时zabbix支持分布式监控，我们可以把成千上万台的被监控对象分成不同的区域，每个区域中设置一台代理主机，区域内的每个被监控对象的信息被agent采集，提交给代理主机，在这个区域内，代理主机的作用就好比zabbix server，我们称这些代理主机为zabbix proxy，zabbix proxy再将收集到的信息统一提交给真正的zabbix server处理，这样，zabbix proxy分摊了zabbix server的压力，同时，我们还能够通过统一的监控入口，监控所有的对象，当监控规模庞大到需要使用zabbix proxy

zabbix的逻辑关系图

zabbix监控环境中相关术语

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

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

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

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

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

6、动作（action）：指对于特定事件事先定义的处理方法，如发送通知，何时执行操作； 

7、报警升级（escalation）：发送警报或者执行远程命令的自定义方案，如每隔5分钟发送一次警报，共发送5次等； 

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

9、通知（notification）：通过选定的媒介向用户发送的有关某事件的信息； 

10、远程命令（remote command）：预定义的命令，可在被监控主机处于某特定条件下时自动执行； 

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

12、应用（application）：一组item的集合； 

13、web场景（web scennario）：用于检测web站点可用性的一个活多个HTTP请求； 

14、前端（frontend）：Zabbix的web接口；

zabbix的流程图，其串联了各术语之间的关系

那么zabbix能够支持哪些通讯方式呢，总结如下：

agent：通过专用的代理程序进行监控，与常见的master/agent模型类似,如果被监控对象支持对应的agent，推荐首选这种方式。

ssh/telnet：通过远程控制协议进行通讯，比如ssh或者telnet。

SNMP：通过SNMP协议与被监控对象进行通讯，SNMP协议的全称为Simple NetworkManagement Protocol ,被译为 "简单网络管理协议"，通常来说，我们无法在路由器、交换机这种硬件上安装agent，但是这些硬件往往都支持SNMP协议，SNMP是一种比较久远的、通行的协议，大部分网络设备都支持这种协议，其实SNMP协议的工作方式也可以理解为master/agent的工作方式，只不过是在这些设备中内置了SNMP的agent而已，所以，大部分网络设备都支持这种协议。

IPMI：通过IPMI接口进行监控，我们可以通过标准的IPMI硬件接口，监控被监控对象的物理特征，比如电压，温度，风扇状态，电源状态等。

JMX：通过JMX进行监控，JMX（Java Management Extensions，即Java管理扩展），监控JVM虚拟机时，使用这种方法也是非常不错的选择。

我们再来聊聊zabbix的工作模式

我们知道，agent端会将采集完的数据主动发送给server端，这种模式我们称之为主动模式，即对于agent端来说是主动的。

其实，agent端也可以不主动发送数据，而是等待server过来拉取数据，这种模式我们称之为被动模式。

聪明如你一定已经明白，不管是主动模式还是被动模式，都是对于agent端来说的，而且，主动模式与被动模式可以同时存在，并不冲突。

管理员可以在agent端使用一个名为zabbix_sender的工具，测试是否能够向server端发送数据。

管理员可以在server端使用一个名为zabbix_get的工具，测试是否能够从agent端拉取数据。

zabbix的监控架构

常用的监控架构平台 

1、server-agentd模式：

这个是最简单的架构了，常用于监控主机比较少的情况下。

2、server-proxy-agentd模式：

这个常用于比较多的机器，使用proxy进行分布式监控，有效的减轻server端的压力。

本文转自 工运搬运维 51CTO博客，原文链接：http://blog.51cto.com/13157015/2044519，如需转载请自行联系原作者