银行 Zabbix 监控架构

Zabbix平台概述

平台介绍

Zabbix是一个基于Web界面提供分布式系统监视及网络监视功能的企业级开

源解决方案.它能监视各种网络参数，保证服务器系统的安全运营，并提供灵活

的通知机制以让系统管理员快速定位、解决存在的各种问题，借助Zabbix可很

轻松地减轻运维人员繁重的服务器管理任务，保证业务系统持续运行。其后端使

用数据库存储监控配置和历史数据，可以非常方便地对接数据分析、报表定制等

渠道，在前端开放了丰富的RESTfulAPI供第三方平台调用，整体架构在当下的

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协议能够轻松对接相关硬件设备的带外监控。

目前我们使用SNMPAgent的被动方式定期巡检硬件设备的基础指标，例如故

障灯信号、电源功率、内存信息、磁盘阵列等，代替人工巡检的方式来实现异常

捕获，并对数据中心内的所有设备做到硬件信息采集，定时更新至CMDB。例如

以下为部分华为RH2288V3IBMC监控模板中自动发现的配置：

自动发现规则

10G8HUAWEIPCV3OMC.研霰»日沟发就败2

□8,盆及耍MSfift主机

||Q

幺拴星9壬lanOecename

[I□网UMxn«®

□MM02r生mreharOskPtesenc*

图讲DR主mmpcwtfSumMOw

|ln。火覆

王松■南Hmp«f3turt00i«cl

I□.卡利.主mmcompontrUNamt

i|D处理好停

5ra1主我腰事cpuOesium

![□内丽.

王虹■专

Zabbix配置硬件监控的操作过程也非常便捷,大部分都是在网页界面配置，只

需要定义好SNMPAgent/Trap的接口或IPMI传感器目标端口后即可灵活定

义监控项。对于IPMI监控的配置，主要是将传感器的名称填入即可，目前我们

对IPMI的带外监控使用的相对较少，主要是部分浪潮PC服务器在使用，对

IPMI更多地考虑应用在如VMwarevSphere的DPM等带外管理上。

在硬件监控选择监控协议时，保持的一项原则是：能用SNMP就不用其他，能

用SNMPv3就不用SNMPv2。因为SNMP在Zabbix中可以非常灵活的

实现自动发现，而SNMPv3可以提供更健壮的认证机制，因为在开放硬件监控

的同时也必须考量网络安全的风险。对单个SNMPv3的监控项配置如下，大部

分参数都提供了输入窗口：

.名称限奏器当前的整体状况

使用SNMPv渚户端

SNMPV3客户就

*键值xcc.machinesystemHealthStat

gm曲irrxCCfi个MIB里systemHealthStat字段.下T2为0

*SNMPOIDLENOVO-XCC-MIB--------------------------------------------

如果使用全数工形承om可以不依赖MIB,但是可曲线差

上下文名耕对应SNMP服领道断ONTEXT

对应服务端陪的

安全名称SNMPSECURITY-NAME

安全级别authPriv这里有三种认证级别，最低的是noAuthPriv,即不认证不1）限.

authPriv是所的认证加加密，这也是非要在服务WS洗碧好的

验证协议MD5SHA

验证口令蛉证方式缄列竟去，需与服务部而T

对于上述提及的SNMP配置自动发现的灵活性，这也是依赖于SNMP设计的

原理，借助树结构的索引方式，可以根据index字段枚举现有元素的数量，然后

再根据数量长度来遍历下一层元素。对于这种遍历,Zabbix自身提供了友好的

discovery^SNMPVALUELOID］函数来完成，无缝对接到内部通用的自动发现

数据结构。整个SNMP自动发现的机制原理如下

EntryDetail

ABCDEFGHJJK

一3

SNMPEntryEntryIndex自

动

powerFruName发

现

powerPartNumber得

PowerEntry.powerlndex.YpowerFRUNumber到

powerFRUSerialNumber结

驱动Zabbix自动发现powerHealthStatus果

由于我们Zabbix的起步试点是从基础设施运维开始，加上Zabbix对

SNMP/IPMI协议配置的操作非常方便，所以经常可以根据厂家提供的mib文

件及mib文档说明即可筛选出需要自定义的监控，这样既可以通过减少采集来

降低管理系统的繁忙度，又能优化监控质量。例如以下为根据LenovoXCC带

外管理系统的mib说明

(http://www.circitor.fr/Mibs/HtmlZL/LENOVO-XCC-MIB.php)来自定义配

置的ThinkSystemSR650的SNMPv3监控使用效果：

202M7.1209”8

1088

^20^7-12100509

—第2051210058

3WM7-1210058

KMOOUUO

QM7.12X558

W20^M2W55»

号Pm05・12X”8

»20^M21005”

・4Poe9UM?小100509Normal

Moanwrue^20^7-121005»NormH

“iatgfu①Q)97.12100509Normal

闷.IfSIUOBMQW12X558MMOOOF49CO

R-t也332WM7.12X558AM80F40C1

网.MiwaMMCX)0F4»C2

IHK5U*aiM»2M7-120e55WA28849c3

上图中的电源、阵列、磁盘等均是通过自动发现的规则来生成的，这对拥有不同

阵列卡数量、网卡数量、路数等的XCC带外服务器，都可以使用同一个模板，

设备变化完全交给Zabbix维护。另外，分享一个定制SNMP监控过程中的经

验,首先在MIB文件中收集所有需要监控的指标，对筛选的指标做分组，找到

每个组的最高父级索引的OID,然后在ZabbixProxy上使用snmpwalk遍历

这个OID找到所有OID内容，区分出Index和Detail后，划分常规监控和

自动发现监控，最后使用snmpget来逐个获取OID的值确定对应Zabbix上

的数值类型°需要特别注意，snmpwalk是遍历，并不需要OID的完整值，而

snmpget则是根据一个完整的OID来检索，对应于Zabbix则是snmpwalk

类似自动发现，snmpget类似常规监控项。

存储监控

在数据中心中，存储设备是非常核心且关键的基础设施，任何一个相关告警都会

让运维人员警觉。在推进Zabbix的存储监控的过程中，体会到一个非常棘手的

困难点，即存储不单单是硬件设备，SNMP的协议不能获取到带内的性能信息，

但也不像主流操作系统那样可以安装ZabbixAgent来做数据采集。对于这种问

题的处理，我们积累的经验是,首选使用RESTful等外部接口来获取监控数据，

在不支持此条件的情况下，在ZabbixProxy服务器上通过自定义监控封装厂家

推荐工具或方法来监控。

ZabbixAgent支持运维人员自定义监控，将执行命令封装成一个ZabbixItem

Key来供Zabbix调用，也支持额外的安全策略，例如AllowRoot可以设置是

否允许root来执行agent,UnsafellserParameters参数能够过滤特殊符号注

入。我们对自定义配置的标准，以RedHat基线为例，在

/etc/zabbix/zabbix_agentd.d目录一个监控类为一份conf文件的形式保存，

命名形式为ClassA_ClassB_DetaiLconf,并且定义的执行文件均放置于

/usr/local/zbxexec/ClassA/ClassB/xxxx.xxo

对于自定义监控项的方法，能够便捷地对接各个存储厂家的产品监控方式，将厂

家建议的监控命令封装为Zabbix的一个监控项。这类被封装的方法主要是CLI、

RESTful和SSH,例如以下我们目前对各产品使用的监控方式：

方式AS工具

CLIunityuemdi

CLIvnxnaviseccli

RESTfulVMAXrequests(Python)

SSHV7000OpenSSH

除了跟厂家沟通对接Zabbix外，其实也可以借助开源生态和Zabbix的合作推

广，也有很多企业与我们一样会分享Zabbix的经验、模板、工具到Zabbix

Share,可以斟酌筛选后使用。同时，Zabbix也一直努力与其他厂家共同合作，

共同推出每个厂家在Zabbix上的官方监控模板，例如DELLEMC在Zabbix

中推出的各个产品的监控模板(

/integrations/emc)0

通过上述的监控方式，Zabbix对生产环境存储设备的监控效果让运维人员感到

比较满意，agentless的架构避免对重要设备的侵入，同时相关的存储告警也能

够及时触发，并帮助存储管理人员迅速发现问题、定位原因。

主机监控

我们目前的主机监控主要包含了Power的小型机和x86的ESXi,这类对象有

一非常明显的特点，就是数量和信息不固定。一台小型机可能需要为新部署的数

据库划分物理分区或虚拟分区，亦或者要调整某个数据库的CPU分配；一个

vSphere集群可能会扩容ESXi主机数量或资源，亦或新建一个集群。在这种多

变的的环境里,首先考虑的是使用Zabbix的自动发现来适配，并且此场景有一

个非常明显的相似特性，就是需要一个主控端来管理整个主机资源池。因此，我

们对主机的监控常常采用的原则是，通过监控主控端来自动发现主机，让被发现

的主机自动使用对应模板。

主控端自动注册主机模板

J_卜_.，J

ResourcePool

DRS

Cluster

HA

Host

CPU

Memory

Host

Storage

Status

Partition

Host

State

CPU

Memory

Partition

RefCode

State

上述的监控流程主要是依赖Zabbix的自动注册主机来实现，不同于硬件监控中

提及的自动注册监控项，这里的自动注册会直接根据主控端获取的资源列表，自

动注册一个待监控的主机，相关的主机配置包括主机名、可见名称、agent接口

等都会继承主控，然后会为每个主机都绑定一个预先配置的监控模板。如果主控

端发现某一个主机不在上一次收集的资源列表中，会在超过资源保留策略时间后，

自动删除该主机。例如自动发现的ESXi主机：

DiscoverViAvarehypervisors:ESX_P1-F-=期集6范控项44帔发器12图形自动发现1履

DiscoverVl^warehypervisors:ESX_P1-J.LFT3■■I期集6笈控项44娱3H2图形自动发现1Web监测

应用集

DiscoverVMwarehypervisors:ESX.PI-LMUJFPB：睡6笈控项44敢发器12图形自动发现1Weo£S!

DiscoverVMwarehypervisors:ESX_P1-\T则集6位控膜44帔发器12图形自动发现1WM监测

DiscoverV»4warehypervisors:ESX_P3-WWbJLr'L.一5应用集6玄拄项44般发器12图形自动发现1Wet)£»

DiscoverVMwarehypervisors:ESX_P3*VHWfVQI16应用集6笈控埃44依发器12图形自动发现1Web酬

DiscoverVI4warehypervisors:ES(PSWMW1-*■应用集6玄拄项64位8820图形目动发现1Web&i!

DiscoverVWwarehypeivisors:ESX_P3^HBnJfrti应用集6飙暇64歌发as20图形目动发现1Web有

DiscoverVWwarehypervisors:ESX_P3-i^MLWB.FA..应用袈6融项64触发器20图形自动发现1Web同

DiscoverVWwarehypervisors:ESX_P4-»•'TTI―.应用袈6融项34触发器28图形自动发现1Web的

操作系统监控

操作系统的监控是非常庞大的,除了操作系统种类多，每个操作系统内的监控项

数量也是覆盖面广，再乘上物理机、虚拟机的数量，整个监控面积会非常之大。

另外，将每一台服务器纳管至Zabbix中的操作也变得异常繁琐。对此，我们保

持的思路是，通过自动化手段让服务器自动上报到Zabbix，优化模板以减少重

复监控，定制触发器的依赖关系。

操作系统的监控都是使用ZabbixAgent方案来实现的，Zabbix也推出了各种

操作系统的agent,不需要编译就能直接运行。对此，我们的所有虚拟机基线、

小型机备份、物理机Ansible部署脚本里，都会事先准备好对应操作系统的

Agent安装和配置。其中,推荐使用被动方式，并且主要修改agent配置的如

下内容：

32.2#/24Server=

,/24#Hostname'IPHostname=

这种配置主要是方便于agent在多个Proxy中平移,在故障恢复、Zabbix升

级等场景下，可以非常便利的保证agent的持续有效。另外将本地回环地址也

写入Server中，方便以后需要在此操作系统中通过agent调用本地脚本。

Hostname在被动模式下并不是必须的，配置管理IP可以保证主动模式和配置

管理的便利。

以上仅是agent的配置标准，如果需要自动上报至Zabbix,还需要其他步骤。

目前我们对于物理机和虚拟机的x86操作系统实现了自动上报主机的机制，每

天上午八点会做一次上报，然后对新增的主机自动加入维护模式，避免部署阶段

中各种不关键的异常带来告警风暴，直至系统稳定才会退出维护模式。在物理机

的部署中，我们除了一套完善的自动化RAID配置、PXE安装系统外，还有对

操作系统配置基线的Ansible方案，每个操作系统的roles里，都有一个

InstallZabbixAgentAndReport的task,这样通过实现配置的好的vars即

可将此主机以标准命名添加到Zabbix中。而对于数量庞大的虚拟机，我们编写

了一套Python脚本，扫描各个机房vCenter中的虚拟机获取到每日的虚拟机

差异，再使用其在CMDB的属性、vCenter上的备注，来填充业务系统、应用

集群、服务器描述等，最后注册到Zabbix。这种机制除了极大程度地解放运维

人员对新系统的主机监控注册外，还可以在脚本中指定纳管策略来实现各种额外

的预期目标，列举以下几点：

根据网段信息耨同机房的服务器接口对接同机房的Proxy避免机房流量交叉。

通过判断当前Zabbix各个Proxy的vps,将新增主机接入到低负载的Proxy。

将CMDB中现有的信息填入到被注册主机的标签和资产信息中。

其架构上的拓扑简化如下：

在这套自动化机制下，极大地减轻了运维人员对监控配置的厌恶，也加到了对我

们CMDB的关联，为以后的工单系统打下架构基础。但是，我们对监控系统的

分析和探索没有仅仅止步于此，考虑到操作系统监控中触发器带来的大量告警,

我们也研究了一些额外的措施，避免太宽泛的告警涌现。

首先，将模板细分为各个类别作为基类的template,然后根据应用场景来指定

上层的模板由哪些基类组合，避免太多的定制模板中近似功能的监控带来重复监

控。然后，对每个模板中的触发器指定严格的依赖关系，避免告警的连带触发导

致风暴。例如Linux系统的分区容量监控触发器，我们制定了几个水位线之间的

依赖：

产里性名称▲

警告TemplateOSLinux:Freeinodesislessthan20%onvolumeiffFStlAME)

□DGBOSLinux:卷(｛#FSNAME)］已使用空间＞80%,当前宜｛ITEM.SSTVALUE)］

依籁于：

LNX—^/T"*1.f*24卷«#FSNAME)］已使用空间＞90%兰前面｛ITEMIASTVALUE)］

LNX_*J-r*L：/V上24卷(｛#FSNAME)］已使用空间＞95%兰前值｛｛ITEM.LASTVALUE)］

LNX_F.X"24镯悌FSNAME｝］已®空曲99%当前®KITEM.LASTVALUE｝］

□重DGBOSLinux:覆隹FSNAME｝］已鲸至|即90%,当前(gRlTEMLASTVALUE｝］

依赖于：

LNX_A＞J4.1724:卷«#FSNAME)］已使用空间＞95%当前值lOTEMLASTVALUE)］

LNX_AN..1『417.24:卷｛｛#FSNAME)］已使用空间＞99%当前面｛IT£M.SSTVALUE)］

□产里DGBOSLinux:希伸FSNAME｝)已麒空间＞95%,当前LASTVALUE｝)

依Jft于：

，小萄伊FSNAME｝旧簸空曲99%当前©1｛ITEMLASTVALUE｝)

□旗DGBOSLinux掷杆SNAME｝)已OS空的99%,当前面｛ITEM.LASTVALUE))

□信息DGBOSLinux:分区［｛#FSNAME)［宫化

数据库监控

数据库监控也是一条每个运维人员心中紧绷的弦，除了普通的表空间使用、会话

数量、SGA使用、ASM使用、缓存命中、刷脏频率等，还有宕机、切换等状态

检查。加上我们近几年分布式数据库落地，及尝试国产数据库的背景下，越来越

多的数据库产品需要对接至目前我们对数据库的监控，结合了多种监

Zabbixo

控思路，制定了各种数据库产品的监控指标，在性能数据追溯与故障告警的场景

下都体现出非常优秀的表现。

在金融行业的传统架构中,Oracle数据库往往是不可或缺的一个基座，我们通过

模板定制，提供了Sinlge-Instance.RAC、DG、F5等多种架构的模板，覆盖

了大部分OracleDBA关心的监控项。在Zabbix中专门使用一台高性能的

Proxy,通过自定义监密的方式来执行Oracle监控脚本。除了应急的故障告警

外，现在Zabbix也成为了DBA分析数据库性能的工具，对比历史数据排查数

据库问题，这也依赖于Zabbix保存的大量监控信息。如下为其中有给数据库的

性能与RAC部分监控指标：

ML诉加

•事Km*JM

y,M*g

BUv>xftfWMe»r««

XME.tm

WTVMM

—t3146*

W»Q>/••・.・

K0^».C・

XQ^f,

nnoYBgR

除了传统架构的数据库，我们对其他数据库产品也提供了全面的监控，并且对此

监控采用了主控服务(Rootservice)的思路，将数据库更自动的纳入监控中。这

种方法的优点是可以完美展现Zabbix自动注册主机的机制，将数据库添加到监

控中，并使用自动注册监控原型的方式来识别数据库开启了哪些需要监控的细节。

目前我们编写了OceanBase.MySQL、DRDS等数据库产品的监控脚本，在

Zabbix中以全新的数据库监控架构运行自管理。此框架的工作流程如下。

以MySQL的监控为例作为详细描述整个过程，参见下图。

1.发现showslavestatus

2.检查fUg里FWWJtt）的稣

3.ZtSCshowengines返西2里.

在MySQL实例的配置zbxmysql.py文件中，新增一个testenvzabbix的

数据库实例，这份文件是通过acl设置仅为zabbix用户读取的。当作为

MySQLRootService的主机执行自动发现主机的监控时，会将新增的实例配置

生成Zabbix自动发现的json规则，根据配置信息创建监控实例，并附加使用

MySQL基础模板。在MySQL基础模板中，配置了一系列特殊的监控自动发现

规则，例如DiscoveryMySQLReplicationEnable会对发现的实例执行show

slavestatus命令，这里仍会调用MySQLRootService的脚本，如果发现目标

实例开启了主从，则会在自动发现返回josn中包含一个｛#REPLICATION):

"enabled"的字段，从而触发主从复制的监控项生效。

创建一台逻辑主机作为主控服务，以链式发散的传播模式自动注册主机，然后根

据模板内的自动发现判断是否需要附加额外的监控配置，这种在我们创新使用的

监控方法，取到了非常好的成效，让监控系统变得更加智能，也不用像某些数据

库监控还需要将连接的用户与密码写入到Zabbix的宏，而只要保证读取的配置

文件在文件系统的ACL上是最小权限即可，提高了数据库的访问安全。另外一

点，现在很多的分布式数据库也是采用控制+计箕+存储的架构，例如TiDB的

PD负责元数据管理、DB负责SQL解析与计算、KV负责底层键值对存储，面

对众多的分区也好，副本也罢,最有效的监控方式就是直接对接其管控部件，将

Zabbix主控服务的起点映射至数据库集群的管控上，不断顺着架构分层，将各

个组件之间的监控项固化成自动发现规则，实现精准有效的监控覆盖。以目前我

们的OceanBase分布式数据库监控为例，以下从OBRootService自动发散

出OBZone、OBTenant.OBServer.OBPartition等监控细节。

oe_oe_rsoGeoewrwa.HR-■ft+P5

*4wa

o«>c««wyueoe_ue.sa_9^i■W*'1AHtLKM'Bits♦。&A

AU/Wl

DtQvroeswwroe.oe.SR.v/C•.加Attmta-a初直观0.)■DG806OctJABOM

・2SitMH

063«v*r0e_06_SR_aiJ^,JfTWTS■能amn欢・血1■J—人DG806S«rvr

■2«1•■,

DiscMVrOBSwwcoe.OB.SR.dMr^B.：•Jf3.：■ft水3DCSD8OomBaseS«fvr

・2■i9

ottc^roes«w<oe.oe.sR.«r^i■WBttltR兽…DOB06OCMOOIX

«1•

oes««w<De.OG.$R_a0-*<■.0”・WQHMlwuM0G8060cMn8a“Servr

9L：Hit£A

08oe.oe.TNjif■■*“8t£R

an*21况，i

DucM^oeT«Mftoe.oemjaBw«p..MHY,fiRAtt«n■ft做皿1FT••・DC806Temrl

«)a3i■21况，0

00TeM0e_Q8.TXJfWBR▲.1•OftestBtfOt工V•DG6D6Tefivl

■11M21■，一

oeNontoe.oe_2N,^piaLft^>.IonHg■WBttkR

G■»*

(xsc«««froezo(M06.oe_ZN.do^^r*b1I-«j旗AftawR9Xtt«

・2a«■»

OBZon*06_08_ZW_dQt.：▼'mr«*a皿双»■・・5

■2C2$■13

除了监控架构的不断灵活，我们也在考虑更