《银行 Zabbix 监控架构.docx》由会员分享，可在线阅读，更多相关《银行 Zabbix 监控架构.docx（31页珍藏版）》请在三一办公上搜索。
1、Zabbix平台概述平台介绍Zabbix是一个基于Web界面提供分布式系统监视及网络监视功能的企业级开源解决方案。它能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统省理员快速定位、解决存在的各种问题，借助Zabbix可很轻松地减轻运维人员繁重的服务器管理任务，保证业务系统持续运行。其后端使用数据族存慵监控配皆和历史数据，可以非常方便地对接数据分析、报表定制等渠道，在前端开放了丰富的RESTfuIAPI供第三方平台调用,整体架构在当下的DevOps的趋势下显得非常亮眼.选型过程我们于2017年开始接触Zabbix,之前运维内主要使用的监控系统是Nagios,但Nagio
2、s的页面展示、监控配置、自动化等各项功能对基础架构的运维人员来说不是特别友好，而风头正劲的Zabbix正好引起了我们的注意,基础架构的运维工作中,需要面对各种各样的监控场景，例如PC服务器的故障灯巡检、存储设备的阵列健康判断、小型机1.PAR的资源监控、操作系疣的多路径检查，等等.而Zabbix内置提供了SNMP、IMP1.SSH.Agent等多种监控途径,在系统架构的各层场景下都能很好的适配，其中Agent还支持自定义工具，总体的表现非常灵活.在网页前端管理上，Zabbix可以满足各个粒度的监控管理,从整个集群到单独一个监控项都能缪进行细分管控，自定义dashboard和历史数据可视化功能也
3、极大地方便运维人员对监控数据的审套.综合以上的考虑因素，行内选择了Zabbix作为一个新的监控平台试点，从基础资源的监控出发，首先将大部分存储、主机和操作系统接管到Zabbix.使用现状2017年底在基础架构范围内试行的Zabbix系统,从3.2版本开始逐步演进到现在的4.4版本,其中经历了各项监控系统的里程碑事件.目前的Zabbix系统也由原先的小范围试用，逐步扩展到涵盖硬件、应用、平台、业务等更大范围的场景，架构上也从单数据中心进化为三中心的分布式部署.除了逐渐替代旧的监控系统，越来越多的第三方系统也开始对接起了Zabbix,例如自动化运维平台、持续发布平台、运堆可视化平台等，通过API或
4、者数据库抽数的方式，使用海星的运维监控数据实现智能运堆的工作模式。在编写此文前不久，我们也顺利完成应用系统监控迁移到Zabbix平台，作为一名全程参与Zabbix系统推广实施和自动化开发的运维人员，非常荣幸能够见证我们运维力量的茁壮成长，在此，本人也将从架构部署、监控维度、自动化方案、运营管理屈面，分享我们Zabbix系统发展壮大的经验.硬件监控数据中心的运维省理中，系统架构的纵向深度是非常陡长的，包括最基础的硬件设备也需要运维人员斐尽心思地去巡检排查，但随着数据中心的设备数量呈爆发式增长，人工巡检已不能满足当下监控实时性、可靠性的要求.对于这种低层级的监控，Zabbix的多维度特性就非常好的
5、解决了这个问题，其内首的SNMP/1PMI协议能够轻松对接相关硬件设备的带外监控.目前我们使用SNMPAgent的被动方式定明巡检硬件设备的基础指标，例如故障灯信号、电源功率、内存信息、磁盘阵列等，代替人工巡检的方式来实现异常捕获，并对数据中心内的所有设备做到硬件信息采集，定时更新至CMDB.例如以下为部分华为RH2288V3IBMC监控模扳中自动发现的配亘：三三三三Zabbix配置硬件监控的操作过程也非常便捷，大部分都是在网页界面配笆，只需要定义好SNMPAgent/Trap的接口或IPMI传感器目标端口后即可灵活定义监控项.对于IPMI监控的配宣,主要是将传感器的名称填入即可，目前我们对I
6、PMI的带外监控使用的相对较少，主要是部分浪潮PC服务器在使用，对IPMI更多地考虑应用在如VMWarevSphere的DPM等带外管理上.在硬件监控选獐监控情议时，保持的一项原则是：能用SNMP就不用其他，能用SNMPv3就不用SNMPv2.因为SNMP在Zabbix中可以非常灵活的实现自动发现，而SNMPv3可以提供更健壮的认证机制，因为在开放硬件监控的同时也必须考后网络安全的风睑.对单个SNMPv3的监控项配苴如下,大部分参数都提供了输入窗口：对于上述提及的SNMP配置自动发现的熨活性，这也是依赖于SNMP设计的原理，借助树结构的索引方式，可以根据index字段枚举现有元素的数量,然后再
7、根据数贵长度来遍历下一层元素,对于这种遍历，Zabbix自身提供了友好的discoverySNMPVA1.E,OID由数来完成,无缝对接到内部通用的自动发现数据结构,整个SNMP自动发现的机制原理如下EntryDetail会A.BX.D.E.F.G.H.IJ.KGSNMPEntryEntryIndex自动发现得到结果PowerFruNamePowerPartNumberPowerFRUNumberPowerFRUSeriaINumberPowerHeaIthStatusPowerEntry.powerlndex.驱动Zabbix自动发现由于我们Zabbix的起步试点是从基础设施运维开始，加上Z
8、abbix对SNMP/1PMI协议配普的操作非常方便，所以经常可以根据厂家提供的mib文件及mib文档说明即可筛选出需要自定义的监控，这样既可以通过减少采集来降低管理系统的繁忙度，又能优化监控质国,例如以下为根据1.enovoXCC带外管理系统的mib说明(http:/www.circitor.fr/Mibs/Html/1./1.ENOVO-XCC-MlB.php)来自定义配置的ThinkSystemSR650的SNMPv3监控使用效果：上图中的电源、阵列、磁盘等均是通过自动发现的规则来生成的，这对拥有不同阵列卡数量、网卡数量、路数等的XCC带外服务器，都可以使用同一个模板，设备变化完全交给Z
9、abbix维护.另外，分享一个定制SNMP监控过程中的经验,首先在MIB文件中收集所有需要监控的指标，对筛选的指标做分组，找到每个组的展高父级索引的OlD,然后在ZabbixProxy上使用Snmpwalk遍历这个OlD找到所有OID内容，区分出Index和Detail后，划分常规监控和自动发现监控，最后使用snmpget来逐个获取OlD的值确定对应Zabbix上的数值类型.需要特别注意.Snmpwalk是遍历，并不需要OlD的完整值，而SnmPget则是根据一个完整的OlD来检索,对应于Zabbix则是SnmPWaIk类似自动发现，snmpget类似常规监控项.存储监控在数据中心中，存睛设备
10、是非觉核心且关穗的基础设施，任何一个相关告警都会让运维人员警觉.在推进ZabbiX的存储监控的过程中，体会到一个非常棘手的困难点，即存储不隼单是硬件设备，SNMP的协议不能获取到带内的性能信息，但也不像主流操作系统那样可以安装ZabbixAgent来做数据采集.对于这种问题的处理，我们积累的经验是，首选使用RESTfuI等外部接口来获取监控数据，在不支持此条件的情况下，在ZabbixProxy服务器上通过自定义监控封装厂家推荐工具或方法来监控.ZabbixAgent支持运维人员自定义监控，将执行命令封装成一个ZabbixItemKey来供Zabbix调用，也支持额外的安全策略，例如AIIowR
11、oot可以设置是否允许root来执行agent,UnsafeUserParameters参数能够过海特殊符号注入.我们对自定义配置的标准，以RedHat基线为例，在etczabbixzabbix.agentd.d目录一个监控类为一份conf文件的形式保存,命名形式为ClassA.CIassB-Detai1.conf,并且定义的执行文件均放置于usrlocalzbxexecClassAClassBxxx.x.对于自定义监控项的方法，能够便捷地对接各个存储厂家的产品监控方式，将厂家建议的监控命令封装为Zabbix的一个监控项.这类祓封装的方法主要是C1.1.RESTfuI和SSH,例如以下我们目前
12、对各产品使用的监控方式：方式尸MXlBC1.IUnty*ettSSMVTOooOpenSSH除了跟厂冢沟通对接Zabbix外，其实也可以借助开源生态和Zabbix的合作推广，也有很多企业与我们一样会分享Zabbix的经验、模板、工具到ZabbixShare,可以斟酌筛选后使用.同时，Zabbix也一直努力与其他厂家共同合作,共同推出每个厂家在Zabbix上的它方监控模板，例如DE1.1.EMC在Zabbix中推出的各个产品的监控模板(通过上述的监控方式，Zabbix对生产环境存储设备的监控效果让运维人员感到比较满意.agentless的架构避免对里要设备的侵入，同时相关的存储告警也能终及时触发
13、，并帮助存储管理人员迅速发现问题、定位原因.主机监控我们目前的主机监控主要包含了Power的小型机和86的ESXi,这类对象有一非常明显的特点，就是数量和信息不固定.一台小型机可能需要为新部署的数据库划分物理分区或虚拟分区，亦或者要调整某个数据库的CPU分配；一个VSphere集群可能会扩容ESXi主机数量或资源,亦或新建一个集群。在这种多变的的环境里，首先考虑的是使用Zabbix的自动发现来适配，并且此场里有一个非常明显的相似特性，就是需要一个主控端来管理整个主机资源池。因此，我们对主机的监控常常采用的原则是，通过监控主控端来自动发现主机，让被发现的主机自动使用对应模扳.自动注册主模板Res
14、ourcePoolDRSHAHostCPUMemoryStorageStatusPartitionStateCPUMemoryRefCodeState上述的监控流程主要是依赖Zabbix的自动注册主机来实现，不同于硬件监控中提及的自动注册监控项，这里的自动注册会亘接根据主控端获取的资源列表，自动注册一个待监控的主机，相关的主机配黄包括主机名、可见名称、agent接口等都会继承主控，然后会为每个主机都绑定一个预先配在的监控模板。如果主控端发现某一个主机不在上一次收集的资源列表中，会在超过资源保留策略时间后,自动删除该主机.例如自动发现的ESXi主机：m12三ftB11We口0*tWerenWM5
15、cr3S.P1fc.*l三P.IXRB12B0*fiweMSOivfVmW“4:ESJM.4Jmwr”MB17却菊3时wsn0U8*fWM4Zf%BCSXwP14_T-GfiSM”慢17R三Ctt5w*tOiscowrVbvW-I*5.6AftC44sat三WoM0w*BftBM三1WeWS三C9CWV4ME)DG8OSUnuc&：”SKAWEH巳使用空SJBO*IYEM1.ASTY*1.UEJ4MT:INKjrWw，.口1.24三CA3HMEflffi三*.S三fl7MiASTV,UEHOU*H*.24好SHWQ巳在W克第戈三MKTEM1.ASTMH.ue1.WJPQW_*X-24ySIWG
16、HBftW5Wb.SfKITCM1.ASTW1.UtMDG8OS1.lnuc制-31*65年90%.MKTEM1.ASTYMUEM9.*rTEM1.ASTW1.UEg1.NX.A-W9mt.1i1724号MSaAMEn已使角交角99.X11rT三M1.ASTWJE*DGeoSUnW阴SHQjeaelMl堂G95%.Sr三KTEM1.ASTVA1.UEj体”UNX.y.弧呷三SJW.NKHiTEM1.ASa1.uE刃DGeOSlJn亚硼MSHKH6W至99%SM8Fr，7-I2n454X.YjwwutaMSXT12ZM582yHMffgTsntss“a7HWSCermtai(WSMle，ra.：
17、1JX-QME,E.SfKrtto.ACfijrAncrtMUtrfM-A.*CS.irt11orMr.r,T；.aAC1.EwewQrPrfwv;ACSJVAncrtMMtftfVMX1.VW*ce,*nm*4rASrr、3.ctmh”/wAHifc-I.一arj.，心.rSa*SEMHTACSjr*m*MA-.4*CartQrMwvw.，.sIryAC1.IrATMM_01.gP一,告警通知监控覆盖的话里，到此也算是结束了，下面进而讨论下一个环节，那就是监控触发的告警需要如何才能推送到需要接收的技术人员.其实,Zabbix自身也提供了非常多样的告瞥推送渠道，也可以自定义脚本来处理告警内容再
18、推送给至渠道.但我们选择将这个推送的渠道稍微拉长，让告警发挥出更多的作用.如果告警无法推送，那么监控的意义就少了一大半，但推送的太多，告警也就没有价值可言.Zabbix的告警消息结构体只是一个字符串，有些特殊符号混杂会对后面的序列化动作触发异常，抑或发送告警的Proxy宕机了，而大果告警却发不出来。由此种种产生的困扰，想必每一个接触过告警的技术人员，都会深有感触。为了解决这些最后一百米的问题，我们也不断地尝试各种方法，目前也依旧在努力寻求突破.我们编写了一个内部命名为ZabbxiRobot的工具，可以按照预定的Zabbix告警字符串进行JSON解析，并在预处理完后，会判断此告警是否需要抑制，是
19、否属于一次需要收敛的抖动，然后才把告警推送至下游.另外，在Zabbix的架构设计上，将一个负责主要告警推送的Proxy与Server配置为互相监控，而Server会有两个推送渠道在主渠道失效后进行通知，进而避免告警空白.这里的短息猫通过gnokii调用串行接口实现的短信发送，发送效率非常低，仅当探测发现Zabbix架构出现更大故障时，会应急发送给几位负责监控系统的运维人员.而备用渠道与主要驱动实现方法都是把告警信息以curlPOST的方式传送给ZabbiXRobOt,不同点在于两者使用了不同的Header,从而在ZabbixRobot中区分出具体的渠道，也会对此过谑.ZabbixRobot是我
20、们使用Golang开发的HTTP服务器，目前具备两个模块，先触发抑制模块，后触发收敛模块.这里的抑制操作是以1.imitUnitGroup来生效的，当期触发条件满足每一个gorup的三元组（flag,number,second）,当判断为flag的告警，在second秒内收到了超过number数最）时，则会使用flag派生出一个InhibitionUnit的goroutine,而这个flag如果存在InhibitionUnit,那么就可以判断处于抑制状态，不会发送出去.InhibitionUnit也是一个三元组（flag,number,SeCond）,当判断为flag的告警，在收到number
21、数量后或超过second秒后退出此次抑制.而在Zabbix-Robot的配置文件里，细分了每个flag和其属性.一股而言，目前常用的flag就是Zabbix的TRIGGER.SEVERITY,即告警级别。收敛模块是目前在测试阶段的一个功能，优先实现了Weights的方法，即判断收到告警与过去三十分钟（可调）样本中的hostidX_+_itemidY+triggerid*Z总分，如果超过预定值K,则会被判定为抖动进而收敛.这里的X/Y/Z是可自定义的权重，比如可以通过提高X来把收敛权重倾向于主机，那么同一台主机发送的告瞥数则会被优先收敛.另外还有其他收敛的方法，比如字符串特征和机器学习，这两个也是我们尝试的方向.当走完抑制和收敛，告警会流向我们的自动化平台，并由平台判断是否派生工单，然后再经订阅系统把告警发送给指
