AIOps 实践思考：AIOps 如何与 APM 结合？

背景

2018 年 4 月 13 日由 BATJ，360，华为，云智慧等众多互联网企业参与标准制定工作的《企业级 AIOps 实践建议》白皮书中提到：AIOps 即智能运维，其目标是，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维所未能解决的问题，提高系统的预判能力、稳定性、降低 IT 成本，并提高企业的产品竞争力。Gartner 在 2016 时提出了 AIOps 概念，并预测到 2020 年，AIOps 的采用率将会达到整个运维行业的 50%。

为什么要使用 AIOps 呢？它的价值到底在哪里？我们先来看一下通常情况下运维同学们是怎么处理一个故障的。

• 18:00 开始出现隐患；
• 18:30 业务正常，隐患影响范围在系统可承受范围内；
• 19:00 隐患超出了系统可承受的正常范围，开始转变为故障；
• 19:30 部分业务出现异常，部分客户受到了影响；
• 19:40 异常指标超出监控阈值，监控系统发出告警；
• 19:50 运维人员登录系统开始排查问题；
• 20:20 运维人员找到故障原因，开始处置，此时该故障可能已经影响了大量用户；
• 20:30 故障恢复。业务恢复。

这是传统运维的处理模式。在整个故障从隐患产生到恢复的过程中，有几个明显问题:

• 监控数据获取的问题
  • 监控工具繁杂、无效数据充斥
  • 大量人工配置、缺乏问题的第一级识别
• 隐患发现的问题
  • 静态阈值：潜在隐患不能及时发现、重大隐患处理延迟
  • 信息检索和甄别难度大：海量信息难以迅速定位原因
• 告警的问题
  • 事件处理效率低：历史告警无模型
  • 缺少事件压缩和升降级：大故障时消息洪水带来副作用
• 处理的问题
  • 缺乏有效的数据依据：严重依赖人脑和经验
  • 处置后无法评价：只存在故障的是与否，一旦波动束手无策

实践 AIOps 的常见场景

除去这四类明显问题之外，当然还有更多的问题。比如：复杂多变的软硬件环境中，如何利用海量且有高价值的监控数据来保障业务高效安全运转？在这过程中，运维规则同样也是灵活多变的，又如何有效地进行管理和维护？针对这些传统运维的痛点，不难抽象出以下几个典型的场景：

智能异常检测

这里我们提到的异常检测，特指从海量的运维监控数据指标中，针对时间序列类型数据指标的不正常问题发现。简单说，即发现历史数据中与大部分对象不同的离群对象，这不同于依靠人来判断的指标评价，能够更有效地提升发现问题的准确性和时效性。

智能告警

使用历史数据学习得到的动态阈值替代静态阈值，更及时地发现重大隐患或故障。

智能的告警消息相关性分析和收敛，解决故障发生时，告警风暴带来的副作用。通过对告警消息的相关性分析，可以识别出告警的模式，将多条相关告警合并或转化成一条具有更多信息的告警，从而帮助更快更准确地诊断故障。

智能故障根因分析

在故障管理的检测、定位与识别的三个阶段中，故障的识别和诊断尤为重要。根因分析也被称为故障定位、故障隔离或警报 / 事件相关性，是推断产生一组给定症状的一组故障的过程。根因分析要求必须使用一个解释故障和症状之间关系的模型来执行这个推理过程。

智能时间序列预测

基于海量的历史数据习得模型，对未来的趋势的变化进行预测，并在生产过程中持续不断的进行模型的补偿修正，同时可以实现故障或事故发生前较准确的提前预警。

在这一系列典型的场景中，可预期的输出结果有影响范围、原因概率和影响概率、具体的某个类型的对象实体。而要求输入的数据能够满足以下几个方面：

• 足够存量的数据以及足够的数据增量
  • 只有足够存量的数据才有条件去进行模型的训练
  • 只有足够的数据增量才有条件补偿修正训练得到的模型
• 数据维度覆盖度要（时间维度、地域维度、系统级维度、应用级维度等）足够
  • 时间维度的提高有助于发现指标的时间周期性和预测的准确度，而没有足够的时间跨度将因损失周期性而大大降低数据价值
  • 地域维度
    • 从业务角度讲，大规模复杂系统，网络层面的故障往往造成区域性的影响。如 CDN 的故障影响、骨士网络质量的影响以及区域性网络质量的影响。通过分布式主动网络监测和真实用户体验的监测手段，这引起看似不可预知的故障发生，也可以在刚开始影响用户时就及时地感知到隐患的直接影响范围，从而降低故障影响时间。
  • 系统级维度
    • 时至今日，业务系统的软硬件规模日趋庞大，而软硬件的组合和调用关系也更加复杂，大规模复杂系统一旦发生故障往往是一点带面的影响。同时随着子业务每的变更频率增大，相关联上下游的业务系统的性能和稳定性也会受到严竣的挑战。在复杂系统中，因为某个或某些子系统的突变事件，往往形成多米诺骨牌型的连锁效应，而采集的数据如果拥有完善的系统级维度，也势必为隐患和故障的发现定位和预测带来便利。
  • 应用级维度
    • 一旦应用系统发生隐患或故障时，在问题的定位过程中，除去因物理和网络因素导致外，Server 端故障多因程序 Bug 或 SQL 使用不当而引起。在分析问题所需的数据中，出现程序运行缓慢或异常、错误发生时的代码执行栈、运行切片、SQL 调用详情、进程或线程锁等等信息，都将为故障的定位速度和预测结果带来直接影响。
  • 数据间归属和关联标记
    • 非监督算法得到的数据有时需要人工监督或半监督的方式来进行修正，而此时对数据分析工程师或业务人员的要求都会非常高，这只在小数据规模或简单业务场景中可行，当面临大模的或复杂的业务场景时，是决不可取的。那么假如数据产生时就具备某种天然的联系，则必然会为模型的训练、校验和修正带来事半功倍的效果。

AIOps 为什么可以与 APM 相结合

前面已经列出了本文要解决的问题和需求，下面试图论述 AIOps 必须与 APM 相结合的必要性。

APM 的全称是 Application Performance Management（应用性能管理），是由 Gartner 归纳抽象出的一个管理模型。APM 管理模型中要求做到这样五个层次：终端真实用户体验、运行时应用架构映射、应用事务分析、深度应用诊断和分析报告。为了支撑这五个层次的管理需求，一套完整的 APM 系统需要采集至少以下几种类型的数据：

用户端体验数据

包括各种浏览器和 APP（原生或 H5 或混合模式）客户端下的首屏时间、DNS 解析时间、首包时间等指标、JS 错误、IP 运营商数据、崩溃分析、卡顿分析、HTTP 和 Socket 链接与请求时间与错误率、资源加载等数据。更为重要的是基于 Session Path 得到的用户行为路径数据，这使得从客户端采集到的所有数据天然地获得了用户行为的属性 – 这对于海量客户端倾刻间产生的海量数据，是一个多么棒的消息！

应用性能数据

包括应用受访时的请求参数、执行时间、错误详情和错误率、异常详情和异常率、调用外部资源的时间和详情（如 SQL、MQ、API、RPC 等）、类和方法的执行时间与运行栈、虚机的状态数据（GC、Heap、线程池等）。更为重要的是基于 Trace 模型构造得到的数据间关系，这将发现应用与应用、应用与资源之间的关联关系。显而易见，可以通过这个关系快速地得到应用运行时的逻辑拓扑，同时也为即将进行的数据挖掘和预测提供强有力的数据依据。常见 Trace 模型包括 Google Dapper 和 Twitter Zipkin 方案，尤以 Google Dapper 最为常用。

服务器和服务的状态数据

这不同于通常的 Zabbix 等监控产品收集的数据，而是与应用、业务相关联，状态数据在产生时除去时间维度与应用业务间接相关之外，同样的由于 Trace 模型而变得与应用和业务直接相关。

端到端的数据联系

利用 APM 系统得到的数据实践于 AIOps，最有利的武器便是 Trace 模型。利用 Trace 模型得到的数据是具备了天然的数据联系的。基于 Trace 模型也很容易进行扩展，即将浏览器和 APP 客户端也加入到模型中。端到端指客户应用端到 Server 应用端的数据，在用户发起请求的最贴近用户侧产生惟一的 Trace ID、并通过 Request Header 或其他请求属性向 Server 端应用传递，于是用户端体验数据、应用性能数据、服务器和服务的状态数据，这三大类数据便有了天然的关系标记。

AIOps 如何与 APM 结合

通过 APM 和 APM 采集数据的简单介绍，不难看出实践 AIOps 所需要的数据需求，以及 APM 系统提供的各维度数据。在这个供求关系中，APM 系统提供的数据存量和增量足够满足、数据维度的覆盖度足够满足、数据间的归属和关联标记堪称完美。

我们再回过头来看，针对传统运维的痛点抽象出的几个典型场景，APM 系统提供的数据能否很好的应对：

• 智能异常检测

在 APM 系统中，关键事务是一个重要的需求场景。通过用户指定或系统习得的具备高频访问或至关重要的关键业务被称为关键事务，由于数据产生的时序性，在异常检测场景中，不仅可以很好地进行异常检测，也可以基于调用链的关系和用户行为来做故障的范围预测。

• 智能告警和智能时间序列预测

这两个典型 AIOps 场景对于 APM 系统提供的数据同样适用，并且由于数据间的系统级与应用级关系，模式识别变得更加简单高效，关系模型可以直接应用于告警模型的训练中，成功规避了场景中监督或半监督里最头疼的人为干预的难题。应用智能告警收敛，AIOps 系统可以提供闪断、高频、阴断等多种告警压缩规则，基于算法削减无价值消息，缩短问题发现时间排除消息洪水的干扰。

• 智能故障根因分析

前面已经较为详细地介绍了多种 Trace 模型，并且论证了因 Trace 模型而带来的数据间的天然关系。据 Gartner 多名分析师称：APM 系统实践 AIOps 最有利的武器便是 Trace 模型，它为分析问题提供了主线条。如果不用 APM 的话，应该怎么做呢？通常会根据人员经验或根据特定的业务场景，在应用程序中埋入追踪代码，即通称的“打点”法，这具有很大的局限性并因业务变更具有很大的操作难度，几乎不可能或很难进行标准化和产品化。

利用 APM 系统提供的数据实践 AIOps，从应用健康、用户体验或业务表现的外部视角来审视故障，如发现到某个具体的关键事务非常缓慢、某地域的用户受到了严重影响，关联诊断到最可能影响性能的代码段或 SQL 语句、应用服务器或中间件的某个节点 Load 或 IO 情况。

小结

通过本文的阅读，您可以获知实践 AIOps 时利用 APM 系统的数据相较于传统的运维数据更为快速有效。APM 系统不仅向 AIOps 实践过程中提供足够丰富的数据以让 AIOps 平台更快适应企业的应用场景、为 AIOps 的实践过程提供了采集、处理和存储的关键技术基础，并可以为 AIOps 的实践效果验证和评价。

作者简介

高驰涛 (Neeke)，云智慧研发总监，是 PHP 开发组成员，同时也是 PECL/SeasLog 的作者。早期从事大规模企业信息化研发架构，曾先后任职于易车集团和某大型微博营销平台，09 年涉足互联网数字营销领域并深入研究架构与性能优化。2014 年加入云智慧，致力于 APM 产品的架构与研发，对业务运维、智能运维有着独到的见解，崇尚敏捷，高效，GettingReal。