作者：潘国庆@携程
点击查看本场直播>>>
一、背景介绍
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 时刻区间是潜在的异常区间。
- 基于历史同期数据均值与标准差判断：同时需要与上周同期的时间进行对比，同一区间的数值偏差较大，则判断为异常。当异常样本较多时，可以用简单的机器学习分类模型通过预测值和实际值做异常判断。
8.常见场景
常见问题：对于用户来说，监控指标太多，监控的维度也比较多。比如一个指标可能有 max、min 等不同的统计方式，监控指标的数量就会比较多。其次，用户能力有限，很难每日查看监控告警。
异常原因：发生异常的原因一般会是技术性问题。如发布新版本上线时可能存在的 bug 导致业务出现下跌。少数的情况是由于外部因素的影响，比如调用外部链接或者服务，外部服务宕掉导致自己的服务出现问题。
解决方案：用户为 Prophet 提供的检测结果进行标注，选择检测结果的正确性。用户的标注数据会用到 Prophet 以后的模型训练中用于优化数据集。
9.节假日场景
由于携程做旅游方向的业务，节假日期间问题较为突出。不同类型的业务在节假日的表现是不同的。
- 例如携程的机票、火车票基本是在节前上升到一定量，到假期期间由于人们出游，该买的票已经购买完成，机票等业务订单量会下降很多。
- 而酒店等业务在节假期间会上升很多。不同类型业务的趋势不同，上升幅度较大的业务容易产生漏报，对于下跌幅度较大的业务，容易产生误报。
节假日应对手段：不同的场景会导致不同的问题，所以 Prophet 针对节假日场景做了一些特殊处理。
- 首先，维护每年节假日信息表，程序一旦发现下一个节假日还有一个星期时，Prophet 就会提取出过去两年内的不同节假日期间的数据。
- 其次，计算前两年的不同节假日和当前节假日数值的相似度来匹配。相当于以当前节假日的数据拟合过去节假日的数据，拟合到某个时间段时，就知道大概从某个时间开始到某个时间结束是和当前趋势类似的。
- 然后，会用过去多个节假日的数据作为一个组合作为新模型的数据输入去训练数据集。不同节假日的占比不同，通过一些方式计算出不同占比值。
- 最终，基于组合的数据集训练出新的模型，新的模型可以比较好地预测出某一个指标或者某一个业务在节假期七天之内的趋势。
10.平台现状
Prophet 基本覆盖了携程所有业务线。即携程的重要业务指标基本都已经在使用监控智能告警。业务类型包含 7 种。监控指标的数量达到 10K+，覆盖了携程所有订单、支付等重要的业务指标，覆盖了大部分服务的重要的业务指标。接入平台在 10+ 左右，基本接入了携程公司所有系统级别的监控平台，在陆续接入各个业务部门自己的监控平台。
Prophet 平台能够覆盖 95% 左右的异常，准确报警率达到 75%。因为每个数据同步到 Prophet 便触发数据实时消费、预测以及告警，告警延迟达到 ms 级别。告警数量也下降了十倍左右。
四、挑战与展望
1.挑战
资源消耗大：如果采用 LSTM 模型，需要为每个指标训练模型，单个 Flink 作业里面都加载了约 4K~5K 的模型，无论训练资源还是实时处理资源消耗都相对较大。
节假日影响：由于在业务指标在不同节假日的趋势不同，告警准确性受到一定程度的影响。
智能告警无法适用于全部场景：有些机器的 CPU 的使用率可以直接设定阈值，达到 95% 时告警，非常方便简单。但是如果用智能告警的方式拟合其趋势，意义不大。另外节假日大促时，会发放门票、酒店优惠券等活动，其订单量可能快速增长 10 倍到 100 倍。这种突发的快速增长在历史数据也很难学习到。上述场景的数据智能告警比较难处理。
2.展望
针对上述问题，Prophet 正陆续进行改进，希望通过下面几种方式解决遇到的挑战。通用模型迫在眉睫：Prophet 目前训练了一个 DNN 模型，可以处理所有监控指标。DNN 模型的准确率可能相较于 LSTM 模型会低一点，但能够涵盖较多场景。所以针对订单、支付等重要的业务指标，可以使用 LSTM 算法模型，保证准确性，但对于相对不太重要的业务指标，可以使用 DNN 通用模型。
- 节假日算法上线：Prophet 节假日算法已经在线上验证半年，基本可以保证其准确性。
- 覆盖携程全部监控平台：Prophet 已经覆盖了携程 70%~80% 的监控平台。大部分业务指标是在公司的系统监控级别，所以只要能覆盖公司级别的监控系统，就可以覆盖大部分重要的业务指标。后续，Prophet 也将陆续接入更多业务部门的监控平台。
作者介绍：
潘国庆，携程大数据研发经理。2016 年加入携程大数据平台团队，主导了 Muise 平台从 Storm 至 Spark Streaming 再到 Flink 的架构升级与技术演进，目前负责携程实时智能异常检测的架构设计与研发。拥有 5 年大数据领域研发经验，拥有于实时计算的研究与推广。
