（本文整理自民生银行王斐在2023Zabbix中国峰会上的演讲，点击图片查看视频，更多内容可在B站“Zabbix中国”查看）大家好，我是来自民生银行的王斐，给大家分享民生银行在Zabbix相关管理上的应用成果，还有Zabbix管理平台的建设——潜望者的处理过程和效果。通过打造自主加开源的一套监控体系，保障数据中心基础关键设施的稳定运行，为业务保驾护航。2023年，中国民生银行位居
英国《银行家》“全球银行1000强”第22位，
美国《财富》“世界500强企业”第329位；
中国银行业协会“中国银行业100强”第11位，
全国工商联“中国民营企业500强”第54位。
民生银行于1996年1月12日在北京成立，是中国第一家主要由民营企业发起设立的全国性股份制商业银行，2000年、2009年先后在上海证券交易所和香港联合交易所上市，现已发展成为一家总资产逾7.5万亿元、净资产逾6300亿元，分支机构2700多家、员工逾6.6万名，拥有商业银行、金融租赁、基金管理、境外投行、银行理财等金融牌照的银行集团。
监控场景：服务于故障发现、应急协同、生产运营和监控管理这4大类场景。监控能力提供了监控指标体系、计算中心、故障分析中心和运营中心4个方面。支撑系统涵盖Zabbix潜望者、交易监控、网络监控、机房监控等等。其中Zabbix潜望者作为基础监控能力最重要的一个环节。
可靠的基础才能决定上层良性的应用搭建。对于Zabbix潜望者和Zabbix本身提出了以下运营保障的要求。第一，配置统一化管理，要求覆盖整个数据中心的关键基础设施。第三，把配置信息作为整体资产纳入到长期的管理规划中。实施部分，因为民生银行存在有大量的新老混合运行的各种类型的信息系统，对这些信息系统标准的监控，就需要建设一套标准的监控实施规则，同时每年民生银行规模以20%的速度增长，整个生产规模在持续的增长。也需要满足生产的要求，把这些相关的监控实施还有部署交付给用户，让他们参与到整个建设环节里。监控可靠性建设。提出了需要提供一套监控值守保障的能力，同时对于监控出现的问题，实现故障的管理和跟踪机制。监控异常引发告警风暴的时候，能做到异常控制以及止损。数据场景建设。监控是整个数据中心的重要的数据输出源头，要求在故障发现环节提供更为丰富的告警信息作为支撑。应急协同的时候，需要提供更多的数据的关联运营。运营管理场景下，需要为各个应用系统和大屏管理的运营，提供数据消费的支撑。最后自身的场景，也希望降低运营管理的费用。
问题管理，包括问题采控，以及异常止损等等一系列的能力。Zabbix集群管理，维护越来越庞大的 Zabbix集群，把整个集群作为一个整体的监控任务的资源池，实现监控任务的及时调度。数据管理，要满足高吞吐以及数据增强的效果。底部依托于 Zabbix原生的能力，包含API事件，持续数据的持续消费，同时还要依赖于行里的相应管理规则，以及相应的问题的处置流程。第一、现在的监控规模非常庞大，导致所有的监控配置分散在不同的环境上，可能这些环境都不是相同的一个server和同一个版本。第二、关于配置的信息，虽然已经有采集，但是这些信息是否足够完整，是否可以在后续的过程中进行跟踪，同时相关的知识经验该如何记录，面对如此庞大的这些信息，应该提供多大的维护力量。
建设的过程分为4个周期。第一个阶段通过周期性的采集，把所有的server相关的配置集中获取。第二个阶段当发现这些实时或者是定时的处理效率已经不足以满足实际使用需求时，借助于CDC的技术，实现了在数据库层面把配置信息做汇总。之后，又开始提出了参考数仓的建设，持续完善数据的消费和使用场景。最后把监控配置作为资产化的管理，进行整个生命周期和过程的完整记录。
实时同步，采取什么样的方式？设计之前，有两个构想。第一种方式，在Zabbix前置，同时API或者server前置进行拦截，发现到底有哪些自发现，可能还有API调用，看看当前有哪些配置的变化。第二种方式，在数据库层面初始数据，捕获数据变动。比较这两方案，认定是通过底层处理逻辑，对于整个Zabbix运行更为可靠或更为独立的旁路方式去获取配置，可靠性会更高。借助 CDC消费数据库的binlog，通过KAFKA推到ETL的清洗流里，最终实现集中汇总，完成统一汇总。之后建设相应的数据场景，参考数仓建设，完善数据层领域，把偏底层或者源头这些原始数据进行扩展，丰富它的使用场景。通过引入了两种知识，一是关于运维，静态的库的配置，通过定时采集的方式汇总在配置中心。第二关于cmdb主题，通过实时推送最终汇总到整体配置中心。最后结合数据标签和数据标记，配置实现了策略或者自动的维护能力。数据过程，对于数据资产的管理，记录它相应的过程。实施过程、异常过程以及发现过程，引入Zabbix渠道，流程渠道，把日常的变化、处理过程信息，写入当前配置以及日志变更库里，实现几个应用场景，完成回顾，能够看到记录。如果出现变更异常，能够快速回退。涉及到外部的审计调阅，提供一个长期持续的记录。实施管理痛点与诉求
两个痛点。首先为了保障基础设施建设可靠性，在设定指标层面,并不是通过单一的维度和单一种方式，Agent或者HTTP的方式，通常会设置多种探测角度去观测被监管对象是否运行正常，监控指标就非常多。监控的维度和渠道也特别多，如何做到快速精准的完成实施工作，这是第一个痛点。第二在维护大量指标时，用户通常也需要对于这些监控的阈值规则进行相应的调整。对于监控的逻辑来讲，它有一定的学习成本。用户一般会人工沟通，或者登录服务器，结合观察的情况处理，这种沟通还有相应的学习成本，对于用户来讲负担较重且学习时间较长，如何解决这些问题。实施规则化建设历程
1定义哪些策略，定义的是监控对象，行里有大量的基础设施，这些对象有不同的指标，需要维护一个更为完善的规则。2监控任务具体运行在哪些环境中，需要实现相应的调度的规则。3客户化如何简化用户维护监控的配置。结合这几点规则，定义做了如下过程.第一，指标模板，在原有的模板基础之上，通过识别到的这些监控可能来自于不同的模板项，可能来自于不同的采集数据源头，需要将多种模板或数据指标或者特殊监控项进行整合。同时在日常的指标开发和维护过程中，像JMX或者数据库中间件之类的，会发现他们有很多个共用的或者通用的指标，还有个性的指标，这种指标，通过做公用指标能减少开发成本，但是这对于实施部署来说会有些麻烦。如何通过这种组装的方式，把特殊和通用形成一个标准的规则，最终实现成一个模板的 plus版本。第二，在API这一侧做相应的包装和增强，通过提供限流角色校验和多server的一个路由能力，保证API的高可用，同时也保证底层在维持server作为的资源池，能够实现最佳性能容量的均衡。第三，环境选择，如同上面所讲，借助整个大数据框架的模式，把server作为具体的运行资源的一个节点，对于server上的环境做特殊的限定，来自于网络域，或者来自于特殊的版本的要求，最终达到性能和容量的最优解。最后，关于客户服务，因为Zabbix trigger提供非常自由灵活的方式，但是灵活对于用户来讲未必是最佳解。对表达式进行精简简化，还有相应的一系列翻译的手段实现它易读易用性的。最后同时和行内的工具工单平台，还有各种管理平台进行集成，实现整个自动化的操作。模板实际上是通过在现在基础模板加特殊监控项再加环境，共同维护相应的配置规则，通过定义对象的采集渠道、监控的维度，最后还有环境的一系列要求来定义的一个plus版本的模板规则。API部分，通过定义认证中心，借助网关，加入了渠道和身份信息的校验，还有规则中心，把每一个对象级别的监控拆解成不同的模板，或者监控指标级的实施任务，最后交给路由层，分发给不同的具体需要承载的Zabbix server的环境。最后在API层又增加了一层API的代理，提供了相应的并发流量的管控，提供了升降级的机制。客户服务，这里列了一个类似CPU的使用率的例子，识别出其中存在的宏变量。还有自定义的变量显示，这种变量最终在给用户展示的时候就会变成一个客户化的表单，实际上是屏蔽了具体的函数，还有具体使用的细节。最终形成了一个用户可以填选的表单，节省了用户对监控配置维护的学习的成本。
同样也有两个方面的痛点，在日常的配置维护，甚至还有工具运行的过程中，经常会遇到这些工具存在异常，不采集数据或者心跳异常等等，如何感知并且帮他们区分到底是一个小故障还是大问题，这是第一个痛点。第二在遇到出现这种问题的时候，恢复故障很关键，但同时触发这些异常的时候，也会导致有大量的无效告警和误告警，对用户也是极大的干扰。那么如何定义防御策略和应急策略，如何在两者策略之中平衡，这是重点需要讨论的。可靠性认定需要通过多种渠道，内部外部共同来对工具运行，还有工具本身进行观测和维护。对多种数据源进行比对，或内外部渠道进行探测，以及定义止损和恢复的策略。首先是关于配置可靠，配置实施永远可能存在误操作的风险，这定义了如何与CMDB进行绑定，要求与CMDB的内容或者监控对象达到一致。第二是内部，依赖于Zabbix 自发现的能力，实现了这些内部的指标库等等对象的细粒度的发现。采集可靠，定义了需要涵盖点对于点和面上的问题都需要发现，包含通过no data这些对于单个指标采集结果的检查，还有延迟的情况进行判定，同时也增加了自监控，还有流量的统计从而发现更粗粒度层面上数据的异常。数据链路是在上送的过程中给上层的应用提供支撑信息最重要的一个通道，这里提供了相应的心跳检测，还有故障的迁移，同时在建设的时候也设定了多活的链路，保证链路多活可靠。最后关于数据补发，提供了数据补发以及告警风暴压降无效告警丢弃等一系列的策略，保障出现异常的时候及时止损。第一，出了问题之后，实际上需要有一套非常完整的问题管理的机制。实际上参考ITIL相应的问题建设思路，定义了问题感知问题分类止损，还有相应的一系列工具箱。通过实时的定时的巡检采集，还有实时的异常告警推送，把相应的问题推送给问题管理中心，通过对问题进行创建分发标记，以及主动防御策略的相应的处罚，实现问题的分类与治理。同时也提供了相应的一组运维保障的工具箱，通过大盘日常的可视以及告警压降等等一系列策略，保证故障不会突破整个监控管理的范围和体系框架。运营大盘，这是运维最常见和需要的，它把日常所需的数据投射在这相应的视图里，比较关注的是对日常监控覆盖的差异比对。还有disabled/ not supported等一系列的状态，相应的差异的变化，帮助在每天的巡检提供一个主动的窗口，方便运维人员及时发现异常。第二，告警压降，当告警风暴出现的时候，尤其是大量的之前经常出现像nodata告警风暴或者是异常，或者模板变更，大量的无关的或者说需要待观测的告警，需要定义一个在压制策略引擎里一系列的规则，通过对特定的时间窗口的检测，还有数量累积的检测，具体哪些指标去判定，对现有的规则进行检查，最后它会命中相应的一系列的压制的动作，对原始告警的屏蔽或压制。第三，同时持续监听现在的恢复的过程，最后可能还会派生出来相应的新的告警，保障告警迅速得到收敛，同时也能及时告知给相应的运维人员，还有保障人员。那么配置迁移，实际上是提供了一套可靠的方案，可能大家也看到个p0级别的故障，他们可能基本上来自于原地升级等等一系列的这些问题，这种原地升级在数据中心层面来看，是有一定的风险的。我们建设了一套相应的包括迁移也好，或者计划内或计划外的迁移也好，能帮助把这些监控的配置任务，从一个server或一个proxy迁移到另一个环境上。这里分别引入这些过程，包括故障的评估，配置，以及完成了配置的集中收集，可以通过API方式给别的 server执行相应的任务，还有创建相应的主机，分析运行大盘，做事后的评估，观测故障是否得以恢复，以及迁移后是否运行稳定。最后整个监控任务再切回原有的环境，保障监控的连续性，避免单点的存在。
第一，输出了大量的告警，输出了一组相应的许多规则，同时还支撑很多数据的分享，告警之后，用户常问什么原因甚至是不是有更多的详情支撑我去分析。第二，有关阈值，当不需要关注时，如何优化阈值，怎么预优化才能达到最优的一个平衡解，或者如何帮助他们去减少阈值优化层面的困扰。第三，需要很多持续的数据支撑用户在其他的大盘等等一系列的场景监控的观测，对这些数据层面面临的诉求，数据场景是明确的价值，希望提供一组易于分析的数据，通过定义的规范，还有接口，帮助大家快速消费或者捕获所急需的数据，包含告警阈值，还有时序。第一个案例，讲到对于故障这一方面输出告警。捕获相应的故障快照，这里提供了类似的，像数据库或者操作系统或者应用，为了提高也是避免统计这种数据通常需要耗费比较长的时间，把它做成异步的方式。自动化的信息采集，通过访问Ansible，尝试调用采集的脚本，通过告警触发，实现了对上述的关键信息的采集和推送的能力。第二关于阈值推荐，阈值推荐因为已经建设了一套相应的告警，还有一套分析的中心的能力，等于说是把这些关于预测还有动态基线的能力，反哺于相应的告警，阈值优化的场景中，借助了计算中心里的两大异常，还有动态基线和异常点检测的两种模型，补充相应的度量因子，最后给出相应的最佳推荐的阈值。举个例子，如何做到阈值推荐，首先获取了所有的历史趋势数据，对历史趋势的数据排除一系列的离群点、异常点的干扰。接下来计算相应的数据分布基带的情况，再补充相应的度量因子，度量因子来自于很多都是配置层面的数据，交易类的，或者日间类的，还有夜间跑批类的，通过给出对于基带相应的系数的增强，扩宽它相应的容忍的一个区间，最终给出一个估算的阈值，降低整个用户的使用成本。最后关于持续建设，也是使用了规范的数据协议，建设了一套自己的TSDB持续集群库，通过网关，还有读写分离这一套逻辑，实现写入层还有查询还有汇聚层的独立。最后有一组相应的一个TSDB的集群和分片库，实际保证这些数据在不通过访问Zabbix的情况下能快速交付给用户。
在做整个监控的过程中，实际上认为整个监控体系，并不是一个单独的系统，而是一个系统工程性。每一个组件不能作为整个系统的一个银蛋来去处理，需要引入这一堆系统，达到整体的一个平衡。作为配置管理系统，帮助整个管理团队实现管理和改进的良性循环。第二技术层面，又向数据中心上层提供了一个完美的数据底座。第三关于数据中心的各方面能力的程度，相互支撑，相互演进。最后感谢整个Zabbix社区和宏时数据给予这一次机会，希望在未来，共同成长。延伸阅读
2024-03-27
Zabbix 下载
Zabbix 手册
Zabbix合作伙伴地图
成为我们的合作伙伴
订阅系统登录
