摘要：本文將介紹攜程實時智能異常檢測平臺——Prophet。到目前為止，Prophet 基本覆蓋了攜程所有業務線，監控指標的數量達到 10K+，覆蓋了攜程所有訂單、支付等重要的業務指標。Prophet 將時間序列的數據作為數據輸入，以監控平臺作為接入對象，以智能告警實現異常的告警功能，并基于 Flink 實時計算引擎來實現異常的實時預警，提供一站式異常檢測解決方案。

本次分享主要分為四個方面：

一.背景介紹

二.Prophet

三.智能化與實時化

四.挑戰與展望

?

一、背景介紹

?

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 年大數據領域研發經驗，擁有于實時計算的研究與推廣。

總結

以上是生活随笔為你收集整理的监控指标10K+！携程实时智能检测平台实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。