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

本次分享主要分為四個(gè)方面：

一.背景介紹

二.Prophet

三.智能化與實(shí)時(shí)化

四.挑戰(zhàn)與展望

?

一、背景介紹

?

1.規(guī)則告警帶來的問題

?

大部分監(jiān)控平臺是基于規(guī)則告警實(shí)現(xiàn)監(jiān)控指標(biāo)的預(yù)警。規(guī)則告警一般基于統(tǒng)計(jì)學(xué)，如某個(gè)指標(biāo)同比、環(huán)比連續(xù)上升或下降到一定閾值進(jìn)行告警。規(guī)則告警需要用戶較為熟悉業(yè)務(wù)指標(biāo)的形態(tài)，從而較為準(zhǔn)確的配置告警閾值，這樣帶來的問題是配置規(guī)則告警非常繁瑣、告警效果也比較差，需要大量人力物力來維護(hù)規(guī)則告警。

?

當(dāng)一個(gè)告警產(chǎn)生時(shí)，也需要耗費(fèi)許多人力驗(yàn)證告警是否正確并確認(rèn)是否需要重新調(diào)整閾值。在攜程，規(guī)則告警還涉及了其它問題，比如攜程僅公司級別的監(jiān)控平臺就有三個(gè)，每個(gè)業(yè)務(wù)部門還會根據(jù)自己的業(yè)務(wù)需求或業(yè)務(wù)場景構(gòu)建自己的監(jiān)控平臺。攜程內(nèi)部有十幾個(gè)不同規(guī)模的監(jiān)控平臺，在每一個(gè)監(jiān)控平臺都配置監(jiān)控指標(biāo)，對于用戶是非常繁瑣的。

?

?

?

?

二、Prophet

?

針對規(guī)則告警存在的以上幾種問題，攜程構(gòu)建了自己的實(shí)時(shí)智能異常檢測平臺—— Prophet。攜程構(gòu)建 Prophet 的靈感源于 FaceBook 的 Prophet，但實(shí)現(xiàn)上有別于 FaceBook 的 Prophet。

?

1.一站式異常檢測解決方案

?

首先，Prophet 以時(shí)間序列類型的數(shù)據(jù)作為數(shù)據(jù)輸入。其次，Prophet 以監(jiān)控平臺作為接入對象，以去規(guī)則化為目標(biāo)。基于深度學(xué)習(xí)算法實(shí)現(xiàn)異常的智能檢測，基于實(shí)時(shí)計(jì)算引擎實(shí)現(xiàn)異常的實(shí)時(shí)檢測，提供了統(tǒng)一的異常檢測解決方案。

?

?

2.Prophet 系統(tǒng)架構(gòu)

?

• 底層：Hadoop 底層。YARN 作為統(tǒng)一資源調(diào)度引擎，主要用于運(yùn)行 Flink 的作業(yè)。HDFS 主要用于存儲訓(xùn)練好的 TensorFlow 模型。

• 引擎層：首先數(shù)據(jù)必須實(shí)時(shí)存在于消息隊(duì)列當(dāng)中，Prophet 使用的是 Kafka。此外，Prophet 使用 Flink 計(jì)算引擎實(shí)現(xiàn)實(shí)時(shí)異常預(yù)警，使用 TensorFlow 作為深度學(xué)習(xí)模型的訓(xùn)練引擎。同時(shí) Prophet 基于時(shí)序數(shù)據(jù)庫存儲歷史數(shù)據(jù)。

• 平臺層：最上層是對外提供服務(wù)的平臺層 Prophet。Clog 用于采集作業(yè)日志。Muise 是實(shí)時(shí)計(jì)算平臺。Qconfig 用于存儲作業(yè)中需要用到的配置項(xiàng)。Hickwall 用于作業(yè)的監(jiān)控告警。

?

3.Why Flink？

?

目前主流的實(shí)時(shí)計(jì)算引擎有 Flink、Storm 和 SparkStreaming 等多種，攜程選擇Flink 作為 Prophet 平臺的實(shí)時(shí)計(jì)算引擎的原因主要是Flink具備以下四點(diǎn)特征：

?

• 高效的狀態(tài)管理：異常檢測的過程中有許多狀態(tài)信息需要存儲。使用 Flink 自帶的 State Backend 可以很好地存儲中間狀態(tài)信息。

• 豐富的窗口支持：窗口包含滾動窗口、滑動窗口以及其他窗口。Prophet 基于滑動窗口進(jìn)行數(shù)據(jù)處理。

• 支持多種時(shí)間語義：Prophet 基于 Event Time。

• 支持不同級別的容錯(cuò)語義：Prophet 至少需要做到 At Least Once 或 Exactly Once 的級別。

?

?

4.Prophet?操作流程

?

用戶只需要在自己常用的監(jiān)控平臺上選擇配置智能告警，后續(xù)所有流程都是由監(jiān)控平臺和 Prophet 智能告警平臺對接完成。監(jiān)控平臺所需要做的包含兩件事：

?

• 首先將用戶配置的監(jiān)控指標(biāo)同步到 Prophet 平臺；?

• 其次監(jiān)控平臺需將用戶配置的監(jiān)控指標(biāo)數(shù)據(jù)實(shí)時(shí)的推送到 Kafka 消息隊(duì)列中。

?

?

Prophet 在接受到新的監(jiān)控指標(biāo)后，便開始嘗試使用 Tensorflow 訓(xùn)練模型。模型訓(xùn)練需要?dú)v史數(shù)據(jù)，平臺可以按照約定好的規(guī)范提供歷史數(shù)據(jù)查詢接口，Prophet 通過接口獲取歷史數(shù)據(jù)并進(jìn)行模型訓(xùn)練、如果沒有接口，Prophet 基于消息隊(duì)列中的數(shù)據(jù)來積累訓(xùn)練數(shù)據(jù)集。模型訓(xùn)練完成后，將其上傳到 HDFS，Prophet 會更新配置中心中的配置通知 Flink 有新訓(xùn)練好的模型可以加載。所有實(shí)時(shí)推送到 Kafka 里面的監(jiān)控指標(biāo)的數(shù)值，會同步的落到 Prophet 的時(shí)序數(shù)據(jù)庫中，在異常檢測的過程中需要用到這些指標(biāo)數(shù)值。

?

當(dāng)模型訓(xùn)練完成后，Flink 的作業(yè)一旦監(jiān)聽到配置發(fā)生了更新，就開始嘗試加載新模型，實(shí)時(shí)消費(fèi) Kafka 里面的指標(biāo)數(shù)據(jù)，最終產(chǎn)出檢測結(jié)果以及異常告警會回寫至 Kafka，各個(gè)監(jiān)控平臺會從 Kafka 獲取自己監(jiān)控平臺的那一部分告警數(shù)據(jù)。整套 Prophet 操作流程對于用戶是無感知的，用戶只需要配置告警，極大的提供了便捷性。

?

?

三、智能化與實(shí)時(shí)化

?

1.智能化挑戰(zhàn)

?

在做智能檢測之前還會遇到一些挑戰(zhàn)。

?

• 負(fù)樣本少：生產(chǎn)環(huán)境中發(fā)生異常的概率比較小。攜程在很多年的時(shí)間僅積累了大概幾千條負(fù)樣本數(shù)據(jù)。

• 業(yè)務(wù)指標(biāo)類型多：業(yè)務(wù)指標(biāo)類型繁多，有訂單、支付等業(yè)務(wù)類型的指標(biāo)，也有服務(wù)類型的指標(biāo)，如請求數(shù)、響應(yīng)延時(shí)等，以及硬件設(shè)施類型的指標(biāo)，如 CPU、內(nèi)存、硬盤等各種指標(biāo)。

• 業(yè)務(wù)指標(biāo)形態(tài)多：正因?yàn)橛胁煌愋偷臉I(yè)務(wù)指標(biāo)，業(yè)務(wù)指標(biāo)的形態(tài)也各不相同。攜程將業(yè)務(wù)指標(biāo)形態(tài)歸納為三部分。一是周期波動相對平穩(wěn)的指標(biāo)，第二是穩(wěn)定的，不會劇烈波動的指標(biāo)，第三是上下波動幅度非常劇烈、呈現(xiàn)不穩(wěn)定的形態(tài)的指標(biāo)。

?

?

2.深度學(xué)習(xí)算法選擇

?

針對以上三點(diǎn)問題，攜程嘗試了 RNN，LSTM 和 DNN 等多種深度學(xué)習(xí)算法。

?

• RNN：RNN 的優(yōu)點(diǎn)是適合時(shí)間序列類型的數(shù)據(jù)，而缺點(diǎn)是存在梯度消失問題。

• LSTM 模型：LSTM 的優(yōu)點(diǎn)是解決了梯度消失的問題。RNN 和 LSTM 深度學(xué)習(xí)算法需要先給每個(gè)指標(biāo)訓(xùn)練一個(gè)模型，然后輸入當(dāng)前的數(shù)據(jù)集，基于模型來預(yù)測當(dāng)前數(shù)據(jù)集的走向。然后再比對預(yù)測數(shù)據(jù)集和當(dāng)前數(shù)據(jù)集進(jìn)行異常檢測。這種方式帶來的好處是檢測精度高，但是單指標(biāo)單模型也帶來更多的資源消耗。

• DNN：DNN 的優(yōu)點(diǎn)是單個(gè)模型能夠覆蓋所有異常檢測的場景。但是特征提取會非常復(fù)雜，需要提取不同頻域的特征，需要大量用戶標(biāo)注數(shù)據(jù)。

?

3.離線模型訓(xùn)練

?

攜程一般兩周發(fā)一次版本，每個(gè)業(yè)務(wù)指標(biāo)都是每兩周嘗試訓(xùn)練一次，模型輸入的訓(xùn)練數(shù)據(jù)也取兩周的數(shù)據(jù)集。

?

• 在使用歷史數(shù)據(jù)之前需要做數(shù)據(jù)預(yù)處理，比如歷史數(shù)據(jù)中可能存在 null 值，需要使用均值標(biāo)準(zhǔn)差將其補(bǔ)齊。

• 其次，歷史數(shù)據(jù)區(qū)間里面肯定會有一些異常區(qū)間，需要用一些預(yù)測值替換異常區(qū)間的異常值。

• 另外，由于節(jié)假日期間數(shù)據(jù)較為復(fù)雜，需要替換節(jié)假日期間的異常值。對歷史數(shù)據(jù)的數(shù)據(jù)集做數(shù)據(jù)預(yù)處理之后，開始提取其不同時(shí)序的特征或者頻率的特征。

• 然后，通過一個(gè)分類模型分類出指標(biāo)是平穩(wěn)的、非周期的還是周期型的。不同類型的指標(biāo)需要不同的模型進(jìn)行訓(xùn)練。

?

?

4.模型動態(tài)加載

?

模型訓(xùn)練完成后，Flink 作業(yè)需要動態(tài)加載模型。但實(shí)際場景下，不可能每訓(xùn)練一個(gè)模型便重啟一次 Flink 作業(yè)。所以 Prophet 平臺將模型訓(xùn)練完成后上傳到 HDFS，通知配置中心，然后 Flink 作業(yè)開始從 HDFS 上拉取模型。為了使每個(gè)模型均勻分布在不同的 Task Manager 上面，所有監(jiān)控指標(biāo)會根據(jù)本身 id 做 keyBy，均勻分布在不同的 Task Manager 上。每個(gè) Task Manager 只加載自己部分的模型，以此降低資源消耗。

?

?

5.數(shù)據(jù)實(shí)時(shí)消費(fèi)與預(yù)測

?

模型加載完成后需要做實(shí)時(shí)異常檢測。首先從 Kafka 消息隊(duì)列中消費(fèi)實(shí)時(shí)數(shù)據(jù)。Prophet 目前基于 Flink Event Time + 滑動窗口。監(jiān)控指標(biāo)的時(shí)間粒度可以分為很多種，如 1 分鐘一個(gè)點(diǎn)、5 分鐘一個(gè)點(diǎn)、10 分鐘一個(gè)點(diǎn)等等。例如基于 1 分鐘一個(gè)點(diǎn)的場景來看，在 Flink 作業(yè)中開一個(gè)窗口，其長度是十個(gè)時(shí)間粒度，即十分鐘。當(dāng)積累到十條數(shù)據(jù)時(shí)，用前五個(gè)數(shù)據(jù)預(yù)測下一個(gè)數(shù)據(jù)，即通過第 1、2、3、4、5 五個(gè)時(shí)刻的數(shù)據(jù)去預(yù)測第六個(gè)時(shí)刻的數(shù)據(jù)，然后用第 2、3、4、5、6 時(shí)刻的數(shù)據(jù)預(yù)測第七個(gè)時(shí)刻的數(shù)據(jù)。最終獲得第 6、7、8、9、10 五個(gè)時(shí)刻的預(yù)測值和實(shí)際值。再利用預(yù)測值與實(shí)際值進(jìn)行對比。以上是數(shù)據(jù)無異常的理想場景下的情況。

?

?

6.數(shù)據(jù)插補(bǔ)與替換

?

實(shí)際場景下往往會出現(xiàn)意想不到的情況。例如上述 10 分鐘的場景中只獲得了 9 條數(shù)據(jù)，缺少第4個(gè)時(shí)刻的數(shù)據(jù)， Prophet 會使用均值標(biāo)準(zhǔn)差補(bǔ)齊此類缺失數(shù)據(jù)。另外如果在上一個(gè)時(shí)刻檢測到第 6、7、8、9、10 時(shí)間區(qū)間是異常區(qū)間，發(fā)生了下跌或者上升。那么此區(qū)間的數(shù)據(jù)被認(rèn)為是不正常的，不能作為模型輸入。此時(shí)需要用上一批次模型預(yù)測出的第 6 時(shí)刻的值替換原始的第六個(gè)時(shí)間粒度的值。第 2、3、4、5、6 這五個(gè)時(shí)刻值中第 4 是插補(bǔ)而來的，第 6 是時(shí)間區(qū)間訓(xùn)練出來的預(yù)測值替換掉了異常值。

?

以插補(bǔ)替換之后的值作為模型輸入，得到新的預(yù)測值7。再依次進(jìn)行預(yù)測。中間過程中異常區(qū)間第 6、7、8、9、10 時(shí)刻的預(yù)測值需要作為一個(gè)狀態(tài)來存儲到 Flink StateBackend，后續(xù)窗口會使用到這些預(yù)測值。

?

?

7.實(shí)時(shí)異常檢測

?

實(shí)時(shí)異常檢測主要可以從以下幾個(gè)方面進(jìn)行判斷：

?

• 基于異常類型與敏感度判斷：不同的指標(biāo)存在不同的異常類型，如上升異常，下跌異常。其次，不同指標(biāo)敏感度不同，可以定義其為高敏感度、中敏感度、低敏感度。當(dāng)高敏感度指標(biāo)發(fā)生簡單的下降抖動時(shí)，認(rèn)為是下跌異常。中敏感度指標(biāo)可能連續(xù)下跌兩個(gè)點(diǎn)時(shí)會判斷異常。對于低敏感度指標(biāo)，當(dāng)下跌幅度較大時(shí)才會判斷為異常。

• 基于預(yù)測集與實(shí)際集的偏差判斷：如果預(yù)測結(jié)果和實(shí)際結(jié)果偏差較大，認(rèn)定當(dāng)前第 6、7、8、9、10 時(shí)刻區(qū)間是潛在的異常區(qū)間。

• 基于歷史同期數(shù)據(jù)均值與標(biāo)準(zhǔn)差判斷：同時(shí)需要與上周同期的時(shí)間進(jìn)行對比，同一區(qū)間的數(shù)值偏差較大，則判斷為異常。當(dāng)異常樣本較多時(shí)，可以用簡單的機(jī)器學(xué)習(xí)分類模型通過預(yù)測值和實(shí)際值做異常判斷。

?

?

8.常見場景

?

• 常見問題：對于用戶來說，監(jiān)控指標(biāo)太多，監(jiān)控的維度也比較多。比如一個(gè)指標(biāo)可能有 max、min 等不同的統(tǒng)計(jì)方式，監(jiān)控指標(biāo)的數(shù)量就會比較多。其次，用戶能力有限，很難每日查看監(jiān)控告警。

• 異常原因：發(fā)生異常的原因一般會是技術(shù)性問題。如發(fā)布新版本上線時(shí)可能存在的 bug 導(dǎo)致業(yè)務(wù)出現(xiàn)下跌。少數(shù)的情況是由于外部因素的影響，比如調(diào)用外部鏈接或者服務(wù)，外部服務(wù)宕掉導(dǎo)致自己的服務(wù)出現(xiàn)問題。

• 解決方案：用戶為 Prophet 提供的檢測結(jié)果進(jìn)行標(biāo)注，選擇檢測結(jié)果的正確性。用戶的標(biāo)注數(shù)據(jù)會用到 Prophet 以后的模型訓(xùn)練中用于優(yōu)化數(shù)據(jù)集。

?

?

?

?

9.節(jié)假日場景

?

由于攜程做旅游方向的業(yè)務(wù)，節(jié)假日期間問題較為突出。不同類型的業(yè)務(wù)在節(jié)假日的表現(xiàn)是不同的。

?

• 例如攜程的機(jī)票、火車票基本是在節(jié)前上升到一定量，到假期期間由于人們出游，該買的票已經(jīng)購買完成，機(jī)票等業(yè)務(wù)訂單量會下降很多。

• 而酒店等業(yè)務(wù)在節(jié)假期間會上升很多。不同類型業(yè)務(wù)的趨勢不同，上升幅度較大的業(yè)務(wù)容易產(chǎn)生漏報(bào)，對于下跌幅度較大的業(yè)務(wù)，容易產(chǎn)生誤報(bào)。

?

?

節(jié)假日應(yīng)對手段：不同的場景會導(dǎo)致不同的問題，所以 Prophet 針對節(jié)假日場景做了一些特殊處理。

?

• 首先，維護(hù)每年節(jié)假日信息表，程序一旦發(fā)現(xiàn)下一個(gè)節(jié)假日還有一個(gè)星期時(shí)，Prophet 就會提取出過去兩年內(nèi)的不同節(jié)假日期間的數(shù)據(jù)。

• 其次，計(jì)算前兩年的不同節(jié)假日和當(dāng)前節(jié)假日數(shù)值的相似度來匹配。相當(dāng)于以當(dāng)前節(jié)假日的數(shù)據(jù)擬合過去節(jié)假日的數(shù)據(jù)，擬合到某個(gè)時(shí)間段時(shí)，就知道大概從某個(gè)時(shí)間開始到某個(gè)時(shí)間結(jié)束是和當(dāng)前趨勢類似的。

• 然后，會用過去多個(gè)節(jié)假日的數(shù)據(jù)作為一個(gè)組合作為新模型的數(shù)據(jù)輸入去訓(xùn)練數(shù)據(jù)集。不同節(jié)假日的占比不同，通過一些方式計(jì)算出不同占比值。

• 最終，基于組合的數(shù)據(jù)集訓(xùn)練出新的模型，新的模型可以比較好地預(yù)測出某一個(gè)指標(biāo)或者某一個(gè)業(yè)務(wù)在節(jié)假期七天之內(nèi)的趨勢。

?

?

?

10.平臺現(xiàn)狀

?

Prophet 基本覆蓋了攜程所有業(yè)務(wù)線。即攜程的重要業(yè)務(wù)指標(biāo)基本都已經(jīng)在使用監(jiān)控智能告警。業(yè)務(wù)類型包含 7 種。監(jiān)控指標(biāo)的數(shù)量達(dá)到 10K+，覆蓋了攜程所有訂單、支付等重要的業(yè)務(wù)指標(biāo)，覆蓋了大部分服務(wù)的重要的業(yè)務(wù)指標(biāo)。接入平臺在 10+ 左右，基本接入了攜程公司所有系統(tǒng)級別的監(jiān)控平臺，在陸續(xù)接入各個(gè)業(yè)務(wù)部門自己的監(jiān)控平臺。

?

Prophet 平臺能夠覆蓋 95% 左右的異常，準(zhǔn)確報(bào)警率達(dá)到 75%。因?yàn)槊總€(gè)數(shù)據(jù)同步到 Prophet 便觸發(fā)數(shù)據(jù)實(shí)時(shí)消費(fèi)、預(yù)測以及告警，告警延遲達(dá)到 ms 級別。告警數(shù)量也下降了十倍左右。

?

?

?

?

四、挑戰(zhàn)與展望

?

?

1.挑戰(zhàn)

?

• 資源消耗大：如果采用 LSTM 模型，需要為每個(gè)指標(biāo)訓(xùn)練模型，單個(gè) Flink 作業(yè)里面都加載了約 4K~5K 的模型，無論訓(xùn)練資源還是實(shí)時(shí)處理資源消耗都相對較大。

• 節(jié)假日影響：由于在業(yè)務(wù)指標(biāo)在不同節(jié)假日的趨勢不同，告警準(zhǔn)確性受到一定程度的影響。

• 智能告警無法適用于全部場景：有些機(jī)器的 CPU 的使用率可以直接設(shè)定閾值，達(dá)到 95% 時(shí)告警，非常方便簡單。但是如果用智能告警的方式擬合其趨勢，意義不大。另外節(jié)假日大促時(shí)，會發(fā)放門票、酒店優(yōu)惠券等活動，其訂單量可能快速增長 10 倍到 100 倍。這種突發(fā)的快速增長在歷史數(shù)據(jù)也很難學(xué)習(xí)到。上述場景的數(shù)據(jù)智能告警比較難處理。

?

?

?

2.展望

?

針對上述問題，Prophet 正陸續(xù)進(jìn)行改進(jìn)，希望通過下面幾種方式解決遇到的挑戰(zhàn)。通用模型迫在眉睫：Prophet 目前訓(xùn)練了一個(gè) DNN 模型，可以處理所有監(jiān)控指標(biāo)。DNN 模型的準(zhǔn)確率可能相較于 LSTM 模型會低一點(diǎn)，但能夠涵蓋較多場景。所以針對訂單、支付等重要的業(yè)務(wù)指標(biāo)，可以使用 LSTM 算法模型，保證準(zhǔn)確性，但對于相對不太重要的業(yè)務(wù)指標(biāo)，可以使用 DNN 通用模型。

• 節(jié)假日算法上線：Prophet 節(jié)假日算法已經(jīng)在線上驗(yàn)證半年，基本可以保證其準(zhǔn)確性。

• 覆蓋攜程全部監(jiān)控平臺：Prophet 已經(jīng)覆蓋了攜程 70%~80% 的監(jiān)控平臺。大部分業(yè)務(wù)指標(biāo)是在公司的系統(tǒng)監(jiān)控級別，所以只要能覆蓋公司級別的監(jiān)控系統(tǒng)，就可以覆蓋大部分重要的業(yè)務(wù)指標(biāo)。后續(xù)，Prophet 也將陸續(xù)接入更多業(yè)務(wù)部門的監(jiān)控平臺。

?

?

作者介紹：

潘國慶，攜程大數(shù)據(jù)研發(fā)經(jīng)理。2016 年加入攜程大數(shù)據(jù)平臺團(tuán)隊(duì)，主導(dǎo)了 Muise 平臺從 Storm 至 Spark Streaming 再到 Flink 的架構(gòu)升級與技術(shù)演進(jìn)，目前負(fù)責(zé)攜程實(shí)時(shí)智能異常檢測的架構(gòu)設(shè)計(jì)與研發(fā)。擁有 5 年大數(shù)據(jù)領(lǐng)域研發(fā)經(jīng)驗(yàn)，擁有于實(shí)時(shí)計(jì)算的研究與推廣。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。