案例分享 | 苏宁如何建设智能监控报警中心？

本文整理自尚海在2020Zabbix中国峰会的演讲，更多演讲视频可关注官方Bilibili账号主页（ID：Zabbix中国）。

  一、 苏宁立体化监控体系  

我今天分享的主题是苏宁智能监控报警中心，主要包括4个部分，苏宁立体化监控体系，Zabbix大规模监控实践，监控告警自动化，智能报警中心建设。

第一部分苏宁立体化监控体系，先介绍背景。第一个就是业务广泛性，在苏宁整个体系下面有易购，线上线下置业、金融、家乐福、视频、体育、直播、物流等等，只要有苏宁服务的地方就要有监控。第二个是监控范围的复杂性，在苏宁的系统多机房部署，也是一个多云部署，多活架构。无论监控的范围有多复杂，都是要做到全面监控的。第三个，系统和服务的复杂性，在苏宁系统多、调用关系也比较复杂，正是因为系统多、调用关系复杂，更需要能够去更好的做到端到端的监控。第四个，监控告警的诉求，告警要做到全、快、精准以及智能化和可视化。

对背景做一下总结，监控范围越来越广，越来越复杂，监控能力是越来越高，越来越智能。监控的使用体验要求越来越好。因为目前监控平台在苏宁内部的用户现在大概是1万多人，那么不同的层级的用户其实对体验各方面的要求也是不一样的。因此基于上述背景，我们提出构建立体化监控和智能报警中心，所谓立体化监控，首先它是一个体系，不是监控工具，也不是几个监控工具，也不是几个监控系统，它是一个完整的全面的一个体系化的监控。其次在立体化监控里面的话，它是有点、线、面的一个有机结合的监控。第五个是在立体化监控里面是要能够做到交叉监控，智能报警中心就是管理和治理智能化和可视化。那要构建立体化的监控也好或者说是构建某一个垂直领域的监控工具，或者监控系统。

总结有几个关键点，第一个容量和性能，第二个告警，第三个数据容量和性能。无论是去构建什么样的监控，容量要够大，要能够承载监控范围的量。比如说我们现在在苏宁易购体体系下面，整个目前监控服务器的话现在大概几十万台，那么我们怎么能够做到这样一个容量，能够承载这么多服务器的监控，包括网络设备，包括其它的指标监控。

正是因为量大，更要确保监控的全面性和完整性，监控一个都不能少，一个都不能错。最后一个就是监控就是容量够大之后还要能够做到高可用以及可扩展的。第二个就是告警，有了监控之后告警。第一个其实要做到怎么能够做到告警的实施，在实施的基础上去做到秒级的告警实施，精准的告警以及告警的关联分析。第三个就是数据，无论构建什么样的监控体系，那么数据怎么能够做到数据可视化，数据的一些分析以及最大化程度的挖掘监控数据的一个价值和输出。那么围绕着这容量和性能告警数据这三个关键点去构建立体化监控体系和智能报警中心。

我们怎么去构建的呢？无论是Zabbix监控Prometheus监控以及其它层面的监控，那么如果说要从建设路径上来说的话，主要就包括5个，怎么采集？怎么存储？怎么计算？怎么分析？怎么可视化？采集采集的话也要根据采集对象的不同来选择对应的采集方式。比如说日志的采集，可能会用到flume，那么一些网络设备服务器的采集会用到Zabbix会用到prometheus，那么调用链的相关的数据采集，可能要用到一些调用链的探针等等其它的一些方式，就是根据采集对象的不同选择对应的采集方式。那么对采集的还有一个要求，就是要能够做到秒级采集，以及对采集方式的一个个性化可定制的这么功能。 

采集完之后，第二个就是存储，根据采集对象的不同，那么也要去选择对应的不同的存储，比如说持续存储、日志存储图存储以及metric存储，比如说我们通过监控采集的一些拓扑数据关系数据，包括网络拓扑，IP拓扑、DU拓扑、系统拓扑，那么是要存在图数据库里面的。因为你如果说存在关系型数据库的话，你会发现你如果要用到这个数据，你要对Mysql比如说这种数据要有大量的这种校验操作，其实性能肯定是支撑不了的。同样日志可能要用到 elastic search测试去做存储，包括等等其它的总是要选择对应的一些存储计算。

有了采集有了存储之后怎么去做计算？比如说用了Zabbix其实是有一定的数据计算能力的，包括Prometheus也有，包括自己自研的一些引擎方面的计算，包括等等其它的，那么同样也要根据前面的采集的指标，存储的方式去选择对应的计算。那么计算要达到的就是既有事实计算也有离线计算，包括计算的过程当中要引入一些算法。那么有了计算之后去做分析，分析主要是有一些聚合方面的，收敛分析方面的，根因定位方面的。最后无论是告警也好，监控也好，要都能够做到可视化。

这是苏宁当前的一个立体化监控体系的概览，从这张图的最下面能够看到，其实就是监控范围，苏宁的整个业务体系都是要在整个监控体系覆盖之下的。那么在这张图的最上面，也是立体化监控体系的四大组成部分。第一个是配置中心，第二个是可视化平台，第三个是智能报警中心，第四个是监控开放平台。

最下面是苏宁智能报警中心，在苏宁智能报警中心下面就是构建了很多垂直领域的一些监控工具，比如说基础的监控，Zabbix监控，Prometheus监控以及机房动环的监控，CDN的监控，以及日志的监控，调用链的日志，还有一些实时日志的监控，包括波测、端测、组件、业务等等，这也是刚才讲到的立体化监控里面的一部分。因为只要有需要做到监控的都有，比如说苏宁易购的APP，那么要能够做到一些端侧的监控，移动端的、PC端的，以及要能够做到主动的波测监控等等组成整体的一个立体化监控体系。那么无论是哪个层面的监控，它都是有报警的，都是由苏宁智能报警中心统一去承接，统一去做管理。

在上层就是可视化，因为智能报警中心其实也要做可视化的，包括监控的其它的数据一些可视化。那么有了这些之后做可视化，比如说监控大屏，每次双11大促、818大促的时候会有一些监控大屏，包括链路大盘，比如说支付链路、浏览链路、直播链路等等。具体的链路大盘结合其它的数据去做这种大盘监控，以及拓扑监控，网络等等的这些拓扑监控，一些融合分析监控视图，这些做到一些可视化监控。

在整个立体化监控体系里面，还有一个很重要的部分就是自我监控，因为监控是给别人提供监控服务的，自我监控也要能够做的更好。因为监控的服务有了异常之后，也要能够第一时间去发现，不然的话如果说监控服务有异常了之后，大家也收不到告警，也不知道是监控有问题，还是说没有报警。所以说针对自我监控。

第一个要做到自我监控的指标要够全。第一个就是数据采集的监控，要能够监控到你整个监控，比如说几十万台服务器的监控，这几十万台服务器的数据，每一个item的数据是不是都能够做到实时的采集？有没有采集失败的？有没有采集延时的，都要能够做到监控。

第二个就是告警服务的监控，在整个监控体系里面告警服务有没有异常，告警会不会有延时，会不会有积压，以及整体的服务有没有异常，也要能够做到第一时间发现。

第三个是访问服务的监控，因为这个就是说监控平台你访提供的一些访问服务有没有异常，比如说包括AP I等等，也要能够做到监控。

第四个也是很重要的一个监控，就是自动化监控。因为目前在苏宁的话，整个监控告警体系里面的话，所有的监控配置告警配置就是无人值守的，没有任何一个人去做任何的配置，全部都是自动化去做的。那么自动化实现过程的监控，比如说这个的话其实就要也要能够做到监控。

第五个就是集群服务的监控，每一个监控集群的服务有没有异常，有没有告警，集群级别的监控也要能够做到。因为涉及到高可用切换。

第六个，有了这么多的自我监控指标之外，那么如何做到自我监控的一个监控，因为监控是做监控服务的，按照普通的监控方式去做监控，肯定不行。如果监控出了问题之后，这些指标的告警也会发不出来。所以说我们提出是做交叉监控，就是说监控体系的监自我监控和监控体系的监控服务是做到交叉监控的，以及做一些监控体系的健康管理。

  二、 Zabbix大规模监控实践  

就是 Zabbix的大规模监控实践，首先从我们用的建构范围上来看的话，因为苏宁用的Zabbix是从2014年开始去用的，现在也用了整整6年。当时用的话服务器也是从几千台到几万台以及到现在的几十万台。从监控范围上来说，目前我们覆盖的监控的话，有网络的监控、服务器的、操作系统、中间件、数据库、应用系统。

网络的话，目前我们在苏宁的虚拟网络这一层也用Zabbix做了一定的监控，比如说一个是在网络虚拟化层，以及物理设备，路由交换防火墙这种设备，包括线路，包括CDN。第二个就是服务器，服务器的话就是包括物理服务器、一些云服务器等等，也包括一些硬件指标，比如说物理服务器的硬盘状态，网卡状态，电源状态等等，以及其它层面的一些指标操作系统。

目前苏宁在用的操作系统也都在监控体系下面，中间件就是在用的中间件，包括苏宁自研的一些中间件，还有数据库以及应用系统。这个应用系统的话，目前我们也加了一些应用系统的 UR减活的监控和健康指标的监控，因为通过这几个监控指标才能够做到底层基础设施和上层应用的一些关联，包括后面的做智能报警，做分析等等才能去做有效的关联，做有效的聚合。这个是监控范围。

从14年我们开始去用Zabbix用到现在的话大概6年的时间，我们在用Zabbix的过程当中遇到了哪些问题？总结下来的话，我们主要有这4大方面的挑战。

第一个容量。单一Zabbix server的容量它是有限的，那么在实际的业务需求下面，又有40万台服务器需要做监控，我们怎么去做支撑？因此我们是怎么实现的？就是分布式监控集群，统一的配置管理，可视化中心。

第二个告警。其实在用Zabbix的过程当中，你如果说有的时候瞬间告警产生量比较大的话，Zabbix alert的进程，进程增长100%，告警发生会有延时。那么以及Zabbix直接原生产生的告警，有关联性质的，复性的告警还是比较多的。那么回到实际的需求环境里面，又要能够做到告警快和精准，怎么去做解决？所以说我们是通过智能报警中心去做的。后面今天也会讲到的智能报警中心。

第三个数据。在监控数据方面，因为在Zabbix监控项比较过多的话，有的时候会出现数据延时，比如说发现有些服务器的数据它是有延时的，因为在现在苏宁的整个zabbix监控体系下的item，现在大概是5000多万个item指标。但是数据延时的问题要解决以及这么多的数据，我们要能够做到实时分析，做完实时分析的时候，也要能够做到最大化的去利用。我们现在是在Zabbix proxy这一层，做的是通过数据复制去做的，这个是数据复制，而不是数据转发。后面也会再介绍一下为什么叫数据复制，而不是叫数据转发以及做持续存储。

第四个就是规则。因为Zabbix是有模板的，通过模板可以去快速的去上线监控的配置告警的配置。但在量比较大的情况下，那么个性化的监控规则它是比较多的，阈值化的也是比较多样化的，比如说我这些服务器，我白天是一个监控规则，我晚上是一个监控规则，我大促期间是一个监控者，我非大促期间又是一个监控规则，那么这些阈值多样化个性化的监控规则，那么在Zabbix的模板的话，其实也是无法满足的，以及做告警的时候，不只是单一规则的告警，是需要做到一些关联规则的告警的。那么我们就是通过规则配置中心，我们自己研发的个性化规则的自动化启程去做实现的。

这个是我们目前用Zabbix的一个部署架构，通过这张图的话其实有几大部分，第一个就是告警中心、配置中心，Zabbix server集群proxy 以及数据复制。首先我们也是从一个Zabbix server到多个Zabbix server以及到现在的多Zabbix Server集群。现在Server集群的概念，因为Server集群的概念的话，就是说首先用的架构的话是server proxy的架构，那么在不是Zabbix集群里面的话，它是有一个server的有多个proxy，但它在集群里面不只是有server、proxy，它还有其它的一些东西，因为它有和配置中心去做交互的东西，我们配置中心不是配置管理中心，是配置管控中心。管控和管理的区别就是不只是管理还有控制，因为在时限的时候控制比管理更重要。

多地方部署多个集群，目前的话因为在苏宁有很多个数据中心，包括也分布在多个城市，包括还有一些线上线下的，我现在集群的话大概也有几十所有的监控机群。刚才也讲了，都是由配置中心去做统一管理和统一管控的。也就是说配置管控中心，它要能够去判定什么样的服务器，在什么样的监控集群，它要有什么样的监控配置，要有什么样的告警配置，它以及后续的自动化要怎么去做处理，怎么去做对接？都是由管控中心去做的。因为之前我们一开始是按照管理中心的这种方式去做的，后来我们也把它做了升级，现在升级成是管控中心。相当于是其实有一些Zabbix Server之间做了一些控制管理方面的东西，我们把它上调到配置中心，去做一些管控的。

有了这个之后，所有的报警都是由报警中心去做的，有多server多集群解决了容量的问题，确实还是可以通过加server去做平行扩展，加容量，但是也带来一些新的问题。多zabbix server是多个数据库的存储，数据太分散了，那么数据分散也会有带来一些新的问题，其实用起来不方便，看起来也不方便。虽然说有可视化中心，可以从用户使用的port层面做一定的程度整合，但是用户看到的它只是一个port层面，但是在监控体系里面，底层还是要去很多要围绕着数据的工作要去做。所以说我们现在是不管是哪个server集群，把所有的proxy都是做了一层数据复制，把数据复制出来。这个数据复制和数据转发的区别就是,最一开始我们也是做的数据转发，比如说通过proxy的上面的本地的MySQL，去通过Binlog方式把数据解析出来，也改过proxy的data sink代码，相当于是 proxy去发给server的时候，在data sink 那里面加我们的代码执行逻辑，把数据发到比如说卡夫卡,发到我们想要存储的地方，这些其实之前我们也都尝试过，包括从数据库层做主层做读写去做这个解析。但是当量大的时候都会有问题。

所以说我们是后来通过数据复制的方案去做解决的，数据复制是怎么做的？正常情况下proxy它的config文件里面要配server IP,我们是把server IP把它改成了我们自己写的一个数据复制。我们内部叫handler IP,也就是说所有的proxy采集的数据都会发给我们自己的handler IP的程序，这个程序是干嘛的呢？之前我们也是把zabbix server和proxy所有交互的代码一行一行的都看了一遍，把Proxy所有采集的agent所有的报文之后，最底层的报文，我们全部都把它给拿到handler里面去，拿过来之后我什么也不干，我就转发给server。就相当于我们是做这个数据复制的目的是尽量不改zabbix server的代码，也保证一个数据的实时。

这样的话好处就是我们把数据能够复制出来，数据复制出来之后，也能够做到数据的统一存储。以这个数据我们现在是放到时序数据库里面存储的，目前我们用的是vm时序存储，这个的话因为也考虑到还有建中其它的一些数据储存，比如说我们也在用的prometheus，包括其它的都是用统一存储去做的。那么这个数据复制最核心的就是怎么能够把所有的proxy底层的报文原封不动的收过来，我在原封不动的发出去，proxy它是一个分布式的，但是在这个数据复制这一层，就相当于它要做一层汇聚，要去做发。其实当然了这个里面我们也用到了一些自己开发的一些技术，因为就不多讲了，因为也在做国家发明专利的一些申请。有了所有的数据做了一些统一存储之后，那么这个数据我们就做了一个数据开放平台，这个数据开放平台既开放给我们的智能监控报警中心应用，也会开放给苏宁的其它的平台去用，包括自动化平台，包括运维自动化平台，包括云管平台，以及包括苏宁的容量规划平台，所有的都是走数据开放平台统一去走数据的最大化分析和利用，zabbix的数据相当于其实无论是查看也好，还是从其它基本上都没用到，因为这也是为了保证数据的一个实时以及最大化的去利用。

我们其实也对zabbix做了一些精简。其实zabbix本身的功能确实很多，但是它有些内部的比如zabbix housekeeper其它一些机制，它是会影响性能的，是会影响到数据库的读写性能的。所以说我们把它该裁减的都裁减掉，所以说才能做到一个zabbix server集群，NVPS的话最高的目前大概能够有五六万，目前我们观察下来它其实还是可以去增加的，因为现在的话我们后面也会介绍，因为它这个是自动化加的，其实现在我们也是不去干预的，所以说比如说马上双11大促，其实也在每天我们去观察下来，其实也还在大量的服务去加。

  三、 监控报警自动化  

监控报警自动化。正是因为规模比较大，以及对监控的要求，一个不能少，一个也不能错，靠人肯定是不行的，所以说监控报警自动化。在苏宁监控和自动化它是必须的关系，没有自动化就没有监控。监控报警自动化，其实从监控报警背景上说的话，也刚才讲过了，就是数十万服务器的规模下，每天它都有大量的服务器上线、下线，以及每个服务器它还有一些变更的操作，比如说变更监控规则，报警规则这个监控变化是很频繁的，那么业务系统也很多，监控告警规则是多样化的，因为整个的业务系统现在大概是4000多个独立的系统，那么它每一个系统其实都是刚才也讲到了有家乐福的系统，有线上的系统、线下的系统、金融的系统、物流的系统，它的监控的方式规则都是不一样的。

从我们监控体系角度，因为我们都要去做支撑，都要去做实现。那就是传统的监控模板其实是难以满足监控的需要的。还有一个就是监控对象，它其实是存在一些常态化的扩容操作的，那么你个性化的规则把它给上去之后，你个性化的规则也要能够做到自动化的继承去实现。所以说综上背景我们自动化的一个目标，因为同样因为在苏宁我们去构建立体化也好，构建智能不监控报警中心也好，做自动化也好，都要先有目标，围绕这个目标去做架构设计。就像刚才讲到的建设路径关键点，一步一步往下去拆分、去分解、去做。我们这个的目标就是要做到监控实时、无人值守，它就是真的是无人值守，它不是一个假的，不需要任何人做任何操作，因为也没有这样的人去做这样的一个操作。

围绕着监控实时、无人值守，其实我们去做监控告警自动化的话，主要用到以下几点。

第一个就是自动注册。自动注册很关键，自动注册拿到注册信息之后，我怎么保证一个不能少，一个不能错，我首先要拿到注册信息，拿到注册信息之后，其实就相当于进入监控的整个管控体系之内，那么我才可以做后面的事。如果说都没有自动注册，你都没进来，其它的其实都还谈不上。所以说第一个自动注册机制很重要，确保所有的对象都能够第一时间纳入监控系统的一个纳管体系。

第二个是自动发现，自动发现我们有一些自己开发的自动发现规则，也有一些是zabbix自带的一些发现规则，那么自动发现也要比如说基于CMDB的一些监控对象数据做到自动发现。

第三个就是监控模板，我们也用到了Zabbix的一些模板，但是Zabbix的模板目前所有的模板都是我们自己定义自己开发的，没有用到原生的模板，原生的模板里面东西确实很多，确实也很好用。但是因为我们考虑到也和它的一些集成，因为有些用不到的，其实我们相当于就不用了。所以说才会做了一些根据监控对象的属性，能够自动匹配其对应的监控模板，但是监控模板和个性化的配置它其实又是有冲突的，因为模板它都是一样的，但是个性化配置它就都是个性化的。

第四个就是自动化配置，你有了自动注册，有了自动发现有了一些模板之后，你还要能够实现自动化的一个配置。

第五个，你自动化配置完之后，在监控整个过程当中，它就有一些自个性化的规则要做调整，那就要能够做到个性化的一个继承，包括全线的继承，包括一些规则的继承。如果说要做总结的话，就是监控系统，其实目前我们做的自动化的话就是基于配置中心配置、管控中心去做的，那么基于CMDP数据围绕的状态类型，相当于是实现监控对象生命周期的自动化管理，无人值守的同时确保监控全面性和完整性。

通过这张图也能够看到，其实我们主要就是三大块状态、继承和软件类型。通过状态其实做监控生命周期的管理，包括继承，包括其它的类型来确保什么样的监控对象，要有什么样的监控配置，要有什么样的告警配置，都是通过类型等等的CMDB这个去做的。

  四、 智能报警中心建设  

第4部分智能报警中心建设，刚才也讲到了，立体化监控体系的构成，以及我们怎么用的Zabbix，以及我们在用zabbix的过程当中，全部是自动化无人值守的。

最后一个智能报警中心建设，因为在监控体系里面，其实报警其实也是一个很重要的部分，在我们构建立体化监控体系和以及建设智能报警中心的过程当中，其实我们总结下来告警它不仅仅是告警，告警更重要的就是背后的含义，因为告警其实它只是一个简单的发了一条告警，以及告警它不仅仅是告警的一个发送，相反告警它仅仅是一个开始。

首先看一下智能监控报警中心的一个总览，也能够看到全生命周期的智能化管理，告警产生了之后，产生要收敛，收敛要分析，分析要发送，发送要到响应，响应要处理，处理要到关闭。也就是说通过我们是要做到告警的端到端的管理，在围绕着智能化管理的过程当中有一个很重要的维度，就是时间。每一个告警几点钟产生的，几点钟收敛的，收敛了多长时间，分析了多长时间，几点钟开始发送的，发送到用户看到是几点钟，几点钟响应的，几点钟处理的，几点钟关闭的，相当于是通过时间把做智能化全生命周期管理下来。

这个好处是，也是配合着右上角的告警治理去做的，因为通过这个时间，它是一个最客观的数据，大家都能看到。通过这个时间其实也逼着我们监控团队逐渐的去提升监控能力，包括研发中心，包括运维中心，其实它们看到告警，我这个告警你几点钟响应的，你有没有响应延迟，几点钟处理的，以及相关的这些东西，其实大家都是能够看到的。反而会提升大家的告警的主动性，大家都会去想办法去推动告警的治理。这也是在整个智能报警中心里面，除了中间的生命周期智能化管理之外，最右上角的告警治理也很重要，告警治理比告警管理更重要，因为在管理的基础上你还要去做治理，因为通过治理你会发现很多的优化点，这样的个性化的监控规则，这种需求就有了，要逐步的去调，因为要做告警治理，虽然说只有了管理之后，比如说一个团队它每天产生告警，它响应也都很及时，处理也很及时，关闭也很及时，从数据层面看它做的很好，但它每天响应处理告警的时候，它都是一些重复的告警。比如说磁盘空间它每天都都会有告警，那就说明它可能是业务打日可能是不合理的，但每天都打，但它每天都处理，那么就要通过告警治理的手段，通过去做分析，然后把这些再去转化成有一些对监控能力的要求，再去做监控能力，有一些做其它的需求就是做调整。

最核心的就是中间这一个告警的全生命周期智能化管理，在这个里面除了管理之外，对于我们来说还有一个比较重要的就是告警链路，因为我们要做到告警的快，要做到告警的精准，那就要围绕着我们整个的告警链路大量的做工作。因为我们现在做告警链路的优化，告警的时间，我们现在基本上真的一秒一秒的往下去降。比如说我们要能够确保告警产生的时候，到用户触达的时间尽可能的短，但是告警产生了之后到触达给用户，其实是中间是有很多过程的，因为要考虑到精准。所以说全生命周期的智能化管理，就是刚才讲的管理是很重要的一步。

第二个就是告警链路，因为告警链路是我们特别关注，也是我们特别要去解决的。从功能上看，其实主要有这么几大块功能，首先就是告警发送，告警发送是比较简单的，什么样的告警通过什么样的方式发给什么样的人就去发了，这是最简单的发送。还有一个告警分发，告警分发主要是面向苏宁体系里面7×24小时监控团队的，苏宁7×24小时监控团队，它有分很多团队，因为无论是易购的各种业务，还有金融的它都是要7×24小时值守的，有数据库的团队，一线的团队、RDC的团队，网络的团队以及中间件的团队，那么我们都是通过告警分发去做的。

告警分发是什么意思？告警分发就是有一定的分发规则。我们是报警中心，这有这么多告警之后，会基于分发规则分配给对应的人。其实核心的就是实现就是说你想看到的告警，我都给你看到，你不想看到的告警我一个都不给你看到，所以说都通过告警分发去做的。比如说数据库告警，我就把你关注的所有的数据库类型的告警都推送给你，包括易购旗下的，包括金融的物流的等等其它的，只要你看到的都会推送给你。因为这个分发规则其实也比较复杂，它也不只是通过监控类型去做区分的，比如说无论是数据库服务器，还是中间件服务器，还是其它的各种服务器，它底层的比如说应硬盘坏了，或者说是其它的状态有问题的这些告警，其实都是要给对应的团队的。RDC团队，这又就相当于分发规则，其实多维度的，那么做到分发规则告警分发之后就有一个告警响应，所有的告警分发给对应的团队之后，它第一时间去做响应，因为苏宁对这个是有考核的，所有的响应时间的考核，要确保所有的告警都能够第一时间去做响应。所以说告警分发和高级响应其实是关联起来去用的，因为在管理的过程当中，刚才也讲到了，每一个时间我们都会把它记下来，你这个时间大家都能看到。

第三个就是告警屏蔽，因为很多计划内的操作你要做报警屏蔽，因为这样的话才能避免无效的这种告警去做产生。告警屏蔽上就有很多了。页面的自动化的频率以及接口，目前的话我们主要大多数去做的这种接口的屏蔽，目前我们智能报警中心的屏蔽接口已经和苏宁的其它所有的,只要能够操作到我们的监控对象的服务，我们都让它去接我们的屏蔽服务。因为这是它必须得接的，这是在我们整个治理管理体系之下，大家都是必须要去做的。这样的话才能够保障减少这种无效的告警。因为你明明都知道今天我要去做操作了，会产生告警，你肯定就不能让它产生告警。

第四个就是告警升级，无论是告警发送还是告警分发，我们都有一个升级机制，就相当于用户看到页面之后，只要它超过一定的时间没做响应，就会去给它做升级，去打电话给他的上级负责人。如果说一定的时间再没有，还会再打电话给他的上级负责人。当然升级机制是可以去动态去做调整的。

目前我们告诫升级主要是和苏宁的豆芽团队去合作的，因为在苏宁豆芽类似于而且钉钉，就是我们内部的交通工具，通过苏宁豆芽的语音的方式打电话，以及播报。

还有一个告警自愈，在智能报警中心的过程当中，因为告警确实一个是范围比较大，告警量比较多的话，我们也做到了一个告警自愈。告警治愈就是告警的自动化处理，我们告警治愈一部分是告警的自动化处理，还有一部分告警的自动化分析，比如说我产生告警了，可能我要去分析告警，我是需要收集一些其它的数据，要看其它的一些数据的，那么都通过这个模块我们去给它实现，以及告警收敛。告警收敛主要是要把有一些规则的告警能够给它收敛到，减少这种告警。还有一个就是最上刚才讲到的右上角的告警治理，因为告警治理其实也是很重要的，因为通过告警治理，其实通过一些治理报表，通过其它的手段才能够去推动大家整个体系，才能大家一块往前走。无论是告警的接收团队，还是告警的处理团队，还是我们监控的团队。因为这大家都是一样，都要去往前走，都要去做优化。因为这个时间，比如说我们现在从告警产生到用户触达看到，现在是30秒钟，我们可能就要想办法减少到20秒钟，或者是同样你响应处理也是一样的，大家都要去想办法去往前走。

这是整个智能报警中心的一个总览，总结一个是管理治理，还有一个告警链路。那么因为告警发送、告警分发就是相比较而言都是比较简单，直接就发了，所以说我介绍一下智能收敛。在我们智能报警中心里面的话，我们做的智能收敛的话，其实通过智能收敛，我们主要就是为了减少告警量，提升精准性，主要怎么去做的？

第一个就是时间相关性，还是时间，无论我们是做收敛还是做分析，第一就是要考虑的时间，考虑时间有两个维度，第一个就是时间相关性，你产生了这些告警，时间它必须得是相关的，比如说你超过5分钟或者超过几分钟，即使其它的规则在符合，我们认为它也不能去做收敛，时间跨度太大。

第二个时间就是我们要确保收敛和分析的时间足够短，因为刚才也看到收敛和分析是在我们整个告警链路其中的一个环节，我们要优化告警链路，我们要尽可能的短，我们要尽可能的快，那告警收敛时间就有一定的要求，目前我们做告警收敛，我们现在在整个告警收敛的时间，我们就是按照5秒到10秒的时间去做的，超过10秒钟我们就不收敛了。因为如果我们觉得为了收敛牺牲触达用户的时间，其实是不值得的。所以说我们怎么去做，第一个就是时间相关性，那么肯定是要以时间相关为准。

第二个就是链路相关性，所谓的链路相关性的话，比如说有拓普，网络连这个服务器服务器有物理服务器，物理服务器有虚拟网络，虚拟网络再到虚拟服务器，虚拟服务器上面跑的是什么系统，跑了什么这些等等。还有一个收敛规则，收敛规则的话其实就是可以收敛规则有一部分是静态的规则，比如基于CMDB的数据的静态规则，以及我们通过一些基于刚才讲到的监控数据的分析，我们自己推断出来的一些规则也都会放到收敛里面去。

最后一个静默告警，因为你去做收敛的时候，其实有一个很重要的因素，你就是要能够做到干扰判定，在大量的告警的时候都过来的时候，其实它是有很多干扰的，你要能够做到干扰告警的一个干扰的判定，不然你不知道哪些是干扰，哪些是是真的，其实也会影响一个收敛的时效性和精准度。

我画了一个图，大概示意了一下我们整个智能收敛分析怎么去做的。首先还是从这个图的最下面去看，所有的只要接入到智能监控报警中心的告警，大部分基本上我们都会走一遍分析的逻辑。但是有一个前提，只给收敛分析，只给它5秒到10秒的时间，超过这个时间，我们就不做了，因为还是要快。其实最底层最右边就是各个监控告警、网络的告警、服务器的告警、日志的告警、掉用量的告警，只要有的告警都接进来，接进来之后最左边最左边的话一个是CMDB。

还有一个图数据库里面主要存的是我们构建出来的拓扑，包括网络的拓扑，比如说交换机是怎么连的，以及交换机和服务器之间是怎么连的，服务器之间的云环境里面它又是怎么去做的？这是网络拓扑，还有一些IP拓扑，IP拓扑的话就是以IP的维度是能够把它给串起来的。第三个还有一些DU拓扑，所谓的DU拓扑，它就是调用链拓扑，哪个系统哪个服务，调用了哪个系统哪个服务，比如说 a系统通过sf要去调b系统等等。还有系统拓扑，系统拓扑是比较简单的，我这个系统里面比如说有web层、APP层、缓存层、DB层，这个其实是最简单的可以构建出来的。那么都是在图数据库里面CMDB以及我们也用到了一些zabbix，以及这些告警源，那么组成了我们整体的是制定数据分析的一个数据源，然后拿到之后就会去做分析。

其实做分析的话，最右边的分析，那么有各个收敛的规则要去做分析，首先是做时间的分析，做完时间分析之后才会再去做其它的，包括我们构建的一些因果模型，因果模型其实也很重要，因为因、果其实你构建出来之后，为什么要提前把它给构建出来？还是那句话？时间。减少时间，节省时间。比如说刚才也讲到了有UR探测检活的告警，如果说我发现一台服务器档期的告警，也有UR探测失败的告警，我认为UR探测的告警其实就是因为档期的这种告警引起的。以及端口的告警，以及其它的组件状态、进程的告警都是相当于因果模型，其实也很重要。因果模型的精准度，确保了告警售点的一个这种精准度。

当然因果模型其实里面的具体的一些模型，有一些是静态的是可以构建出来的，有一些是要通过一些这个算法和其它的监控的数据去做分析，去做趋势的分析，把它给总结下来的。然后有了这些分析之后，其实还有一些干扰判定的话，干扰判定其实刚才也讲了一下，就有一些它是有干扰的，要能够把它给剔除掉，然后去做分析。做完分析之后，至于上层的展示整合那就比较简单了，想怎么整就这么整。这些告警，你可以关联去拓扑去做整合，也可以关联链路，也可以关联大盘，也可以做单独的视图，都是可以的。而且通过还能做到一个影响范围分析，目前通过我们是可以做到一台网络设备故障了，那么这一台网络设备到底影响了多少台服务器，这些服务器是多少个系统的？都是什么服务？而且以及最关键的是这台网络设备影响了这么多服务器，到底真不真正的影响系统的服务，因为系统都是集群的，那么你这个网络设备如果说一个系统挂了10台服务器，可能也是不影响它的服务的，因为它集群还有其它的服务。但是通过这个都是要能够判断出来的。不然的话，你靠人去判断其实要花费大量的时间。

最左边这个的话是有了收敛，最左边最后其实就是主要偏向于分析，分析的话，当然了其实我们去做告警的话，除了我们刚才讲的因果模型，其实还用到了一些聚类算法，是因为聚类算法我们用下来其实感觉还是不错的一种算法，为什么呢？它简单。在我们做智能监控告警中心刚才也讲到了，其实就是整体上我们要求是要简单，一定要简单。如果说你这个算法在智能，如果不够简单，我们目前是不会去用的。还是那句话，时间。有了这个之后，其实包括我们做的可视化中心监控大屏以及实时拓扑，包括链路监控等等的，其实就可以做到去做展示。

收敛分析的架构就是围绕刚才的那张图收敛分析，如果说从架构的角度去看的话，首先就是最底层的数据源，其它的各种接收的各种事件，那么还有我们构建的各种拓扑，拓扑也很重要，因为通过拓扑你才能知道它的一些相关性。拓普你能构建出来，全部都是构建出来之后，还有我们构建的一些因果模型，以及包括事件的一些辅助信息。刚才也讲到了有一些事件的词库，类型库，干扰等等的，这些都是会用到的。

有了这些数据源之后，那么在中间会有一些配置的过程，构建的过程，然后去做分析。同样架构还是那句话，简单还是要简单，因为还是时间的问题，你收敛因为量比较大，你还是要考虑时间，如果你时间比较长的话，所以说其实我们现在是苏宁有一些核心设备的核心指标是产生直接就可以触达给用户的，中间任何过程都不做，能减少5秒钟，减少1秒钟，有的时候也很关键。有些配置构建，做分析，上层的上面就是做一些UI层的这种展示，以及我们收敛完了结果放在这边之后，也会做一些开放。监控报警中心可视化

收敛分析过程，就是有了这个架构之后，这个过程怎么去做的，同样也是一样，有了这些数据之后，其实相当于如果说从过程来看的话，第一个其实就要做一些预处理，预处理完之后才去做构建，做完构件之后做管理，去做展示。具体的其实我这里面也里面也都写了一下，因为这个的话就相当于是上层的展示那都比较简单了，那句话还是要考虑时间。

每一个我们预处理的时间构建的时间，这个时间我们都是要把它详细的给记录下来的，因为这个还是要考虑到时间的问题。其实收敛分析过程刚才也讲到了，就是说有一些无论是因果模型还是有一些怎么能够有的时候你做告警的时候，怎么能够找到告警的传播链，有的时候大面积告警的时候，它告警是会传播的，它是会往下去传播的。那么怎么找到告警传播链？

其实我们现在做的话，第一个就是要构建图，要把这个图构建的够强大，够全。我们目前其实也做了一部分了，很多也已经进入了逐步的也去做投产了，包括一些智能知识图谱的建设也正在做。其实构建图要把图构建出来，构建图之后，因为每一个图里面它是由节点、有边，那么节点和边，因为你节点与节点之间是通过边相连的，那是把得分把它给计算下来，当然了这个里面具体就不看了，它其实指数做这种计算。

其实都是怎么去大概就是说核心就是构建图节点和边，围绕这几个去做计算去做分析，然后能够达到得分，然后去做判断，然后有了之后，因为线上是有大量的数据的，把大量的数据拿下来之后，其实你是可以去验证这个这个算出来的是准不准的，以及有没有优化空间。

对智能监控报警中心做一个总结，那就是智能报警中心实现告警的全生命周期的闭环管理，确保告警及时响应，及时处理，及时关闭。告警全快精准的基础上，通过智能化的分析提升告警的处理效率，快速定位问题。如果说用几个关键词总结一下我们做的智能报警中心的话，全自动、精准快、闭环、智能。

第一个全自动其实刚才也解释了，全自动就是无人值守的，它就是一个全部都是自动化的，以及无论是监控的配置，告警的配置，权限的配置，就是说在告警产生之前，所有的配置都是无人值守的。这样的话才能确保时间精力才能做到刚才也讲了告警只是一个开始，才能做后面的这些事情。

第二个就是精准快，精准快和快的区别就是我们加了个精准，因为之前我们也做过精准，但是精准也离不开快，如果说你确实很精准，但是时间不够及时的话也是有问题的。所以说我们正在做精准快，包括告警链路优化，提升告警的一个触达实效。

第三个闭环，我们看的是其实从用户的角度，它不关心我们有没有做收敛，也有没有人做分析，它就看我们从告警产生，它几点钟能看到，是10秒钟能看到还是30秒能看到，其实现在对我们也是有一定的要求的，我们也是逐步围绕着告警链路，就像刚才那张图，做了大量的工作再去做从底层的技术实现，怎么去做分析，怎么做计算，怎么去各方面，其实我们也做大量工作，包括现在还是继续在做优化，还有一些核心指标快速作答。

核心指标快速触达的话，相当于是从另一个层面保证核心设备、核心指标，比如说机房各种维度的指标能够快速触达到用户闭环。闭环的话就是说所有的告警进了告警中心之后，它必须是一个闭环的，所有的告警继续围绕着怎么响应怎么关闭它是要能做的，以及在闭环里面其实是有一个告警管理机制的，只要接到报警中心里面的管理都可以复用这种管理体系、治理体系。

最后一个就是智能，包括告警的智能收敛根因分析，以及我们正在做的。因为告警它毕竟是一个被动性的，它已经产生了告警，我们再去做分析，再去做处理。我们现在是也就想再往前走一步，也就是我们现在正在做的预警和推理，相当于是我们现在不想说是收到告警再去做处理。那么我们想做的是，我们要知道它什么时候会产生告警，提前把它处理掉，这也是我们正在去做的。

好，我今天的分享就到这里，希望今天的分享也能够给大家带去一些思考，一些收获，一些启发。感谢大家。