银行Zabbix系统监控架构设计
案例 | 银行 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，例如以下我们目前对各产品使用的监控方式：方式产品工具CLIunityuemcliCLIvnxnaviseccilRESTfulVMAXrequests(Python)SSHV7000OpenSSH除了跟厂家沟通对接 Zabbix 外，其实也可以借助开源生态和 Zabbix 的合作推广，也有很多企业与我们一样会分享 Zabbix 的经验、模板、工具到 Zabbix Share，可以斟酌筛选后使用。同时，Zabbix 也一直努力与其他厂家共同合作，共同推出每个厂家在 Zabbix 上的官方监控模板，例如 DELL EMC 在 Zabbix 中推出的各个产品的监控模板（通过上述的监控方式，Zabbix 对生产环境存储设备的监控效果让运维人员感到比较满意，agentless 的架构避免对重要设备的侵入，同时相关的存储告警也能够及时触发，并帮助存储管理人员迅速发现问题、定位原因。四 主机监控我们目前的主机监控主要包含了 Power 的小型机和 x86 的 ESXi，这类对象有一非常明显的特点，就是数量和信息不固定。一台小型机可能需要为新部署的数据库划分物理分区或虚拟分区，亦或者要调整某个数据库的 CPU 分配；一个 vSphere 集群可能会扩容 ESXi 主机数量或资源，亦或新建一个集群。在这种多变的的环境里，首先考虑的是使用 Zabbix 的自动发现来适配，并且此场景有一个非常明显的相似特性，就是需要一个主控端来管理整个主机资源池。因此，我们对主机的监控常常采用的原则是，通过监控主控端来自动发现主机，让被发现的主机自动使用对应模板。在这里插入图片描述上述的监控流程主要是依赖 Zabbix 的自动注册主机来实现，不同于硬件监控中提及的自动注册监控项，这里的自动注册会直接根据主控端获取的资源列表，自动注册一个待监控的主机，相关的主机配置包括主机名、可见名称、agent 接口等都会继承主控，然后会为每个主机都绑定一个预先配置的监控模板。如果主控端发现某一个主机不在上一次收集的资源列表中，会在超过资源保留策略时间后，自动删除该主机。例如自动发现的 ESXi 主机：在这里插入图片描述五 操作系统监控操作系统的监控是非常庞大的，除了操作系统种类多，每个操作系统内的监控项数量也是覆盖面广，再乘上物理机、虚拟机的数量，整个监控面积会非常之大。另外，将每一台服务器纳管至 Zabbix 中的操作也变得异常繁琐。对此，我们保持的思路是，通过自动化手段让服务器自动上报到 Zabbix，优化模板以减少重复监控，定制触发器的依赖关系。操作系统的监控都是使用 Zabbix Agent 方案来实现的，Zabbix 也推出了各种操作系统的 agent，不需要编译就能直接运行。对此，我们的所有虚拟机基线、小型机备份、物理机 Ansible 部署脚本里，都会事先准备好对应操作系统的 Agent 安装和配置。其中，推荐使用被动方式，并且主要修改 agent 配置的如下内容：# .# 众多 Zabbix Proxy 中
