“IT运维离不开系统监控，就好像鱼儿离不开水一样。一款强大的监控系统可以有力保证设备和业务的稳定。
图片来自Pexels在监控系统层出不穷的今天，作为老牌监控系统的Zabbix依然屹立在监控系统之林。今天，我们来看看Zabbix的系统架构以及运作方式。
Zabbix系统架构
众所周知，Zabbix是一款优秀的监控系统，可以针对互联网中的设备和应用进行监控。
在详细介绍其实现方式之前，先来看看它的结构图：
Zabbix架构图从上图可以看出，绿色的部分就是被监控的设备，这个设备的类型可以是服务器，交换机或者是网络打印机。
这些被监控的设备被称作为Host，设备的分组称作HostGroup，分组可以根据地域，机房，应用来划分。
从橙色部分-监控方式可以看出，针对每个Host，Zabbix会安装ZabbixAgent。
它是Zabbix在Host上的客户端，负责将Zabbix需要监控的信息上传到ZabbixServer进行分析和处理。
但并不是所有的网络设备都可以安装ZabbixAgent，针对无法安装的设备，只要支持SNMP（SimpleNetworkManagementProtocol，简单网络管理协议）或者IPMI（IntelligentPlatformManagementInterface，智能平台管理接口）也是可以被监控到的。
另外，如果需要监控Java应用程序，也可以通过JMX来实现。
同样从橙色部分监控内容可以看出，Zabbix通过JMX支持Java应用程序监控；通过IPMI支持硬件设备监控；通过SNMP支持网络设备。
绿色区域与蓝色的ZabbixServer之间有一个双向的箭头，由ZabbixAgent直接到ZabbixServer的方式被称为通用结构，类似常说的C/S架构。
但在实际应用中更多的使用分布式架构，也就是通过绿色区域先连接到黄色的ZabbixProxy，然后再连接到蓝色ZabbixServer的这条路径。
在图右边橙色的区域，是Zabbix的监控服务器，其中ZabbixServer主要负责配置和接受/发送监控信息（更多详细功能后面介绍）。
处理完毕的信息会存储到Database中，这里的Database可以指定MySQL或者Oracle以及其他数据库源。
另外，还会提供ZabbixUI展示配置和监控信息。不仅如此，还为第三方应用提供了ZabbixAPI，通过它来客制化Zabbix规则。
当然从稳定性考虑，可以通过Keepalive之类的软件建立Master，Slave的HA机制。
Zabbix构建监控系统过程
前面通过一张大图介绍了Zabbix的体系结构，详细对Zabbix的基本工作原理有了了解。
顺着这个思路再来看看，Zabbix架构安装和配置步骤：
Zabbix架构部署和配置示意图PS：下面会介绍Zabbix的整个部署和配置过程，涉及到安装和配置的部分，都没有标注具体的命令。
如果有需要安装和配置过程的同学，可以下载Zabbix用户手册，这里因为篇幅的原因不展开描述。
ZabbixServer/Agent/UI安装配置
在Zabbix监控服务器上，安装ZabbixServer和ZabbixUI（Web）。
ZabbixServer用来接受和发送监控详细，ZabbixUI（Web）用来对ZabbixServer的各项功能进行配置。
同时在被监控设备上，安装ZabbixAgent。在其安装完毕以后，需要通过zabbix_agenttd.conf文件，对Server和ServerActive两个参数进行配置。
由于ZabbixAgent有被动模式和主动模式。被动模式，是ZabbixServer从ZabbixAgent上获取数据。
而主动模式，是ZabbixAgent主动将信息上传到ZabbixServer。因此，这两个参数的内容都指的是ZabbixServer的IP地址。
Server配置的是被动模式ZabbixServer的IP，ServerActive配置的是主动模式ZabbixServer的IP。
当然，除此之外还需要更新防火墙配置，并打开Zabbix的访问端口（和）。
最后，给这个被监控的设备（Host），起一个Hostname，这个名字会在ZabbixServer端配置的时候用到。
Server和ServerActive配置项HostGroups/Hosts配置
搞定ZabbixAgent以后，回到ZabbixServer上进行配置。前提是ZabbixServer和ZabbixUI（Web）已经安装完毕，可以通过ZabbixUI（Web）访问配置界面。
上文提到，每个被监控的设备，都是一个Host，那么将多个Host按照某种方式分组，这个分组就是HostGroups。这里的分组方式有地理位置，业务单位，机器用途，系统版本等等。
建立一个HostGroups，然后在其中建立一个Host，这个Host就是刚才安装ZabbixAgent的设备在ZabbixServer上的概念设备。
在配置Host的时候，需要注意这里的HostName和被监控设备中定义的HostName保持一致，方便辨识。配置的IP就是被监控设备的IP，端口号是。
在ZabbixServer创建Host配置Items配置
配置完Host之后，就需要告诉Zabbix监控Host中的什么数据。这个要监控的数据就是监控项，也叫Items。
Items配置包括监控数据的方式，取值的数据类型，获取数值的间隔，历史数据保存时间，趋势数据保存时间，监控Key的分组等信息。
首选，需要选择Type，它是要监听的Zabbix客户端的类型。一般来说，在安装ZabbixAgent以后，这个类型就是ZabbixAgent。也可以选择SNMP，IMPI或者其他类型。
其次，需要注意Key的选择，Key是来确定具体监控项的，对于同一个Host来说它是唯一的。
Zabbix默认就带有一些Key可供选择，例如：vm.memory.size[total]，就是获取内存大小的Key。
由于是针对Host进行配置的，所以也会指定对应的HostIP和Port。另外，还有一些其他的数据需要配置。
例如：数据更新间隔，更新周期，历史数据保存天数，趋势数据保存天数等等。
Items配置示例图细心的同学会发现上图中还有一个Applications的选项。它实际上是对Items的一个集合，例如：要监控MySQL，可以定义一个MySQL的Application。
把相关的Items包括availabilityofMySQL，diskspace，processorload，transactionspersecond，numberofslowqueries全部放到这个Application中方便选择和管理。
Trigger配置
前面提到，Items是用来配置监控什么数据的，而不判断数据是否正常。那么，Trigger的作用就是对采集的数据进行判断。
通常会设置判断规则或者阀值，一旦满足某种规则或者超过对应的阀值就会产生一个事件。
同时，Action会对满足条件的Trigger执行操作。这些规则通过正则表达式来定义。
从接收消息到触发动作示意图信息经过表达式判断，会产生两类Trigger状态，OK（正常）和PROBLEM（异常）。
每个Trigger会对应一个Items，每个Items会对应多个Trigger。同时，Trigger又可以设置不同的事件级别，可以根据这些级别设置多重告警。
Trigger事件级别示意图在配置Trigger的时候主要是添加正则表达式。Zabbix会根据对应Item的Function生成对应的正则表达式。
Trigger会根据监控的内容（Item）来配置，例如：Item是检测Linux的登陆人数。选择Item为“TemplateOSlinux：Numberofloggedinusers”。
对应的Function是Last(mostrecent)Tvalueis=N。意思是获取最近登陆的人数T，当T等于N的时候触发Trigger。
这个N就是需要我们配置的值，比如填写2。也就是登陆人数等于2的时候触发Trigger。
当你配置完毕以后就会生成类似如下图正则表达式了，{TemplateOSLinux:system.users.num.last()}2。
整个过程不需要你输入表达式，只要通过选择和配置就可以完成。
Trigger配置示例图，内容和文中描述有差异，表达的意思相同
上图有一个Tab项叫做Dependencies，这个是Trigger的告警依赖，在实际场景中非常有用。
它会针对特殊场景使用，例如：整个IDC机房的路由出现故障，那么机房所有的机器的网络状态都会出现异常，此时ZabbixServer会收到大量异常报警。运维人员会被报警信息淹没，不知道故障的真正原因。
此时，就可以在Dependencies中选择对应规则，并且勾选MultiplePROBLEMeventsgeneration选项。
之后，就会收到一条报警信息，“某某IDC机房路由器X发生故障”，对其他的报警信息做了聚合操作。
Action配置
如果说Trigger定义触发事件的规则，那么Action就是事件触发后的动作。即当Trigger条件被满足以后，Action会执行一些操作。
比如：发送事件通知（短信，钉钉，邮件），远程执行命令（重启服务）。
Action的配置需要遵从下图几个步骤：
Zabbix中有多种事件类型，Trigger只是其中一种，例如：自动发现监控设备，自动注册监控设备等等。因此，先要选择事件的来源，当然这里我们选择Trigger作为来源。
Action选择事件来源
然后，填写Action的基本信息。例如：名字，主题，默认发送的信息内容，异常恢复主题，以及对应的信息内容。这里的填写可以是字符串，但是更多的会使用宏。
其实就是替换字符，比如{TRIGGER.STATUS}表示触发器的状态，{ITEM.NAME}表示监控项的名字。通过这些宏和字符串的拼接形成最终的信息。
如下图显示：
Action基本信息
接下来，就是对条件的配置（Condition）。由于Action可以面对一个或者多个Trigger，每日每个Trigger又有一个或者多个条件。
为了保证其灵活性，可以针对AND，OR，AND/OR，对条件进行组合。
例如：可以用“AND”条件，将Maintenancestatusnotinmaintenance（机器不在维护状态）和Triggervalue=PROBLEM（触发器异常）两个条件（Condition）组合起来，意思是当两个条件同时满足时触发后续操作。
Conditions是配置示例图最后，就是操作（Operation）的配置。包括执行操作的时间间隔，执行次数，每次执行的间隔，操作类型（发送消息，执行命令），发送给哪些用户/用户组等等。
Operation配置示例图Template配置
如果有很多监控设备需要配置，是有工作量的。于是，Zabbix会将有相同Item，Trigger，Application等规则项放到一起，于是就有了模版（Template）。
当对同类型的设备需要配置监控项时，就可以选择现成的模版。从而，减少运维工程师的工作量。在创建模版的时候，需要输入模版名字，以及对应的分组。
模版基本信息
如果需要继承模版，可以在Linkedtemplate中进行配置。模版继承可以理解为模板嵌套。
例如，事先定义了一个基础模板，Item配置好了CPU、内存、硬盘、网卡等信息。
如果需要在这个基础模版上扩展其他模版，比如：MySQL监控模版或者Web监控模板。那么在配置模板的时候，就可以继承于基础模板，而不需要重新定义模版。
模版创建完毕后，就可以添加Item，Trigger，Application等信息，具体的方式类似Item，Trigger配置。
上面大段的文字讲述了Zabbix构建监控系统的过程。为了方便记忆，这里做个总结。
Zabbix构建监控系统，先安装ZabbixAgent到Host收集信息，ZabbixServer用来获取信息，ZabbixUI（Web）用来展示和配置信息。
ZabbixAgent在Host中配置好监控服务器的IP和Port之后，回到ZabbixServer上，通过ZabbixUI（Web）对要监控的Host（被监控设备）进行配置。
依次配置：Item（监控什么数据），Trigger（故障触发条件），Action（故障触发动作）。
Zabbix监控方式
了解完了Zabbix的架构和Zabbix构建的过程，再来看看Zabbix的监控方式。前面谈到的ZabbixAgent监控，只是Zabbix监控方式的一种。
针对不同情况，Zabbix还提供了SNMP，IPMI，JMX等多种方式。即使是ZabbixAgent的方式，也分为主动和被动两种。
下图描述了Zabbix的几种监控方式与ZabbixServer之间的关系：
Zabbix监控方式逻辑图ZabbixAgent监控方式
该方式有Active（主动模式）和Passive（被动模式）。ZabbixServer和ZabbixAgent之间的通信是通过Zabbix专用协议完成的，数据格式为JSON。
①ZabbixAgent被动模式
默认情况下，ZabbixAgent工作在被动模式下，是由ZabbixServer向ZabbixAgent获取信息。
在安装完ZabbixAgent以后，通过zabbix_agentd.conf文件中的Server参数，设置被动数据采集的IP。
被动模式流程图ZabbixAgent与ZabbixServer通讯流程如上图：
ZabbixServer打开一个TCP连接。Server发送一个Key（agent.ping\n）给ZabbixAgent。ZabbixAgent接收到请求，并且响应请求，发送内容为HEADERDATALEN的信息给ZabbixServer。Server接收返回的数据，并且进行处理。Server关闭TCP连接。
②ZabbixAgent主动模式
这种模式ZabbixAgent会主动上报监控信息到ZabbixServer。可以通过zabbix_agentd.conf文件中的ActiveServer参数配置ZabbixServer的IP。
同时需要配置ZabbixServer上Items的Type，设置为Zabbixagent(active)即可。
主动模式流程图依旧来看看主动流程图：
ZabbixAgent向ZabbixServer建立一个TCP连接。Agent请求需要检测的数据列表。Server响应Agent，发送一个Items列表，包括Itemkey和delay。Agent响应请求。Server接收请求数据，关闭TCP。
SNMP监控方式
它是一个标准的用于管理基于IP网络设备的协议，包括：路由器，交换机，UPS，打印机。特别是当被监控设备无法安装ZabbixAgent的时候。
先一起来看看SNMP的架构，如下图：
SNMP架构图NMS是NetworkManagementSystem（网络管理系统，又名网络管理站），这部分被集成到了ZabbixServer中了。
Agent是SNMP访问的代理，为设备提供SNMP的能力，负责设备与NMS进行通讯。
MIB（ManagementInformationBase）是一个数据库，包含了被管理设备维护的变量。例如：内存空间，磁盘大小。
它通常是以一个树形结构存在的，每个叶子结点都保存一条数据，通过OID（ObjectIdentifier）唯一标识一条记录。
MIB树形结构图例如上图，想表示通用中的System参数，就通过1.3.6.1.2.1.1。如果是私人企业的记录，就是在1.3.6.1.4.1下面。
NMS通过SNMP与设备上的Agent进行通信，获取/修改MIB上面的信息。目前SNMP有三个版本，每个版本都在之前版本的基础上逐步升级。
SNMP版本示例图以第三个版本为例，在原来请求和响应的基础上，加入PDU算法对报文进行了加密和解密操作。
SNMPv3版本传输示意图IPMI监控方式
IPMI（IntelligentPlatformManagementInterface）即智能平台管理接口，原本是Intel架构中企业系统的周边设备采用的一种工业标准，后来成为业界的通用标准。
用户可以通过IPMI监视服务器的物理特征，例如：温度，电压，电风扇工作状态，电源供应等。
IPMI独立于CPUBIOS和操作系统，也就是在缺少操作系统和管理软件的情况下，依旧可以对硬件信息进行监控。在Zabbix中的具体配置，这里不展开描述。
JMX监控方式
JMX（JavaManagementExtensions）是为Java应用程序植入管理功能的框架。也是一套标准的代理和服务，用户可以在任何Java应用程序中使用它。
在Zabbix中，JMX监控数据的获取由专门的代理程序来实现，即ZabbixJavaGateway负责采集数据，它和JMX的Java程序之间通信获取数据。
Zabbix-Server和ZabbixJavaGateway如下图所示：
JMX示意图这里需要几个步骤部署JMX，如下：
选择单独的Server安装ZabbixJavaGateway，最好和ZabbixServer在不同的服务器上。在安装ZabbixJavaGateway的服务器上，针对zabbix_java_gateway.conf文件进行参数配置。主要是Gateway的监听服务器的IP和Port。目的是让Gateway找到要监听的设备。在ZabbixServer配置zabbix_server.conf的参数。主要是配置Gateway的IP和Port，以及Java监控的进程数。目的是让Server找到Gateway。在被监控设备上，针对Java应用开启JMX协议。回到ZabbixUI（Web）配置JMX监控的Java应用。
总结
作为老牌的监控系统，Zabbix的架构包括了被监控设备和Zabbix监控服务器两大部分。
ZabbixAgent运行在被监控设备上，负责和ZabbixServer通信获取和控制被监控设备，它有主动和被动两种工作模式。
ZabbixServer作为监控核心，可以直接与ZabbixAgent连接也可以通过ZabbixProxy进行连接，再由ZabbixProxy连接ZabbixAgent。后面这种方式用在分布式监控的场景。
ZabbixServer获取的数据存放到ZabbixServer的数据库中，ZabbixUI（Web）可以读取服务器中的数据，通过图表的方式展示出来。
Zabbix构建过程，分为安装ZabbixAgent/Server/UI，Host配置，Item配置，Trigger配置，Action配置。
这个配置过程完美地回答了，“监控谁？监控什么？出现异常以后如何处理？”的问题。
最后，针对不同应用场景，Zabbix还支持多种监控方式，有ZabbixAgent，SNMP，IPMI以及JMX。