监控指标10K+！携程实时智能检测平台实践

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

简介： 本文将介绍携程实时智能异常检测平台——Prophet。到目前为止，Prophet 基本覆盖了携程所有业务线，监控指标的数量达到 10K+，覆盖了携程所有订单、支付等重要的业务指标。Prophet 将时间序列的数据作为数据输入，以监控平台作为接入对象，以智能告警实现异常的告警功能，并基于 Flink 实时计算引擎来实现异常的实时预警，提供一站式异常检测解决方案。

作者：潘国庆@携程

一、背景介绍

1.规则告警带来的问题

大部分监控平台是基于规则告警实现监控指标的预警。规则告警一般基于统计学，如某个指标同比、环比连续上升或下降到一定阈值进行告警。规则告警需要用户较为熟悉业务指标的形态，从而较为准确的配置告警阈值，这样带来的问题是配置规则告警非常繁琐、告警效果也比较差，需要大量人力物力来维护规则告警。

当一个告警产生时，也需要耗费许多人力验证告警是否正确并确认是否需要重新调整阈值。在携程，规则告警还涉及了其它问题，比如携程仅公司级别的监控平台就有三个，每个业务部门还会根据自己的业务需求或业务场景构建自己的监控平台。携程内部有十几个不同规模的监控平台，在每一个监控平台都配置监控指标，对于用户是非常繁琐的。

二、Prophet

针对规则告警存在的以上几种问题，携程构建了自己的实时智能异常检测平台—— Prophet。携程构建 Prophet 的灵感源于 FaceBook 的 Prophet，但实现上有别于 FaceBook 的 Prophet。

1.一站式异常检测解决方案

首先，Prophet 以时间序列类型的数据作为数据输入。其次，Prophet 以监控平台作为接入对象，以去规则化为目标。基于深度学习算法实现异常的智能检测，基于实时计算引擎实现异常的实时检测，提供了统一的异常检测解决方案。

2.Prophet 系统架构

底层：Hadoop 底层。YARN 作为统一资源调度引擎，主要用于运行 Flink 的作业。HDFS 主要用于存储训练好的 TensorFlow 模型。
引擎层：首先数据必须实时存在于消息队列当中，Prophet 使用的是 Kafka。此外，Prophet 使用 Flink 计算引擎实现实时异常预警，使用 TensorFlow 作为深度学习模型的训练引擎。同时 Prophet 基于时序数据库存储历史数据。
平台层：最上层是对外提供服务的平台层 Prophet。Clog 用于采集作业日志。Muise 是实时计算平台。Qconfig 用于存储作业中需要用到的配置项。Hickwall 用于作业的监控告警。

3.Why Flink？

目前主流的实时计算引擎有 Flink、Storm 和 SparkStreaming 等多种，携程选择Flink 作为 Prophet 平台的实时计算引擎的原因主要是Flink具备以下四点特征：

高效的状态管理：异常检测的过程中有许多状态信息需要存储。使用 Flink 自带的 State Backend 可以很好地存储中间状态信息。
丰富的窗口支持：窗口包含滚动窗口、滑动窗口以及其他窗口。Prophet 基于滑动窗口进行数据处理。
支持多种时间语义：Prophet 基于 Event Time。
支持不同级别的容错语义：Prophet 至少需要做到 At Least Once 或 Exactly Once 的级别。

4.Prophet 操作流程

用户只需要在自己常用的监控平台上选择配置智能告警，后续所有流程都是由监控平台和 Prophet 智能告警平台对接完成。监控平台所需要做的包含两件事：

首先将用户配置的监控指标同步到 Prophet 平台；
其次监控平台需将用户配置的监控指标数据实时的推送到 Kafka 消息队列中。

Prophet 在接受到新的监控指标后，便开始尝试使用 Tensorflow 训练模型。模型训练需要历史数据，平台可以按照约定好的规范提供历史数据查询接口，Prophet 通过接口获取历史数据并进行模型训练、如果没有接口，Prophet 基于消息队列中的数据来积累训练数据集。模型训练完成后，将其上传到 HDFS，Prophet 会更新配置中心中的配置通知 Flink 有新训练好的模型可以加载。所有实时推送到 Kafka 里面的监控指标的数值，会同步的落到 Prophet 的时序数据库中，在异常检测的过程中需要用到这些指标数值。

当模型训练完成后，Flink 的作业一旦监听到配置发生了更新，就开始尝试加载新模型，实时消费 Kafka 里面的指标数据，最终产出检测结果以及异常告警会回写至 Kafka，各个监控平台会从 Kafka 获取自己监控平台的那一部分告警数据。整套 Prophet 操作流程对于用户是无感知的，用户只需要配置告警，极大的提供了便捷性。

三、智能化与实时化

1.智能化挑战

在做智能检测之前还会遇到一些挑战。

负样本少：生产环境中发生异常的概率比较小。携程在很多年的时间仅积累了大概几千条负样本数据。
业务指标类型多：业务指标类型繁多，有订单、支付等业务类型的指标，也有服务类型的指标，如请求数、响应延时等，以及硬件设施类型的指标，如 CPU、内存、硬盘等各种指标。
业务指标形态多：正因为有不同类型的业务指标，业务指标的形态也各不相同。携程将业务指标形态归纳为三部分。一是周期波动相对平稳的指标，第二是稳定的，不会剧烈波动的指标，第三是上下波动幅度非常剧烈、呈现不稳定的形态的指标。

2.深度学习算法选择

针对以上三点问题，携程尝试了 RNN，LSTM 和 DNN 等多种深度学习算法。

RNN：RNN 的优点是适合时间序列类型的数据，而缺点是存在梯度消失问题。
LSTM 模型：LSTM 的优点是解决了梯度消失的问题。RNN 和 LSTM 深度学习算法需要先给每个指标训练一个模型，然后输入当前的数据集，基于模型来预测当前数据集的走向。然后再比对预测数据集和当前数据集进行异常检测。这种方式带来的好处是检测精度高，但是单指标单模型也带来更多的资源消耗。
DNN：DNN 的优点是单个模型能够覆盖所有异常检测的场景。但是特征提取会非常复杂，需要提取不同频域的特征，需要大量用户标注数据。

3.离线模型训练

携程一般两周发一次版本，每个业务指标都是每两周尝试训练一次，模型输入的训练数据也取两周的数据集。

在使用历史数据之前需要做数据预处理，比如历史数据中可能存在 null 值，需要使用均值标准差将其补齐。
其次，历史数据区间里面肯定会有一些异常区间，需要用一些预测值替换异常区间的异常值。
另外，由于节假日期间数据较为复杂，需要替换节假日期间的异常值。对历史数据的数据集做数据预处理之后，开始提取其不同时序的特征或者频率的特征。
然后，通过一个分类模型分类出指标是平稳的、非周期的还是周期型的。不同类型的指标需要不同的模型进行训练。

4.模型动态加载

模型训练完成后，Flink 作业需要动态加载模型。但实际场景下，不可能每训练一个模型便重启一次 Flink 作业。所以 Prophet 平台将模型训练完成后上传到 HDFS，通知配置中心，然后 Flink 作业开始从 HDFS 上拉取模型。为了使每个模型均匀分布在不同的 Task Manager 上面，所有监控指标会根据本身 id 做 keyBy，均匀分布在不同的 Task Manager 上。每个 Task Manager 只加载自己部分的模型，以此降低资源消耗。

5.数据实时消费与预测

模型加载完成后需要做实时异常检测。首先从 Kafka 消息队列中消费实时数据。Prophet 目前基于 Flink Event Time + 滑动窗口。监控指标的时间粒度可以分为很多种，如 1 分钟一个点、5 分钟一个点、10 分钟一个点等等。例如基于 1 分钟一个点的场景来看，在 Flink 作业中开一个窗口，其长度是十个时间粒度，即十分钟。当积累到十条数据时，用前五个数据预测下一个数据，即通过第 1、2、3、4、5 五个时刻的数据去预测第六个时刻的数据，然后用第 2、3、4、5、6 时刻的数据预测第七个时刻的数据。最终获得第 6、7、8、9、10 五个时刻的预测值和实际值。再利用预测值与实际值进行对比。以上是数据无异常的理想场景下的情况。

6.数据插补与替换

实际场景下往往会出现意想不到的情况。例如上述 10 分钟的场景中只获得了 9 条数据，缺少第4个时刻的数据， Prophet 会使用均值标准差补齐此类缺失数据。另外如果在上一个时刻检测到第 6、7、8、9、10 时间区间是异常区间，发生了下跌或者上升。那么此区间的数据被认为是不正常的，不能作为模型输入。此时需要用上一批次模型预测出的第 6 时刻的值替换原始的第六个时间粒度的值。第 2、3、4、5、6 这五个时刻值中第 4 是插补而来的，第 6 是时间区间训练出来的预测值替换掉了异常值。

以插补替换之后的值作为模型输入，得到新的预测值7。再依次进行预测。中间过程中异常区间第 6、7、8、9、10 时刻的预测值需要作为一个状态来存储到 Flink StateBackend，后续窗口会使用到这些预测值。

7.实时异常检测

实时异常检测主要可以从以下几个方面进行判断：

基于异常类型与敏感度判断：不同的指标存在不同的异常类型，如上升异常，下跌异常。其次，不同指标敏感度不同，可以定义其为高敏感度、中敏感度、低敏感度。当高敏感度指标发生简单的下降抖动时，认为是下跌异常。中敏感度指标可能连续下跌两个点时会判断异常。对于低敏感度指标，当下跌幅度较大时才会判断为异常。
基于预测集与实际集的偏差判断：如果预测结果和实际结果偏差较大，认定当前第 6、7、8、9、10 时刻区间是潜在的异常区间。
基于历史同期数据均值与标准差判断：同时需要与上周同期的时间进行对比，同一区间的数值偏差较大，则判断为异常。当异常样本较多时，可以用简单的机器学习分类模型通过预测值和实际值做异常判断。