长文|太平洋保险基于Zabbix的智能监控体系

将从太保监控平台建设历程、基于Zabbix的一体化监控平台、融合监控数据、打造智能监控平台、发生即发现、发现即处置的智能运维体系方面来分享。

——杜颖君，太保科技，自动化运维专家

01太保监控平台建设历程

第一部分呢，我们介绍一下我们太保监控平台的一个建设历程，图上我们可以看到，我们那个太保是从08年就开始集中建设这个监控的整体的一个体系。

我们是从2008年到2017年，基本上都是使用的BMC的这个商业产品。从17年开始是探索商业产品的一个替换方案。从18年开始呢，是正式确定了这个使用Zabbix替换这个BMC的这个方案，在测试环境 & 进行了一系列的这个论证之后，从2018年到2020年这个阶段，逐步替换，2020年我们是彻底把这个监控指标采集的一个体系全部换成了这个Zabbix替换的产品主要是BMC和Netcool的一些功能。我们现在这个阶段，主要是致力于故障预警定位和一个智能排障的一个分析场景。

说到监控呢，那肯定离不开它后面的一些运维工具，我这边也顺带介绍一下，我们太保内部这个工具平台的一个建设历程。我们对于自动化运维和监控体系相关的一些东西，是从2014年开始建设的，我们主要还是经历了四个阶段，现在还处于第三阶段，基本上是实现了一个前台化和自动化的场景，还有就是第四阶段，我们认为智能运维的体系，应该是一个数据驱动，可以有故障自愈的场景，会越来越丰富，我们现在逐步地开始尝试做这些东西了。

后面这一张图，是我们太保现有的一个工具平台的一个整体介绍。前面的，是我们一些功能平台，大家看到我们有私有云管和那个容器平台还有自动化运维平台。最底层的是我们的一些接入的s层的一些设备，旁边那块，我单独抽出来的是一些配置信息，数据采集相关的一些功能。主要是监控和日志还有我们的CMDB，中间这层是我们的服务网关，其实我们也抽象出来，作为一个运维能力的一个中台。上层，我们是会分装各类的一个自动化运维和监控相关的一个应用场景。我们还有一系列的低代码平台，大屏展示的一些用户UI的系统。

2、基于Zabbix的一体化监控平台

这个是我们内部的一个Zabbix使用情况，第一个我们也是实现了这个两地三中心的一个分布式的部署，纳管大概是开发测试生产3套环境，6万个节点，，监控指标我们基本上达到2,200多个。 后面，我们介绍一下Zabbix比较好的特性吧。

第一个是阈值的定义，我们主要用的比较多的就是触发器的一个功能。

第二块配置模板，那这个是对我们的整体的一个配置工作量是有较大的减少，分布式部署那前面也介绍了，我们两地三中心多套GPS统一管理支持的相对来说比较好，告警配置，Zabbix里面的宏定义的这个用法，也是在我们内部用的会比较多一些，主要有一些相关的信息，直接可以通过Zabbix进行分付，上层也还做了一些我们内部其他系统提供的一些数据封装，这是结合起来使用的。

第三个是自动发现那做说到监控。这个肯定是监控盲点。也是一个非常重要的一个话题。自从引入了Zabbix以后，对我们的监控自发现还是非常有帮助的。主要文件系统和端口，他的发现能力，对我们运维同学来说其实工作量也是降低不少。

最后一块是数据导出，这也是我们实现后面数据分析的一个重要的依赖，这也是Zabbix不同于商业产品的封闭性的最大优势。

这一页，主要介绍一下，我们在Zabbix建设过程中的遇到的一些问题。

第一块是单套Zabbix，我们现在每套基本上是大概是2,000左右的节点，那这个也是Zabbix这个体系，单套只能管这些，再管多了可能有性能问题。

第二块是网络设备监控容易遗漏，经常出现监控盲点。其实我们也是结合了我们自己内部的一些就是上下架流程,把我们的CMDB的一些综合信息给结合起来,这个主要依靠资源去解决这个Zabbix本身的一些弱点，指标覆盖，刚才也提到了宏变量这些关键指标的配置可读性比较差，对于我们真实在一线的运维同学，这个可能确实不太好理解,我们现在也是逐步在做这个,因为指标非常多我们也没做全关键的指标，我们是做了一个整体的翻译,也建立了一些规则去做的。

第四块就是监控对象的生命周期管理，之前我们在没有上这个生命周期管理的之前，如果有些设备下架了，因为我们内部有一个就下限等于暂时保留运行，但其实这台机器已经不作为一个业务系统使用了，那这在这种环节当中，就容易出现一些误告警，我们现在是把这个跟我们CMDB包括我们的一个设备上下的整体流程结合起来，一旦在设备开始脱产之后，在存留的阶段，我们是不会自动把这个告警抑制掉。

最后一个Zabbix的依赖于关系数据库。那我们是主要就是把这前面提到的那个Zabbix它本身，有一个数据导成文件的一个功能，那我们先把它导成文件，然后再用FileBeat采集到我们的一MongoDB当中去，我们叫运维数据的一个中台，后续我们所有的一个分析啊，汇聚都都是从这个总线里面去走的。

Zabbix的信创适配也是现在当下比较热门的一个话题。

左边的是我们在内部就Zabbix纳管的这个组件，操作系统层级统信、麒麟、红旗这块都都已经尝试过了，数据库这块我们腾讯、阿里和那个达梦我们都用了，这些都是我们在太保内部已经实现纳管。

右边这块是Zabbix的适配，统信、麒麟操作系统上部署Zabbix我们都试过没什么问题。主要数据库这块，因为现在那个信创的数据库，他可能都是基于这个MySQL 5 版本，那Zabbix本身，可能是要求8.0那这一块，可能我们是存在的疑惑比较大。那我们接下来是准备看腾讯的这个TTC和MySQL的版本，但我们现在还没有完全投产使用，只在测试环境上运行，跑是能跑起来的。

这个是我们太保内部的一个整体的一个监控平台的一个架构示意图。也借这个机会，跟大家分享分享一下。

我们是三中心，我们异地的成都数据中心的环境相对来说比较复杂一点。其实它涵盖了Zabbix和测试，也有小部分的生产系统也会在那边，这边是我们的上海两个中心，一个原来是在田林，还有一个是主中心。我们现在是在罗泾，田林的那个已经等于是告一段落了。

那我们后面也建立了跟阿里云的合作，建立了一套新的数据中心。我们的监控体系，还是基本上保持不变。三中心的架构以Zabbix的several为主，然后我们自己封装了一个整体的事件管理中心，这个我后面会重点介绍，然后是通过数据，以文件的形式然后采到消息对列里面去，再结合一些流式引擎，做一个数据的汇聚，就上面这块，是我们内部的运维数据总线，其实类似于一个小中台，我们所有的监控类的数据，不光是Zabbix的，还有一些链路监控和一些额外的硬件监控，都会放在这个总线平台里面。

那我们事后的一个分析，主要是依赖MongoDB提供的一个数据服务去做，另外一块和日志结合的是在ES里面，这个就不在这张图上说明了。

这块呢是主要介绍一下Zabbix的成效。从降本、增效、赋能三个环节来讲。

降本那个显而易见，其实刚刚创始人也提到了，我们Zabbix是不会受使用数量的限制，是我们最大的一个优点。

另一个就是增效，监控盲点无效告警，这个是肯定是要优于以前的监控平台的。Zabbix本身时效性和那个BMC上面提升，其实也是不少的。因为我们上了Zabbix之后，同期的这个纳管的节点其实也是在倍速增长。

最后一块，赋能就是数据开放性，这个我觉得是重中之重。因为这块的运维数据里面的监控，其实是一个大部分，因为你采用是商业产品的话，后面的一些分析汇聚，我们自己的发挥的空间就会比较少。

3、融合监控数据，打造智能监控平台

第三部分结合这个监控数据，内部自己封装的一个在监控范围内做的一些主要的一些研发工作。

第一个就是运维数据的治理，这块我们内部是把它分成三个层级，第一个原数据层，那我们现有的一些自动化监控日志和CMDB云管，吐出来的数据，包括监控采集数据，我们其实不同于传统数据中台的做法，我们还是按需做索取，就不会把它全部克隆出来，然后再去做一些真正的统计分析，因为这个运维数据和业务数据，其实还是有有比较大的不同之处，业务数据70%-80%都是有价值的，但运维数据与这个比例是其实是反过来的，所以包括我们这样做的好处是硬件成本可以相对节约，对后面的一些性能也是有帮助的。

第二层主要是公共维度层。我们的团队会去建设一些抽象的这个公共体，公共层值的就是计算结果。我们自己也会提炼一些各个专业运维团队他们所需要的数据分析，我们计算好，比如说类似于平均值，或者是一些数据，另外把数据结合我们完整性分析都放在这一层去建立一个整体的管理体系。

还有一个生命周期，我觉得是相当重要，因为这个东西我们之前也是走过一些弯路，做了那种数据壶的这种模式，但是发现体量越来越大，存进去之后，拿出来会比较困难，后面也是经历了反正很多个版本的迭代，最终是把它决定是放在MongoDB里面，这个其实也是已解决的问题，包括生命周期，相对来说比较好管理一点，你不要的就尽快把它删掉，这样的话针对平台说是一个瘦身，不要太笨重。

分析决策预测，这一块，相对来说开放一些，我们会跟专业团队共同建设，有一部分就是他们拿过去直接做一些小的运维场景，另外一部分，比较大的一些分析决策预警预测，是我们整体的运维工具研发团队去实现的。

第二块，基于Zabbix这个之上封装的一个整体的高警与派单平台。前面，正好创始人也说了，Zabbix是一个处理指标的工具，那基于这个工具之上，告警与派单，我们替换BMC是在2020年，他有一块整个的告警事件处理的模块，其实我们是到今年上半年来彻彻底把它换掉的，原来还是一直在用，因为这块其实Zabbix本身也没有。

我们是后面也是因为派单这块在我们这个太保的这个体系里面是相当复杂的，我们收敛规则派单规则的这个图，其实这个是1/10都不到啊，这只是截出来的这个配置化的一个流程图，but还没讲完，旁边是一个整体成效，就基于我们这个智能的告警收敛的平台，总体来说我们这个收敛率可以达到40%，就无效告警是大幅度减少，这个口碑还是非常好的，然后我们这个整个平台，也是属于自主研发，这个好处就是可以贴合我们内部，这个相对来说是真的又个性化又复杂。

第二个就是预警机线，其实我们还是基于一些规则的算法去实现的，其实我们在18年也尝试过引入一些AI相关的这个智能算法，当时弄下来其实效果不是很好，那这几年呢，大家对AI这个东西运用在运维这个场景下面的这个想法应该也是回归理性了，那我们是最终还是在今年上半年把这块东西给深化再提炼了一下，上面这张图，我觉得是用在监控上面是比较好的。

海洋法则就我们传统的监控平台，基本上这张图上的1和29会监控出来，至少会报警，那下面这个300和1,000我们是肯定不会去做报警的，因为这个量太大而且他真实需要去处置的情况其实是很少的，所以我们是结合这个预警，我们后面还有一个诊断的功能，那就是把这个1,000和300那事情我们也会去做一些处理，提前干预，那其对于监控来说呢，我们现在最大的挑战就：我们能发现问题但是留给运维真正处置的时间其实还是不够。那还是没办法真正做到在业务出现影响之前去把它处理完毕，其实这块呢就是用起来之后就逐步是可以把我们这个留给中间运维同学去处理的。

这个是我们内部也是今年重构的一个应用拓扑关系,CMDB是15、16年就上线了,但这块数据,我们在去年年底开始规划,回顾这个数据治理方案的时候,发现这个拓扑呢,基本上已经是完全不可用了,但是,对于我们的这个应用故障分析来说,这个拓扑其实是至关重要的，从我的角度来看啊，从运维工具发展到现在这个阶段，这个CMDB建的好不好，其实就看这张图的完整性，它能不能发挥真正价值，除了替代这个，这个表单登记的价值之外，那这个关联关系我觉得是至关重要的，反正也是我们后面基于整体的一个预警加诊断的重要的依据。

第五步，前面其实都是为这一块东西去做铺垫的，上面的业务黄金指标，三个圈，这个就是我们作为的基本的预警的一个输入，那也就是我前面海恩法则上面那张图的这个下面两层，发现之后，我们不会去立即处理告警，会通过流程引擎，去看一下，配置，也可以说是一个排障过程，但这个东西全凭经验，全凭手工配出来。后面一个横向的就是链路绘制的一个全链路系统，它可以采集应用之间的一个关联关系，我们会把这几块，都是综合起来再看一看然后确实是有问题的之后，那才再发出真正的这个报警，这样的话，就等于说我们提前干预度，其实是往前走了不少的，这块其实目前来说，还属于酝酿过程当中，因为这块，看到的这块流程，是原生、是基于自动化平台的一个作业流程的引擎，它用在监控上面，我个人觉得，它的性能上面还是会有一点挑战的，规模小的时候还可以用用，之后肯定是会越来越吃力的，所以我们后面也会引入一些AI相关的或者是更先进的理念来做这块东西。

4、发生即发现，发现即处置的智能运维体系

这张图是我们后续规划的整体的智能运维的监控体系，最左边，从整体的数据到观测和分析，在分析这层，会封装各种各样，相对来说跟运维相关的场景，最左边我们也看到分几块东西，一个就是我们是会做运维的，这种类似于BI的这个分析平台我们也会把这个我们专业团队，降低开发成本,就开发的这个智能门槛,把我们一些运维的同学,全部能够引入到这个工具建设的一个生态体系当中来,这块就在这个分析这一层，其实属于一个共建共创的模式。

最后，数据驱动，推广这个就是监控去调动我们的自动化平台，能够做的一些，相对来说复杂一点的故障治愈场景，因为我们现在治愈最简单的重启，包括文件清理，那这些都是全部跟监控联动的，就发现了我们就会去处理，那更多的，有可能是高阶一些或者是：比如说处置难度和判定的这个因素复杂一些的，我们还没有上自动，现在这个，肯定就是基于我们前面的排障，准确性的过程，排障越来越准确后，我们可以把逐步的把自动恢复的一个动作加进来。

我负责的这个团队会做的一些准备工作的一个课题，第一个就是我们在新的这种K8S，这个用容器体系下面去做的故障分析，它是和我们现在点对点，这个IP级的这个故障分析还是有一定差别的。

第二块就是我们会结合数字完成时和监控数据的一个整合，实现一个线上的体验感比较强的巡检，以及监控的可视化体系。

第三个就是我们持续就引入AI算法加持，我刚提到的预测和排障，最后一个就是混动工程，我们会把一些预案分析，放到一个可以模拟的场景来，这个主体的依赖能量还是我们监控数据肯定是一个最大的数据。

最后讲讲愿景，因为我个人比较喜欢摄影，这两张图，就是也是我全部是自己拍的，这个我是从2011年进太保的啊，就这张图是就等于是我们上Zabbix之前啊，吃饭吃到一半拉去干活了，后面一张呢，就是等于我们上了这个工具平台来维持、越来越完善之后，那我们这个就意境就不一样了，那我个人也是成功的从一个一线干活的，发展到一个看着别人干活的，那也是归功于我们Zabbix功不可没，对于我个人以及我们系统的公司系统运维平台的一个建设都起到了至关重要的作用。