一、什么是zabbbix？
对于运维人员来说，监控是非常重要的，因为如果想要保证线上业务整体能够稳定运行，那么我们则需要实时关注与其相关的各项指标是否正常，而一个业务系统的背后，往往存在着很多的服务器、网络设备等硬件资源，如果我们想要能够更加方便的、集中的监控他们，我们则需要依靠一些外部的工具，而 zabbix 就是一个被广泛使用的，可以实现集中监控管理的应用程序。
我们监控的初衷就是当某些指标不符合我们的需求时，我们能够在第一时间发现异常，所以，监控工具需要定期的对被监控主机进行检查、信息收集等操作，当被监控主机出现异常时，能够及时报警、通知管理员，并且需要记录这些异常，以便我们分析这些数据，查漏补缺，那么，一个监控工具就应该具备采集信息、存储信息、展示信息、报警通知等功能，而 zabbix 就可以做到这些，除了 zabbix，你可能还听说过 cacti、nagios、ganglia 等类似的监控系统，但是此处，我们只聊 zabbix。
好了，我们大概了解了一下 zabbix，那么我们通过 zabbix 能够监控哪些硬件资源呢，理论上来说，只要是与我们的业务有关的硬件资源，都应该被监控，比如 主机、交换机、路由器、UPS 等等，但是，监控它们的前提是能与它们进行通讯，那么问题来了，由于硬件的不同，导致我们无法使用统一的方法去监控他们，这个时候，就需要监控程序有一定的通用性，或者说，监控程序需要能够与多种硬件设备通讯，才能满足我们的监控需求，举个例子：如果被监控的对象是一台安装了 linux 操作系统的服务器，那么我们可以通过 ssh 或者 telnet 这种远程工具与被监控对象建立起通讯的通道，可是如果被监控的对象是一台安装了其他操作系统的服务器呢，更甚之，被监控的对象并不是服务器，而只是一台交换机或者路由器呢，所以，zabbix 如果想要能够全面的监控这些对象，则需要能够通过各种方法与它们进行通讯。
那么 zabbix 能够支持哪些通讯方式呢，总结如下：
agent： 通过专用的代理程序进行监控，与常见的 master/agent 模型类似, 如果被监控对象支持对应的 agent，推荐首选这种方式。
ssh/telnet： 通过远程控制协议进行通讯，比如 ssh 或者 telnet。
SNMP： 通过 SNMP 协议与被监控对象进行通讯，SNMP 协议的全称为 Simple Network Management Protocol , 被译为 “简单网络管理协议”，通常来说，我们无法在路由器、交换机这种硬件上安装 agent，但是这些硬件往往都支持 SNMP 协议，SNMP 是一种比较久远的、通行的协议，大部分网络设备都支持这种协议，其实 SNMP 协议的工作方式也可以理解为 master/agent 的工作方式，只不过是在这些设备中内置了 SNMP 的 agent 而已，所以，大部分网络设备都支持这种协议。
IPMI： 通过 IPMI 接口进行监控，我们可以通过标准的 IPMI 硬件接口，监控被监控对象的物理特征，比如电压，温度，风扇状态，电源状态等。
JMX： 通过 JMX 进行监控，JMX（Java Management Extensions，即 Java 管理扩展），监控 JVM 虚拟机时，使用这种方法也是非常不错的选择。
好了，我们刚才提到了 zabbix agent，一般情况下，我们将 zabbix agent 部署到被监控主机上，由 agent 采集数据，报告给负责监控的中心主机，中心主机也就是 master/agent 模型中的 master，负责监控的中心主机被称为 zabbix server，zabbix server 将从 agent 端接收到的信息存储于 zabbix 的数据库中，我们把 zabbix 的数据库端称为 zabbix database， 如果管理员需要查看各种监控信息，则需要 zabbix 的 GUI，zabbix 的 GUI 是一种 Web GUI，我们称之为 zabbix web，zabbix web 是使用 php 编写的，所以，如果想要使用 zabbix web 展示相关监控信息，需要依赖 LAMP 环境，不管是 zabbix server ，或是 zabbix web，他们都需要连接到 zabbix database 获取相关数据，这样说可能不容易理解，对比下图理解上述概念，就容易许多
当监控规模变得庞大时，我们可能有成千上万台设备需要监控，这时我们是否需要部署多套 zabbix 系统进行监控呢？如果部署多套 zabbix 监控系统，那么监控压力将会被分摊，但是，这些监控的对象将会被尽量平均的分配到不同的监控系统中，这个时候，我们就无法通过统一的监控入口，去监控这些对象了，虽然分摊了监控压力，但是也增加了监控工作的复杂度，那么，我们到底该不该建立多套 zabbix 监控系统从而分摊巨大的监控压力呢？其实，zabbix 天生就有处理这种问题的能力，因为 zabbix 支持分布式监控，我们可以把成千上万台的被监控对象分成不同的区域，每个区域中设置一台代理主机，区域内的每个被监控对象的信息被 agent 采集，提交给代理主机，在这个区域内，代理主机的作用就好比 zabbix server，我们称这些代理主机为 zabbix proxy，zabbix proxy 再将收集到的信息统一提交给真正的 zabbix server 处理，这样，zabbix proxy 分摊了 zabbix server 的压力，同时，我们还能够通过统一的监控入口，监控所有的对象，当监控规模庞大到需要使用 zabbix proxy 时，zabbix 的架构如下图，我们可以对比下图，理解上述描述。
此处，我们再把刚才说到的各种组件总结一遍：
zabbix agent： 部署在被监控主机上，负责被监控主机的数据，并将数据发送给 zabbix server。
zabbix server: 负责接收 agent 发送的报告信息，并且负责组织配置信息、统计信息、操作数据等。
zabbix database： 用于存储所有 zabbix 的配置信息、监控数据的数据库。
zabbix web： zabbix 的 web 界面，管理员通过 web 界面管理 zabbix 配置以及查看 zabbix 相关监控信息，可以单独部署在独立的服务器上。
zabbix proxy： 可选组件，用于分布式监控环境中，zabbix proxy 代表 server 端，完成局部区域内的信息收集，最终统一发往 server 端。
了解完了 zabbix 的几个核心组件，我们再来聊聊 zabbix 的工作模式。
我们知道，agent 端会将采集完的数据主动发送给 server 端，这种模式我们称之为主动模式，即对于 agent 端来说是主动的。
其实，agent 端也可以不主动发送数据，而是等待 server 过来拉取数据，这种模式我们称之为被动模式。
聪明如你一定已经明白，不管是主动模式还是被动模式，都是对于 agent 端来说的，而且，主动模式与被动模式可以同时存在，并不冲突。
管理员可以在 agent 端使用一个名为 zabbix_sender 的工具，测试是否能够向 server 端发送数据。
管理员可以在 server 端使用一个名为 zabbix_get 的工具，测试是否能够从 agent 端拉取数据。
好了，我们已经了解了 zabbix 的一些基本概念，其实 zabbix 还有很多常用术语，但是现在我们并没有遇到实际的使用场景，空口白话的描述显得特别无力，而且难以理解，我们就先不管它们了，等到用到它们的时候，我们再做解释。
直达链接：zabbix安装