银行 Zabbix 监控架构.docx

Zabbix平台概述平台介绍Zabbix是一个基于Web界面提供分布式系统监视及网络监视功能的企业级开源解决方案。它能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统省理员快速定位、解决存在的各种问题，借助Zabbix可很轻松地减轻运维人员繁重的服务器管理任务，保证业务系统持续运行。其后端使用数据族存慵监控配皆和历史数据，可以非常方便地对接数据分析、报表定制等渠道，在前端开放了丰富的RESTfuIAPI供第三方平台调用,整体架构在当下的DevOps的趋势下显得非常亮眼.选型过程我们于2017年开始接触Zabbix,之前运维内主要使用的监控系统是Nagios,但Nagios的页面展示、监控配置、自动化等各项功能对基础架构的运维人员来说不是特别友好，而风头正劲的Zabbix正好引起了我们的注意,基础架构的运维工作中,需要面对各种各样的监控场景，例如PC服务器的故障灯巡检、存储设备的阵列健康判断、小型机1.PAR的资源监控、操作系疣的多路径检查，等等.而Zabbix内置提供了SNMP、IMP1.SSH.Agent等多种监控途径,在系统架构的各层场景下都能很好的适配，其中Agent还支持自定义工具，总体的表现非常灵活.在网页前端管理上，Zabbix可以满足各个粒度的监控管理,从整个集群到单独一个监控项都能缪进行细分管控，自定义dashboard和历史数据可视化功能也极大地方便运维人员对监控数据的审套.综合以上的考虑因素，行内选择了Zabbix作为一个新的监控平台试点，从基础资源的监控出发，首先将大部分存储、主机和操作系统接管到Zabbix.使用现状2017年底在基础架构范围内试行的Zabbix系统,从3.2版本开始逐步演进到现在的4.4版本,其中经历了各项监控系统的里程碑事件.目前的Zabbix系统也由原先的小范围试用，逐步扩展到涵盖硬件、应用、平台、业务等更大范围的场景，架构上也从单数据中心进化为三中心的分布式部署.除了逐渐替代旧的监控系统，越来越多的第三方系统也开始对接起了Zabbix,例如自动化运维平台、持续发布平台、运堆可视化平台等，通过API或者数据库抽数的方式，使用海星的运维监控数据实现智能运堆的工作模式。在编写此文前不久，我们也顺利完成应用系统监控迁移到Zabbix平台，作为一名全程参与Zabbix系统推广实施和自动化开发的运维人员，非常荣幸能够见证我们运维力量的茁壮成长，在此，本人也将从架构部署、监控维度、自动化方案、运营管理屈面，分享我们Zabbix系统发展壮大的经验.硬件监控数据中心的运维省理中，系统架构的纵向深度是非常陡长的，包括最基础的硬件设备也需要运维人员斐尽心思地去巡检排查，但随着数据中心的设备数量呈爆发式增长，人工巡检已不能满足当下监控实时性、可靠性的要求.对于这种低层级的监控，Zabbix的多维度特性就非常好的解决了这个问题，其内首的SNMP/1PMI协议能够轻松对接相关硬件设备的带外监控.目前我们使用SNMPAgent的被动方式定明巡检硬件设备的基础指标，例如故障灯信号、电源功率、内存信息、磁盘阵列等，代替人工巡检的方式来实现异常捕获，并对数据中心内的所有设备做到硬件信息采集，定时更新至CMDB.例如以下为部分华为RH2288V3IBMC监控模扳中自动发现的配亘：三三三三Zabbix配置硬件监控的操作过程也非常便捷，大部分都是在网页界面配笆，只需要定义好SNMPAgent/Trap的接口或IPMI传感器目标端口后即可灵活定义监控项.对于IPMI监控的配宣,主要是将传感器的名称填入即可，目前我们对IPMI的带外监控使用的相对较少，主要是部分浪潮PC服务器在使用，对IPMI更多地考虑应用在如VMWarevSphere的DPM等带外管理上.在硬件监控选獐监控情议时，保持的一项原则是：能用SNMP就不用其他，能用SNMPv3就不用SNMPv2.因为SNMP在Zabbix中可以非常灵活的实现自动发现，而SNMPv3可以提供更健壮的认证机制，因为在开放硬件监控的同时也必须考后网络安全的风睑.对单个SNMPv3的监控项配苴如下,大部分参数都提供了输入窗口：对于上述提及的SNMP配置自动发现的熨活性，这也是依赖于SNMP设计的原理，借助树结构的索引方式，可以根据index字段枚举现有元素的数量,然后再根据数贵长度来遍历下一层元素,对于这种遍历，Zabbix自身提供了友好的discoverySNMPVA1.E,OID由数来完成,无缝对接到内部通用的自动发现数据结构,整个SNMP自动发现的机制原理如下EntryDetail会A.BX.D.E.F.G.H.IJ.K''GSNMPEntryEntryIndex自动发现得到结果PowerFruNamePowerPartNumberPowerFRUNumberPowerFRUSeriaINumberPowerHeaIthStatusPowerEntry.powerlndex.驱动Zabbix自动发现由于我们Zabbix的起步试点是从基础设施运维开始，加上Zabbix对SNMP/1PMI协议配普的操作非常方便，所以经常可以根据厂家提供的mib文件及mib文档说明即可筛选出需要自定义的监控，这样既可以通过减少采集来降低管理系统的繁忙度，又能优化监控质国,例如以下为根据1.enovoXCC带外管理系统的mib说明(http:/www.circitor.fr/Mibs/Html/1./1.ENOVO-XCC-MlB.php)来自定义配置的ThinkSystemSR650的SNMPv3监控使用效果：上图中的电源、阵列、磁盘等均是通过自动发现的规则来生成的，这对拥有不同阵列卡数量、网卡数量、路数等的XCC带外服务器，都可以使用同一个模板，设备变化完全交给Zabbix维护.另外，分享一个定制SNMP监控过程中的经验,首先在MIB文件中收集所有需要监控的指标，对筛选的指标做分组，找到每个组的展高父级索引的OlD,然后在ZabbixProxy上使用Snmpwalk遍历这个OlD找到所有OID内容，区分出Index和Detail后，划分常规监控和自动发现监控，最后使用snmpget来逐个获取OlD的值确定对应Zabbix上的数值类型.需要特别注意.Snmpwalk是遍历，并不需要OlD的完整值，而SnmPget则是根据一个完整的OlD来检索,对应于Zabbix则是SnmPWaIk类似自动发现，snmpget类似常规监控项.存储监控在数据中心中，存睛设备是非觉核心且关穗的基础设施，任何一个相关告警都会让运维人员警觉.在推进ZabbiX的存储监控的过程中，体会到一个非常棘手的困难点，即存储不隼单是硬件设备，SNMP的协议不能获取到带内的性能信息，但也不像主流操作系统那样可以安装ZabbixAgent来做数据采集.对于这种问题的处理，我们积累的经验是，首选使用RESTfuI等外部接口来获取监控数据，在不支持此条件的情况下，在ZabbixProxy服务器上通过自定义监控封装厂家推荐工具或方法来监控.ZabbixAgent支持运维人员自定义监控，将执行命令封装成一个ZabbixItemKey来供Zabbix调用，也支持额外的安全策略，例如AIIowRoot可以设置是否允许root来执行agent,UnsafeUserParameters参数能够过海特殊符号注入.我们对自定义配置的标准，以RedHat基线为例，在etczabbixzabbix.agentd.d目录一个监控类为一份conf文件的形式保存,命名形式为ClassA.CIassB-Detai1.conf,并且定义的执行文件均放置于usrlocalzbxexecClassAClassBx×xx.x×.对于自定义监控项的方法，能够便捷地对接各个存储厂家的产品监控方式，将厂家建议的监控命令封装为Zabbix的一个监控项.这类祓封装的方法主要是C1.1.RESTfuI和SSH,例如以下我们目前对各产品使用的监控方式：方式尸MXlBC1.IUnty*e<ncC1.IVra田ISeCalRESTWVlMXreque5tP)thc>ttSSMVTOooOpenSSH除了跟厂冢沟通对接Zabbix外，其实也可以借助开源生态和Zabbix的合作推广，也有很多企业与我们一样会分享Zabbix的经验、模板、工具到ZabbixShare,可以斟酌筛选后使用.同时，Zabbix也一直努力与其他厂家共同合作,共同推出每个厂家在Zabbix上的它方监控模板，例如DE1.1.EMC在Zabbix中推出的各个产品的监控模板(通过上述的监控方式，Zabbix对生产环境存储设备的监控效果让运维人员感到比较满意.agentless的架构避免对里要设备的侵入，同时相关的存储告警也能终及时触发，并帮助存储管理人员迅速发现问题、定位原因.主机监控我们目前的主机监控主要包含了Power的小型机和×86的ESXi,这类对象有一非常明显的特点，就是数量和信息不固定.一台小型机可能需要为新部署的数据库划分物理分区或虚拟分区，亦或者要调整某个数据库的CPU分配；一个VSphere集群可能会扩容ESXi主机数量或资源,亦或新建一个集群。在这种多变的的环境里，首先考虑的是使用Zabbix的自动发现来适配，并且此场里有一个非常明显的相似特性，就是需要一个主控端来管理整个主机资源池。因此，我们对主机的监控常常采用的原则是，通过监控主控端来自动发现主机，让被发现的主机自动使用对应模扳.自动注册主模板ResourcePoolDRSHAHostCPUMemoryStorageStatusPartitionStateCPUMemoryRefCodeState上述的监控流程主要是依赖Zabbix的自动注册主机来实现，不同于硬件监控中提及的自动注册监控项，这里的自动注册会亘接根据主控端获取的资源列表，自动注册一个待监控的主机，相关的主机配黄包括主机名、可见名称、agent接口等都会继承主控，然后会为每个主机都绑定一个预先配在的监控模板。如果主控端发现某一个主机不在上一次收集的资源列表中，会在超过资源保留策略时间后,自动删除该主机.例如自动发现的ESXi主机：m12三ftB11We口0>*t<WerenWM5cr3S.P1fc.*l三P.IXR<44M>B12B0*fiweMSOivfVmW“4:ESJM.4'Jmwr”MB17却菊3时ws<n0U8*fWM4Zf%BCSXwP14_T-£«GfiSM”慢17R三Ctt5w*tOiscowrVbv<n.wwicrs:E8X_PMndrwG6启用0fif9C44三fbOitarSiOttCOMrXVaarerr-MMsers:Ego>W'-I*5«.6AftC44sat三WoM0<w*<Wrnn*r*5tr5E和JyMRVfc.Cik£»«4W>BftBM三1WeWS三C<9CWV<Wev«n*wwcrs:ftHGM44BfcWe»£ftOtlOMff8-E4A.Stft口动MwCt09*fW*M4ft7WMfcfHJB2StftFHCttW牖s*fiA操作系统监控操作系统的监控是非常庞大的，除了操作系统种类多，每个操作系统内的监控项数屋也是覆盖面广,再乘上物理机、虚拟机的数方，整个监控面积会非常之大.另外，将每一台服务器纳管至Zabbix中的操作也变得异常繁琐,对此，我们保持的思路是，通过自动化手段让服务器自动上报到Zabbix,优化模板以减少用且监控，定制触发器的依赖关系.操作系统的监控都是使用ZabbixAgent方案来实现的，Zabbix也推出了各种操作系统的agent,不需要编译就能直接运行.对此，我们的所有虚拟机基线、小型机备份、物理机Ansible部署脚本里，都会事先准备好对应操作系统的Agent安装和配置.其中，推荐使用被动方式，并且主要修改agent配置的如下内容：32.2#Server=127.0.0.l,l.10.32.0/24#HostnaaeHOStname-10.1.33.1这种配置主要是方便于agent在多个Proxy中平移,在故障恢豆、Zabbix升级等场景下，可以非常便利的保证agent的持续有效。另外将本地回环地址也写入Server中，方便以后需要在此操作系统中通过agent调用本地脚本.Hostname在被动模式下并不是必须的，配置管理IP可以保证主动模式和配置管理的便利.以上仅是agent的配理标准，如果需要自动上报至Zabbix,还需要其他步骤.目前我们对于物理机和虚拟机的×86操作系统实现了自动上报主机的机制，每天上午八点会做一次上报，然后对新塔的主机自动加入维护模式，避免部署阶段中各种不关储的异常带来告瞥风疑,直至系疣稳定才会退出维护模式。在物理机的部署中，我们除了一套完善的自动化RAID配三、PXE安装系统外，还有对操作系统配置基线的Ansible方案，每个操作系统的roles里，都有一个InstallZabbixAgentAndReport的task,这样通过实现配舌的好的VarS即可将此主机以标准命名添加到Zabbix中.而对于数最庞大的虚拟机，我们编写了一套Python脚本，扫描各个机房vCenter中的虚拟机获取到每日的虚拟机差异，再使用其在CMDB的属性、vCenter上的备注，来填充业务系统、应用集群.服务器描述等，最后注册到Zabbix.这种机制除了极大程度地解放运维人员对新系统的主机监控注册外，还可以在脚本中指定纳管策略来实现各种额外的预期目标，列举以下几点：根据网段信息莉同机房的服务器接口对接同机房的Proxy避免机房流18交叉.通过判断当前Zabbix各个Proxy的vps,将新增主机接入到低负载的Proxy.将CMDB中现有的信息填入到被注册主机的标签和资产信息中.其架构上的拓扑简化如下：在这套自动化机制下，极大地减轻了运维人员对监控死首的厌恶，也加到了对我们CMDB的关联，为以后的工单系统打下架构基础.但是，我们对监控系统的分析和探索没有仅仅止步于此，考虑到操作系统监控中触发器带来的大量告警，我们也研究了一些额外的措施，避免太宽泛的告警涌现.首先,将模板细分为各个类别作为基类的template,然后根据应用场景来指定上层的模板由哪些基类组合，避免太多的定制模板中近似功能的监控带来里豆监控.然后，对每个模板中的触发器指定严格的依赖关系，避免告警的连带触发导致风暴.例如1.inux系统的分区容量监控触发器，我们制定了几个水位线之间的依赖：TempiaieOSUnuiFreeInM，islessrir»20onvolumeRFS>4ME)DG8OSUnuc&：”SKAWEH巳使用空SJ»BO*®IYEM1.ASTY*1.UEJ4MT:INKjrWw，.口1.24三CA3HMEflffi三>>*.S三fl7MiASTV<,UE»HOU*H*.24好SHWQ巳在W克第戈三MKTEM1.ASTMH.ue»1.WJPQW_*«X-24<y<SI<WGHBftW5Wb.SfKITCM1.ASTW1.UtMDG8OS1.lnuc制-31*"6««5年90%.M<KTEM1.ASTYMUEM<WT:1.NsfB.，1T24WKMsKAMEH巳脚胫目>9.*«®rTEM1.ASTW1.UEg1.NX.A-W9mt.1i1724号MSaAMEn已使角交角>99¼.X11rT三M1.ASTWJE*DGeoSUnW阴"SHQjeaelMl堂G95%.Sr三KTEM1.ASTVA1.UEj体”UNX.y.弧呷三SJ<MEe02>W.NKHiTEM1.ASa1.uE刃DGeOSlJn亚硼MSHKH6W至>99%S<三11nEM1.AS1.UEjDGeOSUnuc)*Uc±5t化数据库监控数据库监控也是一条每个运维人员心中紧绷的弦，除了普通的表空间使用、会话数星、SGA使用、ASM使用、缓存命中、刷脏频率等，还有宕机、切换等状态检直,加上我们近几年分布式数据库落地，及燮试国产数据库的背景下，越来越多的数据库产品需要对接至Zabbix.目前我们对数据库的监控，结合了多种监控思路，制定了各种数据库产品的监控指标，在性能数据追溯与故障告警的场景下都体现出非常优秀的表现.在金融行业的传统架构中，Oracle数据库往往是不可或缺的一个基座，我们通过模板定制，提供了Sinlge-Instance.RAUDG.FS等多种架构的模板，濯盖了大部分OradeDBA关心的监控项。在Zabbix中专门使用一台高性能的Proxy,通过自定义监控的方式来执行OraCle监控脚本.除了应急的故障告警外，现在Zabbix也成为了DBA分析数据库性能的工具，对比历史数据排查数据南问题，这也依赖于Zabbix保存的大量监控信息.如下为其中有给数据库的性能与RAC部分监控指标：5*E三三三三zr三除了传统架构的数据摩，我们对其他数据麻产品也提供了全面的监控，并且对此监控采用了主控服务(RootService)的思路，将数据库更自动的纳入监控中.这种方法的优点是可以完美展现Zabbix自动注册主机的机制，将数据库添加到监控中，并使用自动注册监控膜型的方式来识别数据库开启了哪些需要监控的细节.目前我们编写了OceanBase、MySQ1.、DRDS等数据座产品的监控脚本，在Zabbix中以全新的数据库监控架构运行自管理。此框架的工作流程如下.以MySQ1.的监控为例作为详细描述整个过程,参见下图,在MySQ1.实例的配出ZbX_mysq1.py文件中，新增一Zzhtestenv_zabbix的数据库实例，这份文件是通过acl设置仅为zabbi×用户读取的.当作为MySQ1.RootService的主机执行自动发现主机的监控时，会将新增的实例配置生成Zabbix自动发现的json规则，根据配置信息创建监控实例，并附加使用MySQ1.基础模板.在MySQ1.基础模板中，配等了一系列特殊的监控自动发现规贝!J,例如DiscoveryMySQ1.ReplicationEnable会对发现的实例执行showslavestatus命令，这里仍会调用MySQ1.RootService的脚本，如果发现目标实例开启了主从，则会在自动发现返回josn中包含一个(*REP1.ICATION):,enabled"的字段,从而触发主从豆制的监控项生效.创建一台逻辑主机作为主控服务，以链式发散的传播模式自动注册主机，然后根据模板内的自动发现判断是否需要附加额外的监控配置，这种在我们创新使用的监控方法，取到了非常好的成效，让监控系统变得更加智能，也不用像某些数据库监控还需要将连接的用户与密码写入到Zabbix的宏，而只要保证读取的配置文件在文件系统的AC1.上是最小权限即可，提高了数据库的访问安全.另外一点，现在很妥的分布式数据库也是采用控制+计算+存储的架构，例如TiDB的PD负责元数据管理、DB负责SQ1.解析与计算、KV负责底层键值对存储，面对众多的分区也好，副本也罢，最有效的监控方式就是宜接对接其管控部件，将Zabbix主控服务的起点映射至数据库集群的管控上，不断顺着架构分层，将各个组件之间的监控项固化成自动发现规则，实现精准有效的监控覆盖.以目前我们的OCeanBaSe分布式数据库监控为例，以下从OBRootService自动发散出OBZonexOBTenant.OBServerxOBPartition等监控细节.、一尸卜除了监控架构的不断灵活，我们也在考虑更加深入的监控效果，对于数据席的监控排查，DBA更多地希望所有相关的告警都是同一个时间点的，这样更加便于横向参照.根据这个出发点，运维人员利用"监控快照”的思想，将监控项尽可能多地集中在同一个时间点上，这样也能极大减少监控数据库时频繁交互带来的性能损耗.实现这一点，主要借助于自定义脚本规范和Zabbix监控项中的相关项目依赖特性。以巨杉数据库的监控为例，也正好通过其动作具有一定的性能消耗来说明减少交互频率的正要性.这台测试环境的数据库集群的Coord主机，总共有56个监控项，如果每一个监控项都不要单独连接到其中一个协调节点并做快照获取对应的监控指标，那么集群对于这些频繁的快照操作会付出非常大的性能成本.但实际上，这里真实的监控项只有3个，也就是截图中的multi_snapshot_SDBSNAP*开头的，其余的都是由这三个监控项派生出来的，也就表示交互次数可以从56次缩减到3次.我们对这种方案的实施，是通过自定义脚本或1.DDmacros来生成一个包含各个子监控项的JSON,并设者为不保存历史记录,这一点非常重要，因为子监控项的生成是在父监控项转阵前计算得到的，保存大量被拆分的冗余JSON字符串也没有实际意义.在子监控项的生成动作中，主要使用了Zabbix监控项的预处理操作，使用JSONPath将对应的K/V抽出，再通过倍数/每眇变更/正则等方式获取到最终的子监控值.虽然预处理会消耗Zabbix的CPU,但是实测调大Startpreprocessors参数后，CPU没有明显的攀升，而且ZabbixProxy是分布式可扩展的，这种瓶颈也非常容易通过扩容来解决。综合评估下来，这种方案带来的回报是很可观的，当出现数据库问题时，或许更多的DBA希望回溯监控历史，能够看到的是这样同一时间平面上的各项指标：Wwwr5“9gM2打40“xXQMT-12n4940.加gM2J14S%、293523S40»3»OT.12»4S40，p”Mir*。MM2n45402第5,2234540三M2OS12M必8r三mH2g7l2?JM8j一#ef422g712Z>M8Fr«，«7-I2n454X.Yjwwu<taMSXT12ZM582yHMffgTsntss“a<7<-应王0w三加?KMT12h498应用监控当监控的考虑维度上升至应用组件时，我们依旧坚持使用自动化的方式去面对眼花缭乱的监控需求，思考如何让应用的监控更加富有生命力，同时也分析了在过去使用Nagios进行应用监控时遇到的痛点，最终，编写一个框架级别的工具,接管应用的监控生命周期.这个框架在我们内部称为zbx_app,通过一个文件服务器和应用监控的准则来完成运行，可以自动完成自定义脚本拉取、版本迭代、自动注册监控项等，运维人员仅需要编写一份应用监控的声明文件，其他工作完全交由框架执行.此框架的内部原理，主要是通过Zabbix发送来特定的监控项和自动发现作为更新配置与自动检直基础环境的信号，如果发现文件服务器的相关模块版本更新则会主动拉取文件，从而实现自省理的麋作.这个接收特定信号并管理自身的环境的模块我们内部称之为基类，所有的模块监控会有一个自动发现规则与基类交互，如果基类声明文件里包含了请求的自动发现模块，那么就会应答，让Zabbix感知并利用返回的结果来生成此模块的监控项.对应的监控项生成后，每个监控项会使用快照的方法去捕获一次监控目标，然后再由监控相关项来拆分同一时间点上的各个子项.在这个调用的阶段，也是与基类交互的，只不过基类会根据其模块名来调用同步过来的模块方法的固定接口，这些接口是编写这类模块的开发准则，目的是为了保证基类能够顺利调用并解析.把考虑对象限制在一台主机上，简化这个流程，可以有如下的时间线，由上至下是时间前进的方向.ZabbixProxy会调用DiscoveryAPP自动发现，触发主机初始化一次当前的Zbxapp基类,基类收到信号后也会扫描环境，主要是收集各目录下的声明文件(s.cfg),并根据声明文件做一次基拙环境配因拉取，然后返回ZabbixProxy相关信息.ZabbixProxy收到了基类生效，其他模块的自动发现也会紧随着对主机做一次探测，发送各自的自动发现信号.基类发现声明文件里存在redis的模块声明，那么会把内部信息整合为自动发现返回结构体，ZabbixProxy感知后会生成对应的监控项。Redis模块持续发送监控快照谙求至基类，基类收到后会调用已经从HTTPFiIeServer上拉取下来的redis模块来执行监控请求,并返回结果集。如果过程中应用维护人员将url模块的监控需求写入声明文件，下一次接收到DiscoveryAPP信号时，基类会发现新增声明，迅速前往HTTPFiIeServer拉取指定版本的url监控模块.后续UR1.的监控也会与Redis一样持续生效，直至声明文件删除或注释了此模块.如果过程中自动化开发人员对版本库里的redis模块更新了代码，星类也会在下一次接收到DiscoveryAPP信号后对比MDS列别发现版本更新，从而拉取替换为展新版本。使用自管理的基类实现了应用监控的闭环纳管，监控的操作上，细分了自动化开发人员开发模块职能，也给应用维护人员更多的自由度去声明自己需要的应用监控.而且，对基类的动作也纳入一个监控项，能保证基类自己的瑁定，不至于罢工后无人知晓。通过这个他架，我们将应用监控从上一代的Nagios系统成功地迁移到了Zabbix系统，并且维护成本变得更低，运行模式更加稳定.业务监控当有了强大的应用监控框架支撑后，运维人员也开始更往上地关注更上层的业务监控，业务的特征也是整套架构运行稳定的最直白表现.Zabbix提供了数据库的监控，直接在网页界面直接编写SQ1.语句，由ProxyZServer通过uni×odbc加载对应驱动去连接目标数据库，最终返回执行结果,目前我们利用这种方法，对业务的状态信息、交易成功率、设备报活、跑批等进行数据施亘询，再通过Zabbix的告警渠道发送告警信息给全行订阅了这个业务系统的技术人员,直接在网页界面编写SQ1.能够适应业务查询的多变性，当受监控业务新培一个子系统时，仅耗要在其监控项里连接一个新表，不需要修改自定义脚本.另外，这种方法可以降低自定义脚本的维护成本，ODBC提供了多种数据库的驱动，在网页端开来底层一切都是封装好的，没有必要去考虑连接如何初始化、怎么建立游标、合适释放会话等.当获取到各个业务的监控数据后，能够平滑地对接到Zabbix的dashboard,为各个业务创建一个监控面板，实现大屏展示的效果.在实践过程中，对于这种便捷的监控方式，要特别注意几点：在文件系统上缩小OdbC连接配置文件odbc.ini的权限，仅保证zabbix用户可访问，修改由特殊用户修改.规范SQ1.编写规则，不允许出现执行成本较大的语句，这也需要跟DBA沟通好.尽可能地让结果集返回一行甚至一行一列.把数据计算操作分据给Zabbix预处理，不能把太多的计算操作下推至数据库层面.页面监控从上面讨论的各个监控维度上看，在一个运维的纵向坐标上，从硬件监控到业务监控，实现了屐底层到最顶层的全方面的监控覆盖，多个层面保证了监控系疣能够快速发现问题故障,进行准确的告警报送。但运维人员对监控的思考还没有结束，进而思考一个问题，监控的点位够否不单单在纵坐标上移动，而是可以前移至"未来”的时间点.例如不仅仅是用户登录系统进行交易后才触发一次失败才产生数据被监控,而是周期性地去探测一次交易前替条件，即便在没有客户进行交易时，也会有Zabbix在交易页面上探测需要资源是否具备。这样能够保证比其实客户更早的发现一些交易平台的页面异常，在逻揖上实现了“预知”的效果.另外，可以通过多个运营商线路去做页面监控，更加全面地覆盖客户案例，在发现异常时，也能够对比其他线路是否存在运行商的网络问题，例如CDN,黑名单等.我们使用ZabbixWeb的监控方式，通过防火墙和NAT的网络隔离，使用Squid实现线路选择，以及运用selenium等自动化工具进行页面动作模拟，实现了网银系统的内外网、运营商线路层面的监控.平台监控除了上面提到的监控以外，有一个特殊场景，是运维人员难以回避的，那就是某一些系统自带了一套监控平台，但目前使用的主流监控却无法兼容或替换掉它，当引入组件、产品逐渐增多时，这种问题就越发明显.例如移动开发平台mPaaS中自带了例如monitorkernelcorewatch,monitorguard等监控组件,对整个mPaaS平台运行具有非第圣要的作用，如果考虑使用其他监控系统将其替换，技术磨合的成本也会非常巨大，而且也丢失了平台自身的稳定性.对此，我们决定使用自建外部柒道加ZabbixSender实现外部平台以监控流的方式对接至Zabbix,这样既能既能避免对原有第三方监控系统的侵入，也能让其监控数据汇聚到Zabbix.首先，这里介绍一下ZabbixSender的原理。当受监控的主机在Zabbix中是处于主动模式的话（大部分主机是被动模式），该主机可以自行构建一个已存在的监控项数据发送给Zabbix,而Zabbix收到数据进行验证后，也会作为该主机的监控项数据，这样也可以实现监控的实时性。当对接主机的上游是第三方监控平台时，整个流程看起来就像动态的数据流一样，从上游不断流入至Zabbix.对接上游第三方平台的实现，我们目前有如下方案：当外部平台支持HTTPRESTfuI的监控对接时，将其对接至一个专门负责接受此类告警的HTTP服务器，并为其设苣一个独立的资源路径的handler.当外部平台不支持监控对接，但支持告警推送，可以将接受的告警级别调至最低或全量，将其发送给HTTP服务器、TCP/UDP服务器或邮件服务器.当外部平台没有任何渠道外送信息时，会选择网页爬虫、数据库监控等方式，当这样也会丢失监控流式的特性。以目前遇到的情况，几乎没有第三种情况，一般都是提供HTTP外推监控或告警的，所以这类都会接入到我们一个使用Golang编写的专用HTTP服务器，在每次新培对接平台时，增加对应的handler中的OtherReader和ZBXSender接口实现即可。但需要注意对于这种方式的触发器，需要着更关心Changeodiff()函数的依赖，因为有时候同一个监控项推送频率会非常高.还是以上面提到的mPaaS为例，通过这种方式对接其核心监控平台Corewathc,能够获取到此平台的所有告警监控.>HWSCermtai(WSMle，ra.：1JX-QME,E.«»'SfKrtto.ACfijrAncrtMUtrfM-A».*CS.irt11orMr.r,<T；.aAC1.EwewQrPrfwv»ACSJVAncrtMMtftfVM¾X<1.VW*ce,*nm*4<rA<.*r>S<rwrw-f.ktX"，AC5Rmw>r<S1.'IC.avnyMM,三r,y>r<、3.ctmh”/wAHifc-I.一arj.，心."rSa*SEMHTACSjr*m*MA-.4*CartQrM<.>wvw.，.sIryAC1.IrATMM_01.gP一,告警通知监控覆盖的话里，到此也算是结束了，下面进而讨论下一个环节，那就是监控触发的告警需要如何才能推送到需要接收的技术人员.其实,Zabbix自身也提供了非常多样的告瞥推送渠道，也可以自定义脚本来处理告警内容再推送给至渠道.但我们选择将这个推送的渠道稍微拉长，让告警发挥出更多的作用.如果告警无法推送，那么监控的意义就少了一大半，但推送的太多，告警也就没有价值可言.Zabbix的告警消息结构体只是一个字符串，有些特殊符号混杂会对后面的序列化动作触发异常，抑或发送告警的Proxy宕机了，而大果告警却发不出来。由此种种产生的困扰，想必每一个接触过告警的技术人员，都会深有感触。为了解决这些最后一百米的问题，我们也不断地尝试各种方法，目前也依旧在努力寻求突破.我们编写了一个内部命名为ZabbxiRobot的工具，可以按照预定的Zabbix告警字符串进行JSON解析，并在预处理完后，会判断此告警是否需要抑制，是否属于一次需要收敛的抖动，然后才把告警推送至下游.另外，在Zabbix的架构设计上，将一个负责主要告警推送的Proxy与Server配置为互相监控，而Server会有两个推送渠道在主渠道失效后进行通知，进而避免告警空白.这里的短息猫通过gnokii调用串行接口实现的短信发送，发送效率非常低，仅当探测发现Zabbix架构出现更大故障时，会应急发送给几位负责监控系统的运维人员.而备用渠道与主要驱动实现方法都是把告警信息以curlPOST的方式传送给ZabbiXRobOt,不同点在于两者使用了不同的Header,从而在ZabbixRobot中区分出具体的渠道，也会对此过谑.ZabbixRobot是我们使用Golang开发的HTTP服务器，目前具备两个模块，先触发抑制模块，后触发收敛模块.这里的抑制操作是以1.imitUnitGroup来生效的，当期触发条件满足每一个gorup的三元组（flag,number,second）,当判断为flag的告警，在second秒内收到了超过number数最）时，则会使用flag派生出一个InhibitionUnit的goroutine,而这个flag如果存在InhibitionUnit,那么就可以判断处于抑制状态，不会发送出去.InhibitionUnit也是一个三元组（flag,number,SeCond）,当判断为flag的告警，在收到number数量后或超过second秒后退出此次抑制.而在Zabbix-Robot的配置文件里，细分了每个flag和其属性.一股而言，目前常用的flag就是Zabbix的TRIGGER.SEVERITY,即告警级别。收敛模块是目前在测试阶段的一个功能，优先实现了Weights的方法，即判断收到告警与过去三十分钟（可调）样本中的hostidX_+_itemidY+triggerid*Z总分，如果超过预定值K,则会被判定为抖动进而收敛.这里的X/Y/Z是可自定义的权重，比如可以通过提高X来把收敛权重倾向于主机，那么同一台主机发送的告瞥数则会被优先收敛.另外还有其他收敛的方法，比如字符串特征和机器学习，这两个也是我们尝试的方向.当走完抑制和收敛，告警会流向我们的自动化平台，并由平台判断是否派生工单，然后再经订阅系统把告警发送给指