案例|银行 | Zabbix 监控架构分享

编者荐语：
作者所在的某城商行顺利完成应用系统监控迁移到 Zabbix平台，将从架构部署、监控维度、自动化方案、运营管理层面，分享Zabbix 系统发展壮大的经验。本文作者也在"Zabbix技术交流群“，欢迎加入交流。
 

一 Zabbix 平台概述

 

平台介绍

Zabbix 是一个基于 Web 界面提供分布式系统监视及网络监视功能的企业级开源解决方案。它能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位、解决存在的各种问题，借助Zabbix 可很轻松地减轻运维人员繁重的服务器管理任务，保证业务系统持续运行。其后端使用数据库存储监控配置和历史数据，可以非常方便地对接数据分析、报表定制等渠道，在前端开放了丰富的 RESTful API 供第三方平台调用，整体架构在当下的 DevOps 的趋势下显得非常亮眼。
 

选型过程

我们于 2017 年开始接触 Zabbix，之前运维内主要使用的监控系统是 Nagios，但 Nagios 的页面展示、监控配置、自动化等各项功能对基础架构的运维人员来说不是特别友好，而风头正劲的 Zabbix 正好引起了我们的注意。基础架构的运维工作中，需要面对各种各样的监控场景，例如 PC 服务器的故障灯巡检、存储设备的阵列健康判断、小型机 LPAR 的资源监控、操作系统的多路径检查，等等。而 Zabbix 内置提供了 SNMP、IMPI、SSH、Agent 等多种监控途径，在系统架构的各层场景下都能很好的适配，其中 Agent 还支持自定义工具，总体的表现非常灵活。在网页前端管理上，Zabbix 可以满足各个粒度的监控管理，从整个集群到单独一个监控项都能够进行细分管控，自定义 dashboard 和历史数据可视化功能也极大地方便运维人员对监控数据的审查。综合以上的考虑因素，行内选择了 Zabbix 作为一个新的监控平台试点，从基础资源的监控出发，首先将大部分存储、主机和操作系统接管到 Zabbix。
 

使用现状

2017 年底在基础架构范围内试行的 Zabbix 系统，从 3.2 版本开始逐步演进到现在的 4.4 版本，其中经历了各项监控系统的里程碑事件。目前的 Zabbix 系统也由原先的小范围试用，逐步扩展到涵盖硬件、应用、平台、业务等更大范围的场景，架构上也从单数据中心进化为三中心的分布式部署。除了逐渐替代旧的监控系统，越来越多的第三方系统也开始对接起了 Zabbix，例如自动化运维平台、持续发布平台、运维可视化平台等，通过 API 或者数据库抽数的方式，使用海量的运维监控数据实现智能运维的工作模式。

在编写此文前不久，我们也顺利完成应用系统监控迁移到 Zabbix 平台，作为一名全程参与 Zabbix 系统推广实施和自动化开发的运维人员，非常荣幸能够见证我们运维力量的茁壮成长，在此，本人也将从架构部署、监控维度、自动化方案、运营管理层面，分享我们 Zabbix 系统发展壮大的经验。
 

二 硬件监控

数据中心的运维管理中，系统架构的纵向深度是非常陡长的，包括最基础的硬件设备也需要运维人员费尽心思地去巡检排查，但随着数据中心的设备数量呈爆发式增长，人工巡检已不能满足当下监控实时性、可靠性的要求。对于这种低层级的监控，Zabbix 的多维度特性就非常好的解决了这个问题，其内置的 SNMP/IPMI 协议能够轻松对接相关硬件设备的带外监控。

目前我们使用 SNMP Agent 的被动方式定期巡检硬件设备的基础指标，例如故障灯信号、电源功率、内存信息、磁盘阵列等，代替人工巡检的方式来实现异常捕获，并对数据中心内的所有设备做到硬件信息采集，定时更新至 CMDB。例如以下为部分华为 RH2288 V3 IBMC 监控模板中自动发现的配置：

Zabbix 配置硬件监控的操作过程也非常便捷，大部分都是在网页界面配置，只需要定义好 SNMP Agent/Trap 的接口或 IPMI 传感器目标端口后即可灵活定义监控项。对于 IPMI 监控的配置，主要是将传感器的名称填入即可，目前我们对 IPMI 的带外监控使用的相对较少，主要是部分浪潮 PC 服务器在使用，对 IPMI 更多地考虑应用于在如 VMware vSphere 的 DPM 等带外管理上。

在硬件监控选择监控协议时，保持的一项原则是：能用 SNMP 就不用其他，能用 SNMPv3 就不用 SNMPv2。
因为 SNMP 在 Zabbix 中可以非常灵活的实现自动发现，而 SNMPv3 可以提供更健壮的认证机制，因为在开放硬件监控的同时也必须考量网络安全的风险。对单个 SNMPv3 的监控项配置如下，大部分参数都提供了输入窗口：

对于上述提及的 SNMP 配置自动发现的灵活性，这也是依赖于 SNMP 设计的原理，借助树结构的索引方式，可以根据 index 字段枚举现有元素的数量，然后再根据数量长度来遍历下一层元素。对于这种遍历，Zabbix 自身提供了友好的 discovery[{#SNMPVALUE},OID] 函数来完成，无缝对接到内部通用的自动发现数据结构。整个 SNMP 自动发现的机制原理如下

由于我们 Zabbix 的起步试点是从基础设施运维开始，加上 Zabbix 对 SNMP/IPMI 协议配置的操作非常方便，所以经常可以根据厂家提供的 mib 文件及 mib 文档说明即可筛选出需要自定义的监控，这样既可以通过减少采集来降低管理系统的繁忙度，又能优化监控质量。例如以下为根据 Lenovo XCC 带外管理系统的 mib 说明（http://www.circitor.fr/Mibs/Html/L/LENOVO-XCC-MIB.php）来自定义配置的 ThinkSystem SR650 的 SNMPv3 监控使用效果：

上图中的电源、阵列、磁盘等均是通过自动发现的规则来生成的，这对拥有不同阵列卡数量、网卡数量、路数等的 XCC 带外服务器，都可以使用同一个模板，设备变化完全交给 Zabbix 维护。另外，分享一个定制 SNMP 监控过程中的经验，首先在 MIB 文件中收集所有需要监控的指标，对筛选的指标做分组，找到每个组的最高父级索引的 OID，然后在 Zabbix Proxy 上使用 snmpwalk 遍历这个 OID 找到所有 OID 内容，区分出 Index 和 Detail 后，划分常规监控和自动发现监控，最后使用 snmpget 来逐个获取 OID 的值确定对应 Zabbix 上的数值类型。需要特别注意，snmpwalk 是遍历，并不需要 OID 的完整值，而 snmpget 则是根据一个完整的 OID 来检索，对应于 Zabbix 则是 snmpwalk 类似自动发现，snmpget 类似常规监控项。
 

三 存储监控

在数据中心中，存储设备是非常核心且关键的基础设施，任何一个相关告警都会让运维人员警觉。在推进 Zabbix 的存储监控的过程中，体会到一个非常棘手的困难点，即存储不单单是硬件设备，SNMP 的协议不能获取到带内的性能信息，但也不像主流操作系统那样可以安装 Zabbix Agent 来做数据采集。对于这种问题的处理，我们积累的经验是，首选使用 RESTful 等外部接口来获取监控数据，在不支持此条件的情况下，在 Zabbix Proxy 服务器上通过自定义监控封装厂家推荐工具或方法来监控。

Zabbix Agent 支持运维人员自定义监控，将执行命令封装成一个 Zabbix Item Key 来供 Zabbix 调用，也支持额外的安全策略，例如 AllowRoot 可以设置是否允许 root 来执行 agent，UnsafeUserParameters 参数能够过滤特殊符号注入。我们对自定义配置的标准，以 RedHat 基线为例，在 /etc/zabbix/zabbix_agentd.d 目录一个监控类为一份 conf 文件的形式保存，命名形式为 ClassA_ClassB_Detail.conf，并且定义的执行文件均放置于 /usr/local/zbxexec/ClassA/ClassB/xxxx.xx。

对于自定义监控项的方法，能够便捷地对接各个存储厂家的产品监控方式，将厂家建议的监控命令封装为 Zabbix 的一个监控项。这类被封装的方法主要是 CLI、RESTful 和 SSH，例如以下我们目前对各产品使用的监控方式：
 

方式<