|
在监控系统层出不穷的今天，作为老牌监控系统的 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 配置示例图
上面大段的文字讲述了 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 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。 作者：崔皓 简介：十六年开发和架构经验，曾担任过惠普武汉交付中心技术专家，需求分析师，项目经理，后在创业公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构与研发管理。
| 
