【51CTO.com原创稿件】 IT 运维离不开系统监控，就好像鱼儿离不开水一样。一款强大的监控系统可以有力保证设备和业务的稳定。
图片来自 Pexels
在监控系统层出不穷的今天，作为老牌监控系统的 Zabbix 依然屹立在监控系统之林。今天，我们来看看 Zabbix 的系统架构以及运作方式。
Zabbix 系统架构
众所周知，Zabbix 是一款优秀的监控系统，可以针对互联网中的设备和应用进行监控。
在详细介绍其实现方式之前，先来看看它的结构图：
Zabbix 架构图
从上图可以看出，绿色的部分就是被监控的设备，这个设备的类型可以是服务器，交换机或者是网络打印机。
这些被监控的设备被称作为 Host，设备的分组称作 Host Group，分组可以根据地域，机房，应用来划分。
从橙色部分-监控方式可以看出，针对每个 Host，Zabbix 会安装 Zabbix Agent。
它是 Zabbix 在 Host 上的客户端，负责将 Zabbix 需要监控的信息上传到 Zabbix Server 进行分析和处理。
但并不是所有的网络设备都可以安装 Zabbix Agent，针对无法安装的设备，只要支持 SNMP(Simple Network Management Protocol，简单网络管理协议)或者 IPMI(Intelligent Platform Management Interface，智能平台管理接口)也是可以被监控到的。
另外，如果需要监控 Java 应用程序，也可以通过 JMX 来实现。
同样从橙色部分监控内容可以看出，Zabbix 通过 JMX 支持 Java 应用程序监控;通过 IPMI 支持硬件设备监控;通过 SNMP 支持网络设备。
绿色区域与蓝色的 Zabbix Server 之间有一个双向的箭头，由 Zabbix Agent 直接到 Zabbix Server 的方式被称为通用结构，类似常说的 C/S 架构。
但在实际应用中更多的使用分布式架构，也就是通过绿色区域先连接到黄色的 Zabbix Proxy，然后再连接到蓝色 Zabbix Server 的这条路径。
在图右边橙色的区域，是Zabbix的监控服务器，其中 Zabbix Server 主要负责配置和接受/发送监控信息(更多详细功能后面介绍)。
处理完毕的信息会存储到 Database 中，这里的 Database 可以指定 MySQL 或者 Oracle 以及其他数据库源。
另外，还会提供 Zabbix UI 展示配置和监控信息。不仅如此，还为第三方应用提供了 Zabbix API，通过它来客制化 Zabbix 规则。
当然从稳定性考虑，可以通过 Keepalive 之类的软件建立 Master，Slave 的 HA 机制。
Zabbix 构建监控系统过程
前面通过一张大图介绍了 Zabbix 的体系结构，详细对 Zabbix 的基本工作原理有了了解。
顺着这个思路再来看看，Zabbix 架构安装和配置步骤：
Zabbix 架构部署和配置示意图
PS：下面会介绍 Zabbix 的整个部署和配置过程，涉及到安装和配置的部分，都没有标注具体的命令。
如果有需要安装和配置过程的同学，可以下载 Zabbix 用户手册，这里因为篇幅的原因不展开描述。
Zabbix Server/Agent/UI 安装配置
在 Zabbix 监控服务器上，安装 Zabbix Server 和 Zabbix UI(Web)。
Zabbix Server 用来接受和发送监控详细，Zabbix UI(Web)用来对 Zabbix Server 的各项功能进行配置。
同时在被监控设备上，安装 Zabbix Agent。在其安装完毕以后，需要通过 zabbix_agenttd.conf 文件，对 Server 和 ServerActive 两个参数进行配置。
由于 Zabbix Agent 有被动模式和主动模式。被动模式，是 Zabbix Server 从 Zabbix Agent 上获取数据。
而主动模式，是 Zabbix Agent 主动将信息上传到 Zabbix Server。因此，这两个参数的内容都指的是 Zabbix Server 的 IP 地址。
Server 配置的是被动模式 Zabbix Server 的 IP，ServerActive 配置的是主动模式 Zabbix Server 的 IP。
当然，除此之外还需要更新防火墙配置，并打开 Zabbix 的访问端口(10050 和 10051)。
最后，给这个被监控的设备(Host)，起一个 Hostname，这个名字会在 Zabbix Server 端配置的时候用到。
Server 和 ServerActive 配置项
Host Groups/Hosts 配置
搞定 Zabbix Agent 以后，回到 Zabbix Server 上进行配置。前提是 Zabbix Server 和 Zabbix UI(Web)已经安装完毕，可以通过 Zabbix UI(Web)访问配置界面。
上文提到，每个被监控的设备，都是一个 Host，那么将多个 Host 按照某种方式分组，这个分组就是 Host Groups。这里的分组方式有地理位置，业务单位，机器用途，系统版本等等。
建立一个 Host Groups，然后在其中建立一个 Host，这个 Host 就是刚才安装 Zabbix Agent 的设备在 Zabbix Server 上的概念设备。
在配置 Host 的时候，需要注意这里的 HostName 和被监控设备中定义的 HostName 保持一致，方便辨识。配置的 IP 就是被监控设备的 IP，端口号是 10050。
在 Zabbix Server 创建 Host 配置
Items 配置
配置完 Host 之后，就需要告诉 Zabbix 监控 Host 中的什么数据。这个要监控的数据就是监控项，也叫 Items。
Items 配置包括监控数据的方式，取值的数据类型，获取数值的间隔，历史数据保存时间，趋势数据保存时间，监控 Key 的分组等信息。
首选，需要选择 Type，它是要监听的 Zabbix 客户端的类型。一般来说，在安装 Zabbix Agent 以后，这个类型就是 Zabbix Agent。也可以选择 SNMP，IMPI 或者其他类型。
其次，需要注意 Key 的选择，Key 是来确定具体监控项的，对于同一个 Host 来说它是唯一的。
Zabbix 默认就带有一些 Key 可供选择，例如：vm.memory.size[total]，就是获取内存大小的 Key。
由于是针对 Host 进行配置的，所以也会指定对应的 Host IP 和 Port。另外，还有一些其他的数据需要配置。
例如：数据更新间隔，更新周期，历史数据保存天数，趋势数据保存天数等等。
Items 配置示例图
细心的同学会发现上图中还有一个 Applications 的选项。它实际上是对 Items 的一个集合，例如：要监控 MySQL，可以定义一个 MySQL 的 Application。
把相关的 Items 包括 availability of MySQL，disk space，processor load，transactions per second，number of slow queries 全部放到这个 Application 中方便选择和管理。
Trigger 配置
前面提到，Items 是用来配置监控什么数据的，而不判断数据是否正常。那么，Trigger 的作用就是对采集的数据进行判断。
通常会设置判断规则或者阀值，一旦满足某种规则或者超过对应的阀值就会产生一个事件。
同时，Action 会对满足条件的 Trigger 执行操作。这些规则通过正则表达式来定义。
从接收消息到触发动作示意图
信息经过表达式判断，会产生两类 Trigger 状态，OK(正常)和 PROBLEM(异常)。
每个 Trigger 会对应一个 Items，每个 Items 会对应多个 Trigger。同时，Trigger 又可以设置不同的事件级别，可以根据这些级别设置多重告警。
Trigger 事件级别示意图
在配置 Trigger 的时候主要是添加正则表达式。Zabbix 会根据对应 Item 的 Function 生成对应的正则表达式。
Trigger 会根据监控的内容(Item)来配置，例如：Item 是检测 Linux 的登陆人数。选择 Item 为“Template OS linux：Number of logged in users”。
对应的 Function 是 Last(most recent) T value is = N。意思是获取最近登陆的人数 T，当 T 等于 N 的时候触发 Trigger。
这个 N 就是需要我们配置的值，比如填写 2。也就是登陆人数等于 2 的时候触发 Trigger。
当你配置完毕以后就会生成类似如下图正则表达式了，{Template OS Linux:system.users.num.last()}>2。
整个过程不需要你输入表达式，只要通过选择和配置就可以完成。
Trigger 配置示例图，内容和文中描述有差异，表达的意思相同
上图有一个 Tab 项叫做 Dependencies，这个是 Trigger 的告警依赖，在实际场景中非常有用。
它会针对特殊场景使用，例如：整个 IDC 机房的路由出现故障，那么机房所有的机器的网络状态都会出现异常，此时 Zabbix Server 会收到大量异常报警。运维人员会被报警信息淹没，不知道故障的真正原因。
此时，就可以在 Dependencies 中选择对应规则，并且勾选 Multiple PROBLEM events generation 选项。
之后，就会收到一条报警信息，“某某 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”条件，将 Maintenance status not in maintenance (机器不在维护状态)和 Trigger value = PROBLEM(触发器异常)两个条件(Condition)组合起来，意思是当两个条件同时满足时触发后续操作。
Conditions 是配置示例图
最后，就是操作(Operation)的配置。包括执行操作的时间间隔，执行次数，每次执行的间隔，操作类型(发送消息，执行命令)，发送给哪些用户/用户组等等。
Operation 配置示例图
Template 配置
如果有很多监控设备需要配置，是有工作量的。于是，Zabbix 会将有相同 Item，Trigger，Application 等规则项放到一起，于是就有了模版(Template)。
当对同类型的设备需要配置监控项时，就可以选择现成的模版。从而，减少运维工程师的工作量。在创建模版的时候，需要输入模版名字，以及对应的分组。
模版基本信息
如果需要继承模版，可以在 Linked template 中进行配置。模版继承可以理解为模板嵌套。
例如，事先定义了一个基础模板，Item 配置好了 CPU、内存、硬盘、网卡等信息。
如果需要在这个基础模版上扩展其他模版，比如：MySQL 监控模版或者 Web 监控模板。那么在配置模板的时候，就可以继承于基础模板，而不需要重新定义模版。
模版创建完毕后，就可以添加 Item，Trigger，Application 等信息，具体的方式类似 Item，Trigger 配置。
上面大段的文字讲述了 Zabbix 构建监控系统的过程。为了方便记忆，这里做个总结。
Zabbix 构建监控系统，先安装 Zabbix Agent 到 Host 收集信息，Zabbix Server 用来获取信息，Zabbix UI(Web)用来展示和配置信息。
Zabbix Agent 在 Host 中配置好监控服务器的 IP 和 Port 之后，回到 Zabbix Server 上，通过 Zabbix UI(Web)对要监控的 Host(被监控设备)进行配置。
依次配置：Item(监控什么数据)，Trigger(故障触发条件)，Action(故障触发动作)。
Zabbix 监控方式
了解完了 Zabbix 的架构和 Zabbix 构建的过程，再来看看 Zabbix 的监控方式。前面谈到的 Zabbix Agent 监控，只是 Zabbix 监控方式的一种。
针对不同情况，Zabbix 还提供了 SNMP，IPMI，JMX 等多种方式。即使是 Zabbix Agent 的方式，也分为主动和被动两种。
下图描述了 Zabbix 的几种监控方式与 Zabbix Server 之间的关系：
Zabbix 监控方式逻辑图
Zabbix Agent 监控方式
该方式有 Active(主动模式)和 Passive(被动模式)。Zabbix Server 和 Zabbix Agent 之间的通信是通过 Zabbix 专用协议完成的，数据格式为 JSON。
①Zabbix Agent 被动模式
默认情况下，Zabbix Agent 工作在被动模式下，是由 Zabbix Server 向 Zabbix Agent 获取信息。
在安装完 Zabbix Agent 以后，通过 zabbix_agentd.conf 文件中的 Server 参数，设置被动数据采集的 IP。
被动模式流程图
Zabbix Agent 与 Zabbix Server 通讯流程如上图：
- Zabbix Server 打开一个 TCP 连接。
- Server 发送一个 Key(agent.ping\n)给 Zabbix Agent。
- Zabbix Agent 接收到请求，并且响应请求，发送内容为
- 的信息给 Zabbix Server。
- Server 接收返回的数据，并且进行处理。
- Server 关闭 TCP 连接。
②Zabbix Agent 主动模式 这种模式 Zabbix Agent 会主动上报监控信息到 Zabbix Server。可以通过 zabbix_agentd.conf 文件中的 ActiveServer 参数配置 Zabbix Server 的 IP。 同时需要配置 Zabbix Server 上 Items 的 Type，设置为 Zabbix agent(active)即可。 主动模式流程图 依旧来看看主动流程图： SNMP 监控方式 它是一个标准的用于管理基于 IP 网络设备的协议，包括：路由器，交换机，UPS，打印机。特别是当被监控设备无法安装 Zabbix Agent 的时候。 先一起来看看 SNMP 的架构，如下图： SNMP 架构图 NMS 是 Network Management System(网络管理系统，又名网络管理站)，这部分被集成到了 Zabbix Server 中了。 Agent 是 SNMP 访问的代理，为设备提供 SNMP 的能力，负责设备与 NMS 进行通讯。 MIB(Management Information Base)是一个数据库，包含了被管理设备维护的变量。例如：内存空间，磁盘大小。 它通常是以一个树形结构存在的，每个叶子结点都保存一条数据，通过 OID(Object Identifier)唯一标识一条记录。 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(Intelligent Platform Management Interface)即智能平台管理接口，原本是 Intel 架构中企业系统的周边设备采用的一种工业标准，后来成为业界的通用标准。 用户可以通过 IPMI 监视服务器的物理特征，例如：温度，电压，电风扇工作状态，电源供应等。 IPMI 独立于 CPU BIOS 和操作系统，也就是在缺少操作系统和管理软件的情况下，依旧可以对硬件信息进行监控。在 Zabbix 中的具体配置，这里不展开描述。 JMX 监控方式 JMX(Java Management Extensions)是为 Java 应用程序植入管理功能的框架。也是一套标准的代理和服务，用户可以在任何 Java 应用程序中使用它。 在 Zabbix 中，JMX 监控数据的获取由专门的代理程序来实现，即 Zabbix Java Gateway 负责采集数据，它和 JMX 的 Java 程序之间通信获取数据。 Zabbix-Server 和 Zabbix Java Gateway 如下图所示： JMX 示意图 这里需要几个步骤部署 JMX，如下： 总结 作为老牌的监控系统，Zabbix 的架构包括了被监控设备和 Zabbix 监控服务器两大部分。 Zabbix Agent 运行在被监控设备上，负责和 Zabbix Server 通信获取和控制被监控设备，它有主动和被动两种工作模式。 Zabbix Server 作为监控核心，可以直接与 Zabbix Agent 连接也可以通过 Zabbix Proxy 进行连接，再由 Zabbix Proxy 连接 Zabbix Agent。后面这种方式用在分布式监控的场景。 Zabbix Server 获取的数据存放到 Zabbix Server 的数据库中，Zabbix UI(Web)可以读取服务器中的数据，通过图表的方式展示出来。 Zabbix 构建过程，分为安装 Zabbix Agent/Server/UI，Host 配置，Item 配置，Trigger 配置，Action 配置。 这个配置过程完美地回答了，“监控谁?监控什么?出现异常以后如何处理?”的问题。 最后，针对不同应用场景，Zabbix 还支持多种监控方式，有 Zabbix Agent，SNMP，IPMI 以及 JMX。 作者：崔皓 简介：十六年开发和架构经验，曾担任过惠普武汉交付中心技术专家，需求分析师，项目经理，后在创业公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构与研发管理。 
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
