日志易 AIOps 实践：日志数据大有用途

随着云计算和容器技术在改变我们当前的 IT 基础设施，产品和服务的正常运行更多地要依赖运维。然而大规模多场景的应用和越来越多的模块以及越来越复杂的架构给运维带来了极大的挑战，人工运维，甚至自动化运维已经无法满足频繁的故障需求。适逢人工智能技术的时代，机器学习能将我们从机械繁复地人工操作中解放出来，这不正是运维需要的吗？当人工智能遇上运维，AIOps 让运维人员看到了希望。

AIOps 的概念两年前才由 Gartner 提出，目前落地还比较少，大家还在探索中。但是可以预见，AIOps 必将是运维的下一个趋势。现在国内 AIOps 的采用如何？一些 AIOps 的探路者都有总结出了哪些经验？此次我们采访了日志易产品总监饶琛琳，来了解 AIOps 行业现状和基于日志数据的 AIOps 是怎么实践的。

如何理解 AIOps

AIOps 是在 DevOps 的基础上做的进一步的优化和提升。DevOps 要关注自动化，有监控规则。比如我们原先的监控系统有时候有二三十万个告警项，不可能给这么高频度的告警挨个看，这时候就需要 AI 来做这个事情。

对于运维来说，运维对 AI 的需求就是解决工作中最耗时的那部分。

运维工作中一个大的部分是监控，如何去完成一个高效的监控系统，需要对自己的系统了如指掌，把监控项分布在很细的地方，包括怎么设定阈值，这是很麻烦的事情，我们可以通过 AI 去完成这个事情。

另外一大块就是告警和故障定位。运维团队除了要解决当前的问题，也有长期目标，比如年度或者半年度的 KPI，保证网站或系统的性能。要优化性能点，可能要不断地猜测尝试，中间会有很大的时间成本。这种尝试过程就可以通过 AI 算法去提高优化，在尽量短的时间内达到原先要花很长时间的效果。所以 AI 对于运维团队来说，最大的目的就是在运维工作里去缩短时间，运维真正要做的事情还是那些事情。

AIOps 主要运用哪些 AI 技术

因为运维是在整个 IT 技术里面算比较新的领域，不像网络、安全等领域有一些大家公认的数据集。就算是在企业内部也不一定可以做好数据标注。所以 AIOps 面临的问题就是我们没有比较好的可以做监督学习的样本。

因此在做 AIOps 的过程中，不管是在监控指标领域，还是在日志分析领域，目前运用 AI 技术最简单的方式就是用到一些非监督学习的算法，比如聚类算法（Cluster analysis，亦称为群集分析，把相似的对象通过静态分类的方法分成不同的组别或者更多的子集（subset），这样让在同一个子集中的成员对象都有相似的一些属性，常见的包括在坐标系中更加短的空间距离等）。

现在的 AIOps 用法最常见的就是在排障过程中，怎么从海量日志里找到自己关心的点，比如有的客户采购了一些 PaaS 和 IaaS 平台的系统，这种系统都很复杂，每一个云系统里面可能都是好几十个不同的组件，每个组件之间各自有各自的日志输出。因为不同组件的格式完全不一样，我们把它采集到一起，对日志进行聚类模式学习的算法，进行快速排查，这时候需要看的信息量就非常小，定位问题的 MTTI 也很短。

另外一些地方会更进一步，把聚类和模式发现算法用到告警方面，去做告警的判断。比如有的日志类型之前从没见过，像对于外采的设备，我们知道正常情况下这种日志应该是不会出现的，所以只要这种日志输出，就证明当时一定有问题。这时候去关注信息优化，或者对这种极端情况做优化，这样运维人员就能提前预料到某一类这样的问题。

日志对运维工作的价值

日志对运维工作的价值主要体现在两个方面：

• 外采设备或系统的运维：有些用户的运维业务和系统里并不是所有的东西都是自己研发人员写的代码，会有很多外采的设备或系统，不是一有问题自己的研发就能搞定。对于常见的硬件设备，包括开源社区的一些中间件，日志是最能直接反应出当前运行状态的数据。在拿到日志的时候，常见一些关键字比如 warning, error，critical 等，可能很简单拿得到了，有些到了 info 级别，也能反应出比较少见或者我们平常不太留意的的情况，这样也可以发现很多潜在的问题；
• 排障：排障关注的不是每一个设备怎么样。在正常的运维系统中，我们最关心底层业务怎么样；但是在排障的时候，拿到一个总的告警是没有用的，要深入到底层，因为底层有很多不同的模块和系统。在排障过程中，单独排某一条线，作用不大，我们可以把不同平台的日志拿来做快速查询。但是如果对查询结果一个个去尝试，时间成本非常大，除非能把路径固定下来，有一些知识库告诉你出现这类问题就一定这么解决，这是少见的情况。另一个解决方案是，把数据搜集到一起，通过搜索引擎来过滤，快速拿到结果。再下一步通过 AI 算法，把这些结果总结分类成少数的几种模式，这样可能原来几千万行日志最后变成 20 几条结果，就可以节省很多时间。

日志易的统一管理平台

日志易作为一个日志管理平台，主要解决以下几个问题：

首先是怎么把各种来源的数据收集起来，同时做好格式化和结构化，因为不管是统计分析还是机器学习，只有结构化了的数据才能用。我们在采集端和结构化端这块有比较大的成本投入，提供了很多详细的解析方式。同时我们也内置了上百种常见的基础设施和中间件，包括一些通用业务系统的解析规则，部署上去之后就可以直接用，让接入的数据能尽快地去做统计分析和样本学习。

另外在做统计分析这块的时候，每一家的统计需求可能完全不一样，如果对每一个分析需求都写自己的分析程序，只要业务变更了，这个分析程序就失效了。对此我们做了一个接口层，叫做 SPL，Search Processing Language，它是一个类似 SQL 的东西，但是会像运维人员更熟悉的 shell 语法，可以把要现写的程序变成写 shell 命令一样。这样对每个不同的需求，可以就像写 Shell 脚本一样快速完成。

我们第一步先降低了采集数据和数据格式化的难度，第二步在统计分析时候，又简化了写程序的过程，这样我们整个这个平台就可以比较完整的形态，快速地完成事情，降低了各种成本。

日志易本身的定位就是通过采集日志信息，做结构化，然后通过算法做统计分析。

另外一个方面，我们理解的日志是一个广义的日志概念，有时间戳和一段内容。我们其实也可以把很多监控系统的数据对应到日志来，因为监控系统数据有一个时间戳，一个监控项的名称，再加上当前这个值，所以它其实也是一个有时间戳的内容。

很多时候我们会对接用户的监控系统，把他们监控系统里历史信息和监控指标也拿到我们平台来，这样就可以把我们的时序指标分析运用到这部分数据里。这样我们既接入了监控系统的数据，也接入了狭义的日志数据，就可以在同一个时间维度上做分析。以时间戳这个维度为核心要素，把不同系统的数据拿过来，再按同样的时间戳做对比分析，排障的时候就会非常方便。

AIOps 已成明显趋势

因为所有的 AI 算法首先的成熟条件就是要有足够多而且充分的数据，显然像互联网行业或者金融银行，这些原先 IT 建设水平就比较高，已经有了不少数据积累的企业更合适做 AIOps，这样的企业现在只是需要用 AI 把这些数据的价值发挥出来。

18 年以来，很多企业都在做 AIOps 方面的尝试或投入，他们会拿出一部分自己的监控系统的数据或日志系统的数据去做一些 AI 尝试，现在来看主要还是在监控和日志这几个方向。AI 还有一些其他的方向，比如智能客服，但这部分就目前来说还不是紧要关头。对于更广泛的企业来说，还是要先抓住监控系统和日志系统做一些处理，这样可以发挥出更明显和直接的价值。

AIOps 的趋势现在已经比较明显了。有的企业已经在开始做尝试，还有的已经在做计划了。因为做 AIOps 还是有些前提条件的，可能有些企业内部建设还没有很完善，但是他们也会关心自己已经完善到了什么地步，这一步的完善对下一步引入 AIOps 会不会有比较明显的帮助。现在，包括在往后的一段时间内，大家应该会非常积极的参与这到件事中。

因为 AIOps 现在还是比较新的东西，现在可能还没有一套特别全的产品提供，主要是将 AI 用在以下三个方面：

• 像日志易这样，会偏向在日志方面，包括模式识别，异常报警等模块加 AI 算法；
• 监控系统，这是一个刚需，每个运维团队都要做的事情；
• 还有一些厂商偏重运维和安全之间的交界点，会拿数据做偏安全方面的方案。

AIOps 落地难点和愿景

现在 AIOps 实践中最大的难点就是我们没有好的样本数据进行学习。另一方面，现在大家集中关注的是从监控和日志里发现问题，定位问题。但是就 AIOps 整体来说，还有很广泛的一面是决策，而这块目前还是缺少突破。虽然现在很多人在提去和原先已有的通用化运维系统做对接，比如现在看到问题了，我们判断一下需要搭几台机器，接口调几台机器，但是对这类问题大家还处在一个粗浅的尝试阶段。

饶琛琳说，理想中的 AIOps 应该是跟无人驾驶的感觉一样。在发现故障之后，AIOps 就可以抉择出来最优的做法，通过判断快速定位，以时间最快成本最优的方式解决问题。最后，我们能想到的是在 DevOps 整个流程闭环中，每一个阶段都有 AI，能完善的流转，最后形成 AIDevOps，甚至 AIDevSecOps。

感谢张婵对本文的策划和审校。