“光大银行为了解决传统监控管理的痛点,从监控平台的建设和全站监控能力,大屏可视化展现和智能监控分析这四点出发,打造了新一代的一体化的统一监控管理平台。”
——马文杰, 中国光大银行总行信息科技部 高级项目经理
本文整理自马文杰在2020Zabbix中国峰会的演讲,ppt网盘链接:https://pan.baidu.com/s/1Q4QttDD_4OCf1J978NFF5A 密码:nbac。更多演讲视频可关注官方Bilibili账号主页(ID:Zabbix中国)。
我将从开源监控探索历程、经验分享及对未来监控的展望三部分展开分享。光大银行是中国光大集团的子公司,是全国性的股份制商业银行,目前在内地有39家一级分行和五六十家的二级分行,以及4家的海外分行。
经验分享部分预告(敲黑板~)
传统的监控管理有哪些痛点呢?主要总结为以下四点:
那我们怎么去解决痛点?光大银行的科技部信息数据中心提出了四化建设,分别是敏捷化、数字化、服务化和智能化。
光大银行为了解决传统监控管理的痛点,光大银行从监控平台的建设和全站监控能力,大屏可视化展现和智能监控分析这四点出发,打造了新一代的一体化的统一监控管理平台。
光大银行是从2005年开始逐步去配置监控手段,到2018年新的监控平台进行投产运行。新的监控平台是以Zabbix为底层的采集工具,并且逐步替换现有的像IBM的ITM,或者是OVO等传统的监控工具,形成了基于Zabbix的监控标准化管理,自动化管理、可视化管理和智能化管理,不断提高运维管理的全面控制能力。并且2019年也完成了科技运营数据平台,即大数据平台的拓展运行,以产学研的方式落地AIOPS,引入多种算法分析,实时处理8大类运维数据。
光大银行把Zabbix作为我们的重要的监控手段,在选型的时候已经对比了从基础监控能力、可扩展性和社区资源等多个方面去对比了Zabbix和其他的几款开源软件。
我们认为Zabbix是一款支持多平台的企业级分布式开源监控软件,并且它可以支持多种的复杂条件的多条件告警,并且它提供多种的API的接口,支持二次开发,并且它还具有非常好用的一个自动发现和低级别发现的这样一个功能,有丰富的社区资源,所以完全满足光大银行对开源监控的需要。
Zabbix在光大银行的开源监控体系中的一个作用是什么呢?主要分为以下几点。
采用了大家比较标配的一个keepalived方式,去实现我们的Server的高可用。Mysql是采用互为主从的关系,即双主模式,通过binarylog的双向同步,在任意一台的Mysql写入都会同步到备库。keepalived是用来监控关键服务的进程和Mysql的进程,检测到故障的话,就会自动切换到备机,就实现这种自动切换,无需手工操作,监控无终端的模式。
zabbix server是从zabbix agent采集监控数据,性能数据入库ZabbixDB,通过flume软件定时去获取监控对象的监控数据,并把它推送到Kafka、大数据平台。其他的像容量监控其他这种系统就会通过大数据平台去消费Kafka的监控性能数据,并且进行一些趋势预测,根因分析、阈值修正、容量分析等各种的大数据分析的功能。
跟其他的可能有点不太一样,自动发现模块是在Zabbix原生的自动发现的模块基础上进行了一定的扩展。原生的模块能够发现指定网络的主机,并且能够发现该主机里面的深度标准化的数据库或者中间件的软件,就例如像Mysql,Oracle,Redis,tuxedo等,前提要做的是深度的标准化,才能去发现这些这些模块这些软件,发现的新主机、新实例,通过自服务的模块去上送到统一监控管理平台。自服务模块是面向用户的可交互的页面,用户会去通过页面去补充监控凭证,就例如像密码之类的数据,通过下发监控策略,更新监控状态,达到监控主机和实力的自助式的监控。
Dbforbix是 Zabbix集成的数据库的插件,它支持Oracle、Mysql、Postgresql、DB2等多种数据的采集。取用bdforbix是因为之前发现原生的Zabbix Odbc这种方式监控是存在一些问题的,所以去启用了这样一个插件,并且会在这样一个插件上面去做一些机制优化,功能优化和功能上的扩展,优化了Dbforbix的任务调度的定时机制,并且增加了简单检查类型的监控指标项目的支持。还把原来需要在后台修改配置文件、重启服务才能生效的监控模式,修改为只需要在页面端去配置就立即生效的功能优化,最后还支持了一些指标频率采集的实时修改。
下面再分享一些比较重要的也是比较容易忽视的一些功能。加密其实对于银行业来说是一个非常重要的功能,因为像银行业的话,每年都会有审计过来去审查,因为监控系统是连接到银行业各个业务系统的,如果密码是明文化的,或者是通信是不加密的,都会被审计的审查的,都会有产生一些问题。
所以这边的话通信的话,是采用Zabbix的原生的 PSK进行的被监控主机,agent的和server之间的通信加密。因为当时用的是4.0版本,还没有像5.0现在就有这种自带的原生的加密的方式,所以采用的是基于Linux系统自带的一个base64对宏变量中明文密码进行加密,进行采集的时候再去在底层进行一个解密的操作。
通过标签使用,是丰富上层的监控平台提供一个告警字段。因为监控系统的监控类型是分为三大类的,包括大类、中类和子类。举个例子,假如说数据库是大类,Mysql是中类,表空间是子类,通过这种类型的划分做到为告警人员和提供特别准确的告警通知。通过宏变量使用是为监控数据采集提供必要的一些信息凭证。
这是自研的一个模块,我们是 EPP模块从通过Zabbix的自带的API去提取读取告警数据,对数据进行一些规则解析,丰富处理和微容器处理,并把它打入到内存型数据库里去。最后处理后的告警数据进入到统一告警平台进行展示和告警。
配置前提需要深度的标准化。以Redis数据库为例,不同版本不同模式,假如说无论是主机备机还是哨兵还是集群,各种模式,我都把这些条件作为一个单独的item做处理,在每一条告警触发器中都加入以上的判断条件,就会实现一个监控模板的统一。假如说在不知道这台 ready服务器是主机还是备机,还是哨兵,只是需要去把模板关联上,它会自动读取版本信息,会去使对应的策略去生效。这样做的好处对于日后自动化监控部署的实现,我们一直认为自动化的前提标准化,只有把标准化做好之后,才能去实现自动化监控,以至于后来的智能化监控。
主要也是分为五大类,第一是清除无效指标,包括一些不可达不支持的指标,这些指标的话会增加性能消耗,造成恶劣的堵塞。第二是部署的优化,也是包括一些使用模式,Zabbix agent的使用主流模式或者是mysql的调优,一些参数的调优。第三是资源配置优化,数据库要尽量使用物理机,使用proxy分布式的架构,在性能上带来一些优化。第四应用优化,采集频率不要过高,避免去使用像可计算的这种类型的指标项,推荐会比较使用dependent item依赖指标,并且减少明细数据的存储,增加区数据的存储。最后是源码优化,会使用加固后的dbforbix这样的插件。
最后一部分是对未来监控的展望。总体来说我们认为是向数字化运营态的转变,包括提升动态,提升洞察力和智能分析能力,主要也是分为以下四点。
对于金融行业来说,稳定和安全是最主要的一个要素。
我今天的分享就到这里,谢谢大家。ppt网盘链接:https://pan.baidu.com/s/1Q4QttDD_4OCf1J978NFF5A 密码:nbac。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论3 条评论
2021-09-29 09:11
2021-09-24 08:16
2021-02-23 15:15
Zabbix_小Z: @wellyoung 开心~ 欢迎关注:Zabbix 开源社区。