阿里巴巴智能监控新场景的探索

摘要： 智能监控是智能运维的子领域，详细分析。

做者简介

王肇刚
阿里巴巴全球运行指挥中心高级技术专家

智能监控是智能运维的子领域，咱们说的监控，探讨的更可能是在监控策略，由于可能从数据采集、日志收集、包括计算等等产生数据，再设定一些判断的规则和策略，发送报警，这些都属于监控。

我和个人团队在阿里内部的分工是横向去看阿里巴巴业务指标的监控，咱们就以这个话题展开。

分享分为五个环节，从阿里巴巴不一样的业态，特别是新的业态带来的挑战讲起。对于咱们以前已有的基于机器学习算法这样一个算法工程架构，咱们作了哪些加强应对这些挑战。

咱们的监控也从单一指标监控延展到多个指标一块儿监控。监控完了以后，咱们可能要分析定位，这时系统又能帮运维工程师作什么，这是第四方面的话题。最后是对智能运维整个领域作一些展望。

1、新业态给业务监控带来的挑战

上图是阿里巴巴不一样的业态，有比较传统的电商业态，右上角是国际电商，蚂蚁金服还有阿里云。最近这段时间阿里在收购各类各样的公司，也是商业的布局，咱们会看到优酷、钉钉等等。

咱们团队在阿里巴巴内部是负责横向的业务指标监控，这个有什么差别？

技术层面也是经过日志的采集流程计算看一个指标下跌仍是上涨，区别在于只要业务发生了不可用或者发生问题，咱们但愿都可以发现，而不是说阿里巴巴自己的系统出问题了。

举个例子，若是阿里巴巴一点异常都没有，可是电信可能有问题，这个时候咱们但愿知道。

它是从对于业务数据量实时的监控。由于阿里巴巴自己的业态是很丰富的，有这么多的业态，咱们看到的数据也很丰富。

上边这个图，你们可能看到的这些 Logo，看到购物或云计算的一些业务，可是团队作智能运维算法的同窗，看到的就是右边这种奇形怪状的曲线。

咱们团队在阿里内部是横向团队，第一环节就是须要可以精确、及时的发现业务是否有异常。

为了达到这个目标，咱们引入了称之为智能基线的系统，这个系统能够在网上搜索到。

这个系统效果仍是不错的，可以在没有任何阈值或者规则输入的状况下，自觉作预测。同时有些业务发展比较迅速，咱们能够比较好地在历史的长期趋势和短时间的业务沟通之间，作出一个相对较优的折中。

业务变化以后，假设你之前配了阈值还要改，智能基线不须要改。阿里巴巴几千项业务指标，经过人工的检查验收以后的准确率是在80%以上，这个数字每周都不同。

而对比传统的工程师经过传统的静态分段阈值或者环比的方式，准确率可能只有 40% 左右。

你们可能也会看到特别对于业务量监控，可能 10 条报警里面，4 条真的以为有问题已经不容易了。

阿里有不少不一样的业态，因此一套系统解决全部问题仍是挺难的，由于不一样业态之间的差别仍是很是大，数量级、波动、周期均有差别，包括如今有新零售业务，它是把线上线下的业务结合起来，并且很是强调线下。

好比盒马鲜生有几百家门店，这是个商业的尝试，对于作运维监控的同窗也带来不少挑战。

好比淘宝和天猫的某些交易量在分钟级别是万或十万或更高的数量级，这个可能就是百或几百，波动的量级和原始量级在一个量级上，这个就比较难处理。

包括周期性，对于通常的在线服务，是7X24小时提供服务，天天什么时间流量最低？国内业务凌晨四点钟最低，这个会受门店的开关门影响，由于零售是有时间的。

咱们若是线上刷淘宝下单点一下就行，线下不同，一对一排队结帐。并且在量小的状况下，不少时候不能看单一指标，许多指标要一块儿看，因此就给咱们以前的算法提出很是大的挑战，咱们须要作新的算法演进。

你们可能会问为何整这么复杂的算法。配监控，配规则不就能够了吗？

实际上是能够的，但业务太复杂。做为一个横向团队，算法工程师可能只有三四人，七八我的要面对阿里巴巴集团成千上万的业务监控指标，不可能了解每一个指标的全部细节，这个时候是没有办法用人，咱们要用机器学习的方法去作。

2、加强版的时间序列异常检测实战

接下来说讲怎么用机器算法解决问题，这是一年半之前咱们采起的架构，咱们能从业界不少文章上看到相似的架构。

咱们但愿作一个基线拟合，这个曲线应该是什么样，咱们说异常这两个字就是异于日常。

咱们第一步想知道正常的曲线是什么样子，因此咱们作基线拟合，咱们用STL作这样的方法，咱们用比较传统的 N-sigma 作调整。这种架构其实能解决 60% 左右的问题，可是有些极端的状况解决不了，因此咱们就把架构作了演进。

咱们第二代的架构作数据预处理，而后又作了比较简单的滑动平均，数据有时候会缺点，无论是采集侧的一些不稳定因素，仍是计算一侧出现了问题，致使你但愿一分钟出一个数据点，可是最后尚未算出来。

这种状况应该从工程上解决，因此咱们会在算法层面作一些脑部的算法策略，就是即便缺了能补回来，可是不能长时间缺数据。

下面的逻辑就走了机器学习的思路，咱们对曲线作特征工程。咱们以前的基线拟合的这种预测只是咱们特征工程中一部分，对于重要的部分，咱们也会把一些统计特征编码进去，固然也会把一些时间特征编码进去。

由于咱们知道不少电商的业务是有按期促销的习惯，好比淘宝的交易量天天早晨十点必定会有阶峰，你们不知道在抢什么东西。

算法层面怎么解决？咱们把天天的这个时刻第几小时第几分钟，经过热度编码的方式作到里面去，就可让算法学到这个时间点这样一下多是正常的。

咱们后面采起了不一样类型的统计学的判断和作法，最后作成集成策略，你们能够理解为简单的投票策略。

它其实给咱们带来了比较好的一些算法的效果，好比说基线拟合会更准，对于不一样类型的异常进行断定。不少时候曲线有不同的异常，若是用 N-sigma 的方式，你的刻画表现能力是不够的。

即便是这样，对于遇到的新零售业态，咱们以为仍是不够。由于你看刚才的算法能解决通常性的问题，可是对于曲线问题差别很大的时候，以前的预处理就须要加强，量级从十万左右到几百万，你的预处理策略须要变化。不少曲线不具有周期性，或者周期性很是零乱。

好比咱们有一个业务比较奇怪，你们在淘宝上有没有充话费？这个是天、周、月三重周期，天的话基本没有问题，周的话工做日和周末是有差别的，月这个周期，由于大部分人是在月末报警了或者月初充。

最后一个线下的业务对这种异常很敏感，在这种状况下咱们用一套算法策略是解决不了不一样问题的，因此咱们作了第三次优化。咱们先引入了一层算法路由，但愿可以经过机器学习的方式，把不一样的曲线归到不一样的算法路由里面去，这样的话不一样的曲线走不一样的处理路径，那么效果会很好。

我举三个例子，比较周期性、非周期性、百分比的指标等等，这些不一样类型的指标方法都不同。在这些不一样的方法以后，咱们仍是以为算法也许解决不了全部的问题，由于算法对于大多数运维工程师来说，不见得那么方便去调参数，因此咱们也开放了三个参数，咱们会看它不一样的抑制时间、发布策略和敏感度。

分开来看，算法路由，这个工做的目的就是说让算法自动把数据分类，这一块也不必定非得用算法，用人就能够，可是由于量太大，因此人工的成本很高。

这里咱们用了深度学习的算法，上面那个图是网络的图，咱们使用了孪生网络，两边都是LSTM，因此咱们用了双向的网络结构去把咱们标记为同样和不同的，最终可以区分开。

在这个基础上，咱们作了一个分类模型。这块从技术层面来说，不用特别复杂的算法，咱们用这个算法就是想探索一下，实际你们真正作的好的话，好比你用通常的分类方法，用咱们最直接方法也能够达到相似的效果，可是咱们这里尝试了一下。

分好以后有个工程架构，之前是说不一样的算法场景走的处理逻辑都是同样的，里面的参数能够不同，后面不一样的处理逻辑像插件同样能够去作组合，这个组合的变化频度不会太快，可是通常变化成本都很低。

这样之前是三条通路，我把插件的参数和顺序和有没有插件作一个变化。有了这个以后，对于阿里巴巴成千上万条，但都是到万这个级别，不会再多。

你们会想这个东西多是从业务角度监控的，从惯性思惟来看，咱们可能会是想监控 CPU 或者某个接口调用的超时，这些也是能够的。

咱们也探索了在系统级指标或者非应用级指标作这个尝试。它的周期性不太明显，第二个这个指标的变化跟业务行为关系不那么大，运维的决策对它的曲线影响大于业务的影响。最后一个就是标准不统一，你以为这个可能须要报警，别人可能以为不须要报警。

咱们采起了一种轻量级的方式去作检测，能够作到自动学习。

它跟上面那套算法相比在于它比较轻，能够作成一个包的形式，嵌到监控系统中去作监测。它的效果如上图右边显示，咱们内存中有奇形怪状的异常，这个算法逻辑仍是比较简单的，不用太在乎算法自己的框架，由于这些算法你能够替换成其余的算法，但可能须要考虑在数据进来以前作比较好的预处理。

第二个可能你须要基于统计特征和那些曲线自己的特征，影响你的特征工程。最后孤立森林不是说基于用户的标注去作的，由于实际场景中咱们不可能像作人脸识别这样给咱们标注。

什么参数微调？第一个是说抑制报警的时间，这个很容易理解。第二个防抖动策略，这个也很容易理解，就跟过去 N 分钟有 N 条报警是同样的，因此咱们归纳成N/M。

最后一个是报警灵敏度。这个在咱们市场环境中测试的效果大于70%，如今这个数字可能稍微好一些。

最终怎么评价算法？仍是要看人标的。好比说咱们有十几位同窗评判，他们的标准也不统一。甚至一我的今天说这个点标的对，次日忘了再看一遍就说标的不对。

因此说以上是咱们介绍的关于单个指标，无论是系统级的仍是业务级的指标，怎么经过机器学习的方法，作不用任何监控阈值配置和维护成本的智能监控。

3、多指标关联分析的探索

刚才也提到了在新业态下，不少时候咱们只看一个指标是没有办法断定业务有没有异常，或者咱们发现指标和指标之间是有关联的，这个在实践当中也会遇到。有时候两个指标都出了问题，这时这个信息能不能被利用，咱们也作了探索。

这个东西有一个业务背景，就是咱们刚才提到的看一个指标不够，咱们常常在一些业态里看到会监控某一个业务的成功量、成功率、失败的错误请求数几个指标相关变化。

有时候会发现指标有异常传播，这个传播有几种方向传播。好比说在不一样的业务之间传播，好比由于两个程序之间有关联关系，A坏了B也影响了。

还有就是混合部署的状况，同一个集群布两个业务，A被打爆，B也被压死了，也有这样的状况。

咱们怎么作这个事情？分为两步。第一步咱们但愿发现和维护相关的指标，就是哪些指标应该有关联的，发现以后要维护。一旦咱们掌握这个信息以后就能够作两个事情。

第一种咱们可以把这些相关指标放在一块儿断定业务是否是异常，而不是只看一个指标。

第二种咱们单指标能看的很准，但这时候我想知道为何会下跌，虽然给不出因果，可是能够给出相关。

业务指标之间的相关性其实有不一样的类型，好比上下游之间有监控项，好比咱们在阿里作过一个实际状况，你们看淘宝搜商品，若是出现异常你们就搜不了东西，咱们的淘宝详情页的浏览量和下单量都会降低。不是说搜索的程序或者应用服务掉了那个服务，它们之间没有关联，可是不少用户习惯了搜而买。一但搜挂了，不少用户不知道怎么买了。

因此这样的关联靠系统内部是拿不到的。包括业务不一样份量的监控，好比河南省播放成功率和河北省播放成功率之间的关联。

这种关联咱们怎么发现？必定是靠人工梳理，可是对于阿里的体量，一个是梳理不过来，第二个梳理之后过两天又变了。阿里集团可能天天的业务发布的频次是千级别的，那怎么办？还有第三种方式。

第一种利用 CMDB，咱们经过CMDB看到哪些应用之间可能相关。

第二个经过 时间序列相关性 发现了方法，这个跟刚才提到的卵生网络的方法是相似的。但从实际来看，通常是在第一个检测的基础上，再在局部作第二个，而不是全局的检测。

第三个咱们利用关联规则挖掘看哪些项常常关联报警。

咱们能够经过算法发现这些关系，这三个方案实际上是互补的方案。因此有了这三个方案后，就能够把不少相关的指标放在一块儿监控，方案取得了较好的效果。

在盒马鲜生，基于咱们上面作的新的算法，单指标架构和多指标关联架构，可以把监控发现率和误报量作很是好的提高，这就是咱们在新业态下经过单个指标的算法和多个指标的算法取得关联效果。

4、故障影响面和根因分析的探索

以前都是关于监控的部分，监控是为了发现问题，可是发现完了问题，不少时候是须要想怎么可以解决问题的。咱们在故障根因的推荐层面作过一些探索，但这个也只能是探索，供你们参考借鉴。

首先咱们看一下故障缘由分析问题的范围和边界，我也跟不少工程师交流过，凡是作运维系统的工程师都有一个梦想，就是我想作一套系统，一旦个人业务出问题，告诉我问题缘由在哪，这个很是理想化。

但在实际过程当中，这个事情是很是难解决的，探索来讲在阿里内部也解决地很差。虽然解决的很差，咱们也作了一些探索。

为了不咱们作的事情不符合咱们老板或者客户的预期，咱们须要先把能作什么说清楚。咱们很难作到淘宝交易量下跌了，我告诉你哪一个代码有bug，这个作不到，可是咱们能作到缩小影响范围。

这个为何有价值？由于阿里巴巴有两到三万名工程师，半夜两点出了问题，我打电话叫起来就是一个很是复杂的技术问题。

首先要从阿里巴巴几万个应用程序里，先要看这个业务故障到底跟哪几个应用相关，这个都是很是典型的问题。

咱们的目标是可以从站点、产品线和业务功能指标出现问题的时候，可以定位到应用服务层，包括数据库这层。这个架构就是可以锁定这个范围，而后以后的事情可能须要更细致的方式解决。

另一个好处，咱们能够对故障作一个结构化的快照，除了阿里巴巴，我看到不少公司也会对故障作复盘作改进措施，可是没有造成很好的流程。

可是在阿里我看到过去大大小小很是严谨的复盘和故障记录，包括很是多的细分的环节和字段，这个很是好，由于之后的故障能够从中学些东西。可是有个遗憾，这些东西全是用汉语写成的，长篇大论几千字。

人能够去读，可是好比阿里有另一个工做叫全链度压测，咱们要对去年的业务优先进行测试，这个时候咱们要挖掘到底哪些有问题。挖不出来，为何？都是汉字写的。

汉字写的话，它的表述、格式，都是很难被机器理解的。若是作的这件事情之后出故障，咱们尽量地把故障作一个结构，这个不只对此次故障的自己，对之后故障的防范都有很是大的价值。

怎么作？如上图所示，咱们会有一个主的抽象流程，当咱们的前面算法发现问题以后，咱们会尝试找到跟这个业务指标相关的应用和它的中间件以及数据库，以及相关的网络服务器IDC。

咱们创建了一个囊括阿里主流的全部运维相关事件的这样一个数据仓库，阿里内部可能有本身的这种事件存储的机制。

这个数据仓库可以告诉咱们在哪些运维的对象上发生了什么事情，最后咱们对这个事情作一个排序和筛选，把可疑的挑出来。逻辑仍是比较清晰的，可是真正作的时候发现有不少具体的环节须要考虑。

好比你怎么找到监控项关联应用，淘宝交易下跌了，你怎么知道是阿里的几万个应用中哪一个应用形成的问题？这个其实也是比较难的问题，咱们也没有解决太好，可是能够看到思路。

最直接来说，咱们经过监控系统自己的配置来获得。咱们的业务指标能画成一张趋势图，能作监控，由于背后有逻辑计算，有日志的采集等等。这些系统的工做，是由于加监控的同窗已经把监控怎么采集配置进去了。可是它有失效的时候，好比说两种状况。

一种发现业务环境很是强，ABC三个程序不断作处理，最后把结果打到第四个程序上去了。因此你经过这个，能获得第四个应用的名字，前三个应用其实跟这个业务很是相关，可是你从这里读不到，因此这是咱们要解决的。

第二个有一些应用自己是用来监控的，好比阿里的客户端，它会上报到某一些监控系统，这时候监控系统画出来的曲线，其实跟监控系统自己相关的，而不是跟产生监控数据的应用相关的。

这种状况下，这个方案就失效了。这个时候就须要经过人工配置的方式解决，目前是这两种方式结合在用。

刚才说的第一个问题，咱们也能够经过阿里巴巴的中间作的系统去解决这个问题，包括咱们也能够经过算法，对于报警作平台挖掘，能够挖掘出来像刚才搜索框下跌，致使交易量下跌的关系等等均可以挖掘出来，这个东西也是补充的方式。可是最核心的不是算法，最核心的是CMDB若是维护得好，比什么都好。

经过刚才那个思路，可以把咱们的业务指标跟应用结合起来，可是不少时候应用常常是无状态的，状态存储在数据库集群里面，这个时候仍是常常经过CMDB解决这个问题。

还有比较难的问题，就是网络跟应用程序的关系，有一个机房出问题了，常常咱们是混合部署的，因此这个时候问题实际上是一个很是散的关联，这个问题上咱们解决的也很差，因此咱们只能把这个信息当成一个缺乏的信息推荐出来，供你们去决策。

好比说无论阿里什么业务出了问题，咱们都会把网络最近出的一些异常点或者事情推送出来，提醒你们是否是这个问题，可是这块很难作到精细的管理。

咱们知道了哪些运维实体跟业务有关联以后，还要知道这些运维实体上、程序上、集群上、网络上发生了什么事情？那这个事情咱们怎么知道？咱们会创建一个在线的数据仓库，它可以不断地抓取来自于各个运维平台和系统中的不一样格式的事件。

这个抓取以后不是简单放一块存，还要创建关联索引。阿里有不少不一样的横向纵向的系统，他们的数据格式的字段都不同。

咱们尝试作一个翻译，在当中找到了两三个你们都能看懂的词。好比钉钉应用，这在阿里内部很是稳定的。第二个IP地址，这个也是很稳定的。

可是这两个以外，格式语言是不同的。咱们把数据仓库建好以后，输入开始时间、结束时间和应用列表三个关键词，就能够查到这段时间内实体发生了什么事情。我把事情都推荐出来是否是就解决了？还不够。

我给你们分享一个数字，在阿里巴巴内部，像这样的事情一分钟发生四千到六千次，也就是说一个故障若是持续了十分钟，就是几万个事件，因此咱们还要再作筛选。

这个时候就会经过一些方式作筛选，咱们会根据哪些运维实际上发生了报警，把这些实体的信息优先放在前面。怎么知道有跳变？咱们会对怀疑的对象作系统级指标的扫描，扫描出来跳变就排到前面去，因此有了这个以后就能够相对精确地缩小范围，当阿里巴巴淘宝天猫有异常的时候，我就能够知道。

咱们可以从上面看到，最上面这个环节是同一个时间内有多少业务的多少点在报警，红颜色的时候，可能就是某些业务出现短暂的异常了。

咱们会感受 CMDB 加平台化算法对报警压缩合并，看到了集中在优酷、集团客户体验、菜鸟这三个业务功能上。

这个其实就是刚才讲的多指标关联分析的做用，这时候我也不知道是否是由于它致使的，可是他们之间是相关的，这个能够帮助咱们定位。

最后咱们可以根据刚才说的逻辑，把跟这个事情相关的前五个或者前十个应用程序推荐给你。为何推荐给你？要么它发生了一些骤变，要么发生了一些大的业务操做。

不少时候可能百分之五六十的业务故障，都是发布新功能或者改配置改错致使的。作的比较好的地方，可能可以作到70%以上的推荐准确率。可是也有作的很差的，百分之三四十的准确率。

由于阿里业务很复杂，每一个环节每一个业务都有不同的方式。可是这个方法，我认为仍是一个值得推广和借鉴的大逻辑上的思路，这个就是咱们介绍的监控发现问题以后，咱们在根因分析层面有哪些探索和思考。

5、智能运维在故障治理领域的将来规划

最后但愿可以和你们一块儿探讨一下在智能运维领域如今与将来能够作什么事情。

运维本质上是解决在线服务运行中的质量、成本和效率三方面，运维不是从上到下的思路，包括我也参与了白皮书的工做，咱们也跟其余业界的同事探讨这个问题，不是说有一个顶层规划要怎么作，实际是在这些点所处的具体环节上，不少工程师开始尝试用算法的方式解决问题，逐步聚集成一个数。

咱们如今在上图左边那条路作了一些探索，已经在业务中用起来了。最先的探索，其实在阿里内部已经稳定运行了接近两年时间，也是效果在不断演化演进。

最近咱们也在探索右边这条路，就是无人值守相关的东西。出问题的时候不少人问淘宝的故障恢复了没有，支付宝有没有受影响。靠天然语言提出的问题，是否是能够经过机器人回答你，这个也是咱们探索的。

固然如今还不敢作全自动，仍是咱们列出来你再确认一下，但已经比你调出系统而后跟不少人沟通半天决策要方便一些。因此其实不只是在质量领域咱们作智能化的监控，智能化的根因分析，其实在节省人效率层面，也能够作一些探索。

中间这块跟成本相关，这块在阿里巴巴有不少团队作这样的事情，也能够经过智能化的调度可以作容量预测，优化包括硬件采购的周期，预测你服务器增加怎么样。或者在实施的时候，经过自动化的调度策略，节省服务器的资源。

因此其实智能运维这个概念，在今天已经不是个概念，它已经在咱们企业实际工做中，有很是多落地的点。但愿今天个人分享，能给你们有一些借鉴和参考，咱们一块儿建设智能运维美好的明天。

说明：以上内容为阿里高级技术专家王肇刚在 GOPS 2018 · 上海站的分享。

原文连接