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

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

1、背景介绍

1.规则告警带来的问题

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

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

2、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 操做流程对于用户是无感知的，用户只须要配置告警，极大的提供了便捷性。

3、智能化与实时化

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 做业中开一个窗口，其长度是十个时间粒度，即十分钟。当积累到十条数据时，用前五个数据预测下一个数据，即经过第 一、二、三、四、5 五个时刻的数据去预测第六个时刻的数据，而后用第 二、三、四、五、6 时刻的数据预测第七个时刻的数据。最终得到第 六、七、八、九、10 五个时刻的预测值和实际值。再利用预测值与实际值进行对比。以上是数据无异常的理想场景下的状况。

6.数据插补与替换

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

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

7.实时异常检测

实时异常检测主要能够从如下几个方面进行判断：

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

8.常见场景

常见问题
异常缘由
解决方案

阅读原文看场景运用：https://developer.aliyun.com/...