关于AIOps建设的实现方法，擎创科技提出来了三大原则和六步走路线（参考上篇推送文章智能运维建设怎么做？按照：三大原则六步走，准没错！），许多读者可能会问到，AIOps建设这盘大棋究竟为何六步走的第一步要落子于集中监控的改造？集中监控智能化的改造都需要考虑哪些方面，收益在哪里？如何通过集中监控的改造进一步的展开智能运维相关场景的建设？这里面的逻辑和衔接关系是怎样的？
带着这些问题，我们来谈一谈AIOps智能运维如何为集中监控这项传统运维领域最重要的手段（没有之一）添加智慧的引擎。
一、传统集中监控之殇
如下图所示，运维体系中最重要的使命是及时发现问题，这在任何企业组织中都是不言而喻的。正是因为如此，企业才会在经年累月中布局了诸多监控手段，有些是商业化的工具，有些是运维人员为了获取被管理对象的状态写的形形色色的脚本，但总体都是为了及时发现问题。
但是，当业务运行出现问题时，往往有许多监控工具都会产生多样化的事件（或者俗称告警），这些事件分散在各自不同的监控工具或者由脚本采集或者触发，没有一个统一的视角进行一站式的管理，这就是构建集中监控（或称统一监控）平台的主要动因。当然，集中监控还可以根据运维需要将事件分配给不同的运维人员进行处理，提高分工管理效率。
集中监控固然是视野够宽广，但随之而来的是另外一些问题，原始的事件里有许多重复性的、杂乱的噪音信息，而且某一个组件发生问题，往往会引发相关的组件都产生报警，这样在短时间内就会产生告警风暴，这也会严重影响运维人员的判断，因此传统的集中监控，都是依赖运维人员的经验梳理规则，并将事件归并、关联的规则运用于平台，实现告警抑制。
这种方式在传统运维领域已经有超过二十年历史，早在年，世界上第一家利用内存处理技术运行事件处理规则的产品NetcoolOmibus就在国内开始了业务，后来这家公司被IBM收购，至今还是IBM监控产品Tivoli的旗舰产品，国内也还有大量客户在使用。为什么要使用InmemoryDB技术，就是因为规则会越积累越多，而基于规则匹配去处理事件，需要很多计算资源，否则处理速度赶不上事件产生的速度，就会丢漏事件，这是监控的大忌。
后来，BMC、HP等公司都开始用这种技术做集中监控产品，近年来国内的诸多公司也纷纷跟进，集中监控用设定规则处理告警的方式已经成为惯例。唯一的不同在于，由于业务逐渐走向分布式架构，近年来告警的量级达到一种一般关系型数据库难以企及的架构后，有些公司采用分布式数据库来替代传统架构，但上层的应用逻辑仍然是基于规则匹配处理。从表面上看，集中监控的出现确实实现了以集中视角看到各类告警的需求，一线人员对于告警有了一站式处理平台，效率相对于分散的监控工具确实得到了提升。
运维的世界真的就此安宁了吗？并非如此。
众所周知，规则，是一种经验的总结。只有出现过，甚至反复出现的规律，才能被总结为规则。因此传统集中监控仍然存在一些无法根治的弊端：
1.经验规则是有局限性的
若运维人员缺乏足够的经验，就无法梳理出有效的规则；再者，运维人员往往对自己负责的局部领域有经验，但对于其他部分则是小白，业务应用的载体一定是复杂的多个组件构成，不同领域的经验兼具才能发现一些相关性规则，而这些相关性无法仅仅通过“集中”就能发现，所以规则只能解决一部分问题。
2.对于新发生的或者偶发的事件