监控指标10K+！携程实时智能检测平台实践
摘要：本文將介紹攜程實時智能異常檢測平臺——Prophet。到目前為止，Prophet 基本覆蓋了攜程所有業(yè)務線，監(jiān)控指標的數(shù)量達到 10K+，覆蓋了攜程所有訂單、支付等重要的業(yè)務指標。Prophet 將時間序列的數(shù)據(jù)作為數(shù)據(jù)輸入，以監(jiān)控平臺作為接入對象，以智能告警實現(xiàn)異常的告警功能，并基于 Flink 實時計算引擎來實現(xiàn)異常的實時預警，提供一站式異常檢測解決方案。
本次分享主要分為四個方面：
一.背景介紹
二.Prophet
三.智能化與實時化
四.挑戰(zhàn)與展望
?
一、背景介紹
?
1.規(guī)則告警帶來的問題
?
大部分監(jiān)控平臺是基于規(guī)則告警實現(xiàn)監(jiān)控指標的預警。規(guī)則告警一般基于統(tǒng)計學，如某個指標同比、環(huán)比連續(xù)上升或下降到一定閾值進行告警。規(guī)則告警需要用戶較為熟悉業(yè)務指標的形態(tài)，從而較為準確的配置告警閾值，這樣帶來的問題是配置規(guī)則告警非常繁瑣、告警效果也比較差，需要大量人力物力來維護規(guī)則告警。
?
當一個告警產(chǎn)生時，也需要耗費許多人力驗證告警是否正確并確認是否需要重新調整閾值。在攜程，規(guī)則告警還涉及了其它問題，比如攜程僅公司級別的監(jiān)控平臺就有三個，每個業(yè)務部門還會根據(jù)自己的業(yè)務需求或業(yè)務場景構建自己的監(jiān)控平臺。攜程內部有十幾個不同規(guī)模的監(jiān)控平臺，在每一個監(jiān)控平臺都配置監(jiān)控指標，對于用戶是非常繁瑣的。
?
?
?
?
二、Prophet
?
針對規(guī)則告警存在的以上幾種問題，攜程構建了自己的實時智能異常檢測平臺—— Prophet。攜程構建 Prophet 的靈感源于 FaceBook 的 Prophet，但實現(xiàn)上有別于 FaceBook 的 Prophet。
?
1.一站式異常檢測解決方案
?
首先，Prophet 以時間序列類型的數(shù)據(jù)作為數(shù)據(jù)輸入。其次，Prophet 以監(jiān)控平臺作為接入對象，以去規(guī)則化為目標。基于深度學習算法實現(xiàn)異常的智能檢測，基于實時計算引擎實現(xiàn)異常的實時檢測，提供了統(tǒng)一的異常檢測解決方案。
?
?
2.Prophet 系統(tǒng)架構
?
-
底層：Hadoop 底層。YARN 作為統(tǒng)一資源調度引擎，主要用于運行 Flink 的作業(yè)。HDFS 主要用于存儲訓練好的 TensorFlow 模型。
-
引擎層：首先數(shù)據(jù)必須實時存在于消息隊列當中，Prophet 使用的是 Kafka。此外，Prophet 使用 Flink 計算引擎實現(xiàn)實時異常預警，使用 TensorFlow 作為深度學習模型的訓練引擎。同時 Prophet 基于時序數(shù)據(jù)庫存儲歷史數(shù)據(jù)。
-
平臺層：最上層是對外提供服務的平臺層 Prophet。Clog 用于采集作業(yè)日志。Muise 是實時計算平臺。Qconfig 用于存儲作業(yè)中需要用到的配置項。Hickwall 用于作業(yè)的監(jiān)控告警。
?
3.Why Flink？
?
目前主流的實時計算引擎有 Flink、Storm 和 SparkStreaming 等多種，攜程選擇Flink 作為 Prophet 平臺的實時計算引擎的原因主要是Flink具備以下四點特征：
?
-
高效的狀態(tài)管理：異常檢測的過程中有許多狀態(tài)信息需要存儲。使用 Flink 自帶的 State Backend 可以很好地存儲中間狀態(tài)信息。
-
豐富的窗口支持：窗口包含滾動窗口、滑動窗口以及其他窗口。Prophet 基于滑動窗口進行數(shù)據(jù)處理。
-
支持多種時間語義：Prophet 基于 Event Time。
-
支持不同級別的容錯語義：Prophet 至少需要做到 At Least Once 或 Exactly Once 的級別。
?
?
4.Prophet?操作流程
?
用戶只需要在自己常用的監(jiān)控平臺上選擇配置智能告警，后續(xù)所有流程都是由監(jiān)控平臺和 Prophet 智能告警平臺對接完成。監(jiān)控平臺所需要做的包含兩件事：
?
-
首先將用戶配置的監(jiān)控指標同步到 Prophet 平臺；?
-
其次監(jiān)控平臺需將用戶配置的監(jiān)控指標數(shù)據(jù)實時的推送到 Kafka 消息隊列中。
?
?
Prophet 在接受到新的監(jiān)控指標后，便開始嘗試使用 Tensorflow 訓練模型。模型訓練需要歷史數(shù)據(jù)，平臺可以按照約定好的規(guī)范提供歷史數(shù)據(jù)查詢接口，Prophet 通過接口獲取歷史數(shù)據(jù)并進行模型訓練、如果沒有接口，Prophet 基于消息隊列中的數(shù)據(jù)來積累訓練數(shù)據(jù)集。模型訓練完成后，將其上傳到 HDFS，Prophet 會更新配置中心中的配置通知 Flink 有新訓練好的模型可以加載。所有實時推送到 Kafka 里面的監(jiān)控指標的數(shù)值，會同步的落到 Prophet 的時序數(shù)據(jù)庫中，在異常檢測的過程中需要用到這些指標數(shù)值。
?
當模型訓練完成后，Flink 的作業(yè)一旦監(jiān)聽到配置發(fā)生了更新，就開始嘗試加載新模型，實時消費 Kafka 里面的指標數(shù)據(jù)，最終產(chǎn)出檢測結果以及異常告警會回寫至 Kafka，各個監(jiān)控平臺會從 Kafka 獲取自己監(jiān)控平臺的那一部分告警數(shù)據(jù)。整套 Prophet 操作流程對于用戶是無感知的，用戶只需要配置告警，極大的提供了便捷性。
?
?
三、智能化與實時化
?
1.智能化挑戰(zhàn)
?
在做智能檢測之前還會遇到一些挑戰(zhàn)。
?
-
負樣本少：生產(chǎn)環(huán)境中發(fā)生異常的概率比較小。攜程在很多年的時間僅積累了大概幾千條負樣本數(shù)據(jù)。
-
業(yè)務指標類型多：業(yè)務指標類型繁多，有訂單、支付等業(yè)務類型的指標，也有服務類型的指標，如請求數(shù)、響應延時等，以及硬件設施類型的指標，如 CPU、內存、硬盤等各種指標。
-
業(yè)務指標形態(tài)多：正因為有不同類型的業(yè)務指標，業(yè)務指標的形態(tài)也各不相同。攜程將業(yè)務指標形態(tài)歸納為三部分。一是周期波動相對平穩(wěn)的指標，第二是穩(wěn)定的，不會劇烈波動的指標，第三是上下波動幅度非常劇烈、呈現(xiàn)不穩(wěn)定的形態(tài)的指標。
?
?
2.深度學習算法選擇
?
針對以上三點問題，攜程嘗試了 RNN，LSTM 和 DNN 等多種深度學習算法。
?
-
RNN：RNN 的優(yōu)點是適合時間序列類型的數(shù)據(jù)，而缺點是存在梯度消失問題。
-
LSTM 模型：LSTM 的優(yōu)點是解決了梯度消失的問題。RNN 和 LSTM 深度學習算法需要先給每個指標訓練一個模型，然后輸入當前的數(shù)據(jù)集，基于模型來預測當前數(shù)據(jù)集的走向。然后再比對預測數(shù)據(jù)集和當前數(shù)據(jù)集進行異常檢測。這種方式帶來的好處是檢測精度高，但是單指標單模型也帶來更多的資源消耗。
-
DNN：DNN 的優(yōu)點是單個模型能夠覆蓋所有異常檢測的場景。但是特征提取會非常復雜，需要提取不同頻域的特征，需要大量用戶標注數(shù)據(jù)。
?
3.離線模型訓練
?
攜程一般兩周發(fā)一次版本，每個業(yè)務指標都是每兩周嘗試訓練一次，模型輸入的訓練數(shù)據(jù)也取兩周的數(shù)據(jù)集。
?
-
在使用歷史數(shù)據(jù)之前需要做數(shù)據(jù)預處理，比如歷史數(shù)據(jù)中可能存在 null 值，需要使用均值標準差將其補齊。
-
其次，歷史數(shù)據(jù)區(qū)間里面肯定會有一些異常區(qū)間，需要用一些預測值替換異常區(qū)間的異常值。
-
另外，由于節(jié)假日期間數(shù)據(jù)較為復雜，需要替換節(jié)假日期間的異常值。對歷史數(shù)據(jù)的數(shù)據(jù)集做數(shù)據(jù)預處理之后，開始提取其不同時序的特征或者頻率的特征。
-
然后，通過一個分類模型分類出指標是平穩(wěn)的、非周期的還是周期型的。不同類型的指標需要不同的模型進行訓練。
?
?
4.模型動態(tài)加載
?
模型訓練完成后，Flink 作業(yè)需要動態(tài)加載模型。但實際場景下，不可能每訓練一個模型便重啟一次 Flink 作業(yè)。所以 Prophet 平臺將模型訓練完成后上傳到 HDFS，通知配置中心，然后 Flink 作業(yè)開始從 HDFS 上拉取模型。為了使每個模型均勻分布在不同的 Task Manager 上面，所有監(jiān)控指標會根據(jù)本身 id 做 keyBy，均勻分布在不同的 Task Manager 上。每個 Task Manager 只加載自己部分的模型，以此降低資源消耗。
?
?
5.數(shù)據(jù)實時消費與預測
?
模型加載完成后需要做實時異常檢測。首先從 Kafka 消息隊列中消費實時數(shù)據(jù)。Prophet 目前基于 Flink Event Time + 滑動窗口。監(jiān)控指標的時間粒度可以分為很多種，如 1 分鐘一個點、5 分鐘一個點、10 分鐘一個點等等。例如基于 1 分鐘一個點的場景來看，在 Flink 作業(yè)中開一個窗口，其長度是十個時間粒度，即十分鐘。當積累到十條數(shù)據(jù)時，用前五個數(shù)據(jù)預測下一個數(shù)據(jù)，即通過第 1、2、3、4、5 五個時刻的數(shù)據(jù)去預測第六個時刻的數(shù)據(jù)，然后用第 2、3、4、5、6 時刻的數(shù)據(jù)預測第七個時刻的數(shù)據(jù)。最終獲得第 6、7、8、9、10 五個時刻的預測值和實際值。再利用預測值與實際值進行對比。以上是數(shù)據(jù)無異常的理想場景下的情況。
?
?
6.數(shù)據(jù)插補與替換
?
實際場景下往往會出現(xiàn)意想不到的情況。例如上述 10 分鐘的場景中只獲得了 9 條數(shù)據(jù)，缺少第4個時刻的數(shù)據(jù)， Prophet 會使用均值標準差補齊此類缺失數(shù)據(jù)。另外如果在上一個時刻檢測到第 6、7、8、9、10 時間區(qū)間是異常區(qū)間，發(fā)生了下跌或者上升。那么此區(qū)間的數(shù)據(jù)被認為是不正常的，不能作為模型輸入。此時需要用上一批次模型預測出的第 6 時刻的值替換原始的第六個時間粒度的值。第 2、3、4、5、6 這五個時刻值中第 4 是插補而來的，第 6 是時間區(qū)間訓練出來的預測值替換掉了異常值。
?
以插補替換之后的值作為模型輸入，得到新的預測值7。再依次進行預測。中間過程中異常區(qū)間第 6、7、8、9、10 時刻的預測值需要作為一個狀態(tài)來存儲到 Flink StateBackend，后續(xù)窗口會使用到這些預測值。
?
?
7.實時異常檢測
?
實時異常檢測主要可以從以下幾個方面進行判斷：
?
-
基于異常類型與敏感度判斷：不同的指標存在不同的異常類型，如上升異常，下跌異常。其次，不同指標敏感度不同，可以定義其為高敏感度、中敏感度、低敏感度。當高敏感度指標發(fā)生簡單的下降抖動時，認為是下跌異常。中敏感度指標可能連續(xù)下跌兩個點時會判斷異常。對于低敏感度指標，當下跌幅度較大時才會判斷為異常。
-
基于預測集與實際集的偏差判斷：如果預測結果和實際結果偏差較大，認定當前第 6、7、8、9、10 時刻區(qū)間是潛在的異常區(qū)間。
-
基于歷史同期數(shù)據(jù)均值與標準差判斷：同時需要與上周同期的時間進行對比，同一區(qū)間的數(shù)值偏差較大，則判斷為異常。當異常樣本較多時，可以用簡單的機器學習分類模型通過預測值和實際值做異常判斷。
?
?
8.常見場景
?
-
常見問題：對于用戶來說，監(jiān)控指標太多，監(jiān)控的維度也比較多。比如一個指標可能有 max、min 等不同的統(tǒng)計方式，監(jiān)控指標的數(shù)量就會比較多。其次，用戶能力有限，很難每日查看監(jiān)控告警。
-
異常原因：發(fā)生異常的原因一般會是技術性問題。如發(fā)布新版本上線時可能存在的 bug 導致業(yè)務出現(xiàn)下跌。少數(shù)的情況是由于外部因素的影響，比如調用外部鏈接或者服務，外部服務宕掉導致自己的服務出現(xiàn)問題。
-
解決方案：用戶為 Prophet 提供的檢測結果進行標注，選擇檢測結果的正確性。用戶的標注數(shù)據(jù)會用到 Prophet 以后的模型訓練中用于優(yōu)化數(shù)據(jù)集。
?
?
?
?
9.節(jié)假日場景
?
由于攜程做旅游方向的業(yè)務，節(jié)假日期間問題較為突出。不同類型的業(yè)務在節(jié)假日的表現(xiàn)是不同的。
?
-
例如攜程的機票、火車票基本是在節(jié)前上升到一定量，到假期期間由于人們出游，該買的票已經(jīng)購買完成，機票等業(yè)務訂單量會下降很多。
-
而酒店等業(yè)務在節(jié)假期間會上升很多。不同類型業(yè)務的趨勢不同，上升幅度較大的業(yè)務容易產(chǎn)生漏報，對于下跌幅度較大的業(yè)務，容易產(chǎn)生誤報。
?
?
節(jié)假日應對手段：不同的場景會導致不同的問題，所以 Prophet 針對節(jié)假日場景做了一些特殊處理。
?
-
首先，維護每年節(jié)假日信息表，程序一旦發(fā)現(xiàn)下一個節(jié)假日還有一個星期時，Prophet 就會提取出過去兩年內的不同節(jié)假日期間的數(shù)據(jù)。
-
其次，計算前兩年的不同節(jié)假日和當前節(jié)假日數(shù)值的相似度來匹配。相當于以當前節(jié)假日的數(shù)據(jù)擬合過去節(jié)假日的數(shù)據(jù)，擬合到某個時間段時，就知道大概從某個時間開始到某個時間結束是和當前趨勢類似的。
-
然后，會用過去多個節(jié)假日的數(shù)據(jù)作為一個組合作為新模型的數(shù)據(jù)輸入去訓練數(shù)據(jù)集。不同節(jié)假日的占比不同，通過一些方式計算出不同占比值。
-
最終，基于組合的數(shù)據(jù)集訓練出新的模型，新的模型可以比較好地預測出某一個指標或者某一個業(yè)務在節(jié)假期七天之內的趨勢。
?
?
?
10.平臺現(xiàn)狀
?
Prophet 基本覆蓋了攜程所有業(yè)務線。即攜程的重要業(yè)務指標基本都已經(jīng)在使用監(jiān)控智能告警。業(yè)務類型包含 7 種。監(jiān)控指標的數(shù)量達到 10K+，覆蓋了攜程所有訂單、支付等重要的業(yè)務指標，覆蓋了大部分服務的重要的業(yè)務指標。接入平臺在 10+ 左右，基本接入了攜程公司所有系統(tǒng)級別的監(jiān)控平臺，在陸續(xù)接入各個業(yè)務部門自己的監(jiān)控平臺。
?
Prophet 平臺能夠覆蓋 95% 左右的異常，準確報警率達到 75%。因為每個數(shù)據(jù)同步到 Prophet 便觸發(fā)數(shù)據(jù)實時消費、預測以及告警，告警延遲達到 ms 級別。告警數(shù)量也下降了十倍左右。
?
?
?
?
四、挑戰(zhàn)與展望
?
?
1.挑戰(zhàn)
?
-
資源消耗大：如果采用 LSTM 模型，需要為每個指標訓練模型，單個 Flink 作業(yè)里面都加載了約 4K~5K 的模型，無論訓練資源還是實時處理資源消耗都相對較大。
-
節(jié)假日影響：由于在業(yè)務指標在不同節(jié)假日的趨勢不同，告警準確性受到一定程度的影響。
-
智能告警無法適用于全部場景：有些機器的 CPU 的使用率可以直接設定閾值，達到 95% 時告警，非常方便簡單。但是如果用智能告警的方式擬合其趨勢，意義不大。另外節(jié)假日大促時，會發(fā)放門票、酒店優(yōu)惠券等活動，其訂單量可能快速增長 10 倍到 100 倍。這種突發(fā)的快速增長在歷史數(shù)據(jù)也很難學習到。上述場景的數(shù)據(jù)智能告警比較難處理。
?
?
?
2.展望
?
針對上述問題，Prophet 正陸續(xù)進行改進，希望通過下面幾種方式解決遇到的挑戰(zhàn)。通用模型迫在眉睫：Prophet 目前訓練了一個 DNN 模型，可以處理所有監(jiān)控指標。DNN 模型的準確率可能相較于 LSTM 模型會低一點，但能夠涵蓋較多場景。所以針對訂單、支付等重要的業(yè)務指標，可以使用 LSTM 算法模型，保證準確性，但對于相對不太重要的業(yè)務指標，可以使用 DNN 通用模型。
-
節(jié)假日算法上線：Prophet 節(jié)假日算法已經(jīng)在線上驗證半年，基本可以保證其準確性。
-
覆蓋攜程全部監(jiān)控平臺：Prophet 已經(jīng)覆蓋了攜程 70%~80% 的監(jiān)控平臺。大部分業(yè)務指標是在公司的系統(tǒng)監(jiān)控級別，所以只要能覆蓋公司級別的監(jiān)控系統(tǒng)，就可以覆蓋大部分重要的業(yè)務指標。后續(xù)，Prophet 也將陸續(xù)接入更多業(yè)務部門的監(jiān)控平臺。
?
?
作者介紹：
潘國慶，攜程大數(shù)據(jù)研發(fā)經(jīng)理。2016 年加入攜程大數(shù)據(jù)平臺團隊，主導了 Muise 平臺從 Storm 至 Spark Streaming 再到 Flink 的架構升級與技術演進，目前負責攜程實時智能異常檢測的架構設計與研發(fā)。擁有 5 年大數(shù)據(jù)領域研發(fā)經(jīng)驗，擁有于實時計算的研究與推廣。
總結
以上是生活随笔為你收集整理的监控指标10K+！携程实时智能检测平台实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 京东JDHBase异地多活实践
- 下一篇： springboot配置定时任务及常用的