監控指標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/...