程學(xué)林，鄭佳卉，蔣爍淼，貝毅君

1(浙江大學(xué) 軟件學(xué)院，杭州 310027) 2(上海駐云信息科技有限公司，上海 200120)

1 引 言

近幾年來，企業(yè)的IT架構(gòu)漸漸地從物理服務(wù)器遷到由云服務(wù)器構(gòu)成的IaaS(Infrastructure as a Service)云.云計(jì)算這種高效的新型資源共享模式，其核心是云服務(wù)供應(yīng)商借助網(wǎng)絡(luò)向客戶提供包含計(jì)算、數(shù)據(jù)存儲、網(wǎng)絡(luò)、軟件等計(jì)算資源.在大多數(shù)企業(yè)中，應(yīng)用程序部署在云服務(wù)器上，并選擇云資源服務(wù)來作為底層的軟硬件支撐.

《Flexera 2020年云狀態(tài)報(bào)告》1收集了全球云計(jì)算相關(guān)調(diào)查數(shù)據(jù)，從企業(yè)云策略調(diào)查數(shù)據(jù)中可知幾乎所有的受訪企業(yè)均選用了多云且大多數(shù)企業(yè)使用混合云策略，但所有參與調(diào)查的企業(yè)或組織中只有33%使用多云管理工具，而多云管理的基礎(chǔ)是多云監(jiān)測.在快速發(fā)展的公共云、私有云和混合云市場中，云資源在運(yùn)行過程中每時(shí)每刻都能產(chǎn)生帶有時(shí)間維度的時(shí)序數(shù)據(jù)，數(shù)據(jù)總的體量十分龐大.多云環(huán)境下監(jiān)測的任務(wù)是，對采集到的原始海量時(shí)序監(jiān)測數(shù)據(jù)進(jìn)行預(yù)處理并存儲用于實(shí)時(shí)展示；或使用預(yù)處理后的數(shù)據(jù)來實(shí)時(shí)分析判斷云資源的運(yùn)行狀態(tài)(正常/異常)，從而能夠及時(shí)通知運(yùn)維人員[1].

當(dāng)前全球云資源市場生態(tài)已基本成型，各大云服務(wù)供應(yīng)商向客戶提供有償?shù)脑瀑Y源的同時(shí)，也向客戶提供了內(nèi)嵌于各自云平臺中的監(jiān)測工具供客戶來查看所購買資源的運(yùn)行狀況，然而這些自帶的監(jiān)測與分析服務(wù)，基本止步于單云資源運(yùn)行數(shù)據(jù)的實(shí)時(shí)展示，對云資源運(yùn)行狀態(tài)的告警也僅僅采用基于固定閾值的簡易方式[1].

圖1 網(wǎng)絡(luò)流量Fig.1 Network traffic

在云資源實(shí)際運(yùn)行過程中，這種基于用戶主觀經(jīng)驗(yàn)的閾值設(shè)定機(jī)制脫離了動態(tài)變化的現(xiàn)實(shí)環(huán)境，易產(chǎn)生異常的遲報(bào)、漏報(bào)或誤報(bào).況且許多異常并不是空間(數(shù)值)上的異常而是時(shí)間維度上的異常，如圖 1所示，這是企業(yè)某臺ECS上網(wǎng)絡(luò)流量的時(shí)間線圖，圓點(diǎn)處標(biāo)明異常發(fā)生點(diǎn)，此處網(wǎng)絡(luò)流量開始持續(xù)處于高位，即便設(shè)置了閾值也無法判斷是否發(fā)生了異常.除此之外，監(jiān)測數(shù)據(jù)可能會發(fā)生概念漂移(Concept Drift)[2]，如圖 2所示，CPU使用率的時(shí)間線圖中兩點(diǎn)標(biāo)注處才是異常發(fā)生時(shí)刻，但軟件的運(yùn)行導(dǎo)致CPU使用率整體升高，后又因?yàn)檐浖\(yùn)行結(jié)束導(dǎo)致CPU使用率下降，這兩種運(yùn)行狀態(tài)都是正常模式，在這種情況下模型必須通過連續(xù)在線學(xué)習(xí)[3]適應(yīng)新的正常模式.

圖2 CPU利用率Fig.2 CPU used percent

除了異常檢測方面存在缺陷外，內(nèi)嵌于各云服務(wù)提供商提供的云平臺之中所造成的數(shù)據(jù)隔離也是個(gè)不小的問題，在當(dāng)前企業(yè)普遍選擇多云策略的背景下，IT運(yùn)維人員需要分別登陸各云平臺的管理后臺查看資源運(yùn)行情況或是設(shè)置告警規(guī)則顯然增加了運(yùn)維成本，無法以企業(yè)為單位的視圖進(jìn)行綜合分析.

針對上述問題，本文提出了一種基于時(shí)序數(shù)據(jù)的企業(yè)多云實(shí)時(shí)監(jiān)測方案MCloudMonitor，圍繞多云資源運(yùn)行產(chǎn)生的海量時(shí)序數(shù)據(jù)提供可靠的存儲和處理服務(wù)，基于在線學(xué)習(xí)和模式記憶的方式來動態(tài)分析時(shí)序數(shù)據(jù)從而進(jìn)行異常檢測，而不是簡單根據(jù)靜態(tài)閾值來判斷是否產(chǎn)生異常.除此之外，本文基于該方案借助時(shí)序數(shù)據(jù)存儲、流處理等關(guān)鍵技術(shù)進(jìn)行實(shí)現(xiàn)和測試評估，證明該方案能有效幫助企業(yè)運(yùn)維人員對多云平臺資源海量時(shí)序數(shù)據(jù)進(jìn)行實(shí)時(shí)、便捷地處理、展示和分析，從而驅(qū)動企業(yè)做出綜合決策，準(zhǔn)確發(fā)現(xiàn)異常，提升企業(yè)的運(yùn)維效率，降低運(yùn)維成本.

2 相關(guān)工作

2.1 數(shù)據(jù)采集技術(shù)

單一云環(huán)境監(jiān)測只需專注于單一云平臺或云資源，不必費(fèi)心數(shù)據(jù)的采集和傳輸，但它以數(shù)據(jù)匯總成本為代價(jià)，自動匯總的能力幾乎為零，往往需要用戶手動操作；而多云環(huán)境正好與之相反，因此在數(shù)據(jù)采集和傳輸上需要設(shè)計(jì)合適的解決方案降低復(fù)雜度.許多云平臺都有提供特定的接口用于獲取該平臺資源的監(jiān)測數(shù)據(jù)，但主要存在兩大問題：

1)平臺提供的接口限制了數(shù)據(jù)的采集范圍.

2)每個(gè)平臺都有不同的接口要求，不僅在實(shí)現(xiàn)過程中需要對每個(gè)接口進(jìn)行特殊處理增加系統(tǒng)實(shí)現(xiàn)的工作量，還使得監(jiān)測系統(tǒng)強(qiáng)依賴于云平臺、失去云中立性：當(dāng)增加新的云平臺監(jiān)測需求時(shí)，開發(fā)者必須修改系統(tǒng)實(shí)現(xiàn).因此會導(dǎo)致系統(tǒng)的適用性和擴(kuò)展能力較差.

綜上所述，單純通過接口獲取多云平臺資源運(yùn)行數(shù)據(jù)的方式存在一定局限性，數(shù)據(jù)采集的靈活度較低，相應(yīng)地提供給用戶的自定義采集能力就較差.

本文借助了專用于采集時(shí)序數(shù)據(jù)的采集探針Telegraf2來解決多云平臺監(jiān)測數(shù)據(jù)獲取的問題，大大降低了系統(tǒng)實(shí)現(xiàn)的復(fù)雜性，提高了可操作性.采集探針運(yùn)行在各個(gè)云平臺的被監(jiān)測端，Telegraf擁有內(nèi)存占用小的優(yōu)點(diǎn)，已經(jīng)集成了很多Input插件，它可以直接從其運(yùn)行的系統(tǒng)中提取各種指標(biāo)，它還具有多種Output插件，能夠?qū)⒉杉降臄?shù)據(jù)發(fā)送至各種數(shù)據(jù)相關(guān)系統(tǒng)，如InfluxDB和Kafka.

2.2 時(shí)序數(shù)據(jù)存儲技術(shù)

時(shí)間序列數(shù)據(jù)在現(xiàn)代社會中有著非常重要的作用[4-10]，數(shù)據(jù)獲取與分析的實(shí)時(shí)程度往往同其背后所蘊(yùn)含的巨大價(jià)值掛鉤，并衍生出了存儲和處理海量時(shí)序數(shù)據(jù)的需求.

時(shí)序數(shù)據(jù)的數(shù)據(jù)量大，表示數(shù)據(jù)源在某個(gè)時(shí)間點(diǎn)的的某些特征，數(shù)據(jù)寫入的頻率極高，已存儲的數(shù)據(jù)幾乎不需要更新.上述特征使得時(shí)間序列數(shù)據(jù)處理與常規(guī)數(shù)據(jù)庫的數(shù)據(jù)處理在工作量上存在一定差異.其中最明顯的就是數(shù)據(jù)規(guī)模問題.傳統(tǒng)的關(guān)系型數(shù)據(jù)庫由于存儲成本大、維護(hù)成本高、寫入吞吐低、查詢性能差等缺點(diǎn)[11]，無法利用時(shí)序數(shù)據(jù)具有時(shí)間這個(gè)天然維度的特性進(jìn)行存儲與處理海量的時(shí)序數(shù)據(jù).在數(shù)據(jù)分析領(lǐng)域大展身手的數(shù)據(jù)倉庫也因?yàn)楦镜膶?shí)現(xiàn)原理上存在問題[12]而無法實(shí)時(shí)抽取數(shù)據(jù)用于實(shí)時(shí)分析.

時(shí)間序列數(shù)據(jù)庫(TSDB)應(yīng)運(yùn)而生，專用于應(yīng)對上述行業(yè)對時(shí)序數(shù)據(jù)的插入和查詢應(yīng)用場景.這類數(shù)據(jù)庫自帶時(shí)間戳維度的索引和優(yōu)化，針對時(shí)間維度有專門的存儲結(jié)構(gòu)，提高了對時(shí)序相關(guān)數(shù)據(jù)的讀寫分析效率[13].

2https：//www.influxdata.com/time-series-platform/telegraf/

現(xiàn)如今，主流的TSDB有TimescaleDB、OpenTSDB、KairosDB、InfluxDB3等.從劉等人的實(shí)驗(yàn)4中可以得出，InfluxDB的性能領(lǐng)先于其他時(shí)序數(shù)據(jù)庫，因?yàn)樗跀?shù)據(jù)攝取和大多數(shù)查詢工作負(fù)載中的性能都遠(yuǎn)遠(yuǎn)好于其他的時(shí)序數(shù)據(jù)庫.從楊婕的研究[14]中可以得出，開源的InfluxDB憑借其優(yōu)勢和版本迭代速度，在各種TSDB中脫穎而出，直到現(xiàn)在都是最受關(guān)注的時(shí)序數(shù)據(jù)庫.

2.3 流處理技術(shù)

對于一些時(shí)間要求比較高的應(yīng)用，必須有非常低的延時(shí)展示統(tǒng)計(jì)結(jié)果，隨著流式時(shí)間序列大數(shù)據(jù)處理的工作量不斷增加，數(shù)據(jù)處理框架將成為大數(shù)據(jù)集處理延遲的潛在性能瓶頸.從Wissem等人的調(diào)查[15]中，Hadoop和Spark等常用大數(shù)據(jù)工具在處理數(shù)據(jù)的實(shí)時(shí)性方面顯得力不從心.當(dāng)它們在進(jìn)行離線計(jì)算時(shí)，數(shù)據(jù)從獲取到分析，時(shí)間消耗會高達(dá)數(shù)小時(shí)，甚至幾天，高數(shù)據(jù)延遲是實(shí)時(shí)系統(tǒng)無法接受的.

為此Nathan Marz提出一套Lambda架構(gòu)方案[16]來處理不同類型的數(shù)據(jù)，采用批計(jì)算和流計(jì)算整合的方式，例如借助Hadoop進(jìn)行離線批處理，使用Apache Storm進(jìn)行實(shí)時(shí)流處理.這種架構(gòu)由于框架過多，造成分析系統(tǒng)復(fù)雜、運(yùn)維成本高昂等方面的問題，因此Lambda架構(gòu)還不是最完美的解決方案.

Apache Spark推出了基于Spark的 Spark Streaming.該流式計(jì)算框架將流數(shù)據(jù)切分成微批進(jìn)行流式數(shù)據(jù)處理，但由于其依舊基于批處理模式來處理離散化流(Discretized Stream)，因此不算完全意義上的流處理，也不能高效地處理原生數(shù)據(jù)流.

張利兵研究得出有狀態(tài)流計(jì)算會逐步成為企業(yè)數(shù)據(jù)架構(gòu)解決方案[17]，而目前從社區(qū)來看，能夠滿足的只有Apache Flink5.它是一個(gè)高吞吐、低時(shí)延、高性能的分布式流處理計(jì)算框架和引擎，通過用于對無界(沒有定義數(shù)據(jù)流的結(jié)束)和有界(定義了數(shù)據(jù)流的開始和結(jié)束)數(shù)據(jù)流進(jìn)行有狀態(tài)的計(jì)算，對于在流處理的支持上和低延遲上，F(xiàn)link更勝于Spark Streaming[18].

2.4 異常檢測算法

如何實(shí)現(xiàn)真正意義上的自動化實(shí)時(shí)異常檢測是實(shí)現(xiàn)一個(gè)優(yōu)秀的云資源監(jiān)測的主要難題，盡早地檢測出異常極具價(jià)值和意義，但在實(shí)踐中很難可靠地執(zhí)行.

洪斌[1]等人提出了幾種分別基于統(tǒng)計(jì)分析、數(shù)據(jù)分類、最近鄰分析等理論基礎(chǔ)的狀態(tài)監(jiān)測技術(shù)和基于概率分析、方程擬合、機(jī)器學(xué)習(xí)和事件感知等狀態(tài)預(yù)測技術(shù)，并給出了它們的假設(shè)、思路、應(yīng)用和性能分析.除此之外，他們還提出云資源狀態(tài)分析研究發(fā)展趨勢將往非監(jiān)督化算法、降低對人工干預(yù)的依賴的方向發(fā)展.

但他們提及的異常檢測算法基本均為靜態(tài)批式異常檢測，與流式異常檢測是完全不同的問題，大多數(shù)現(xiàn)有的異常檢測算法(甚至那些專門為時(shí)間序列數(shù)據(jù)設(shè)計(jì)的算法)不適用于流式應(yīng)用.如洪斌等人提到的UBL算法[19]雖然根據(jù)時(shí)間序列設(shè)計(jì)、具有無監(jiān)督、多指標(biāo)統(tǒng)籌識別的優(yōu)勢，但其模型訓(xùn)練主要還是借助云資源各種工作負(fù)載模式的數(shù)據(jù)離線訓(xùn)練完成，過多的增量更新模型會降低模型的質(zhì)量，對于云資源進(jìn)入一個(gè)新的工作負(fù)載模式需要重新引導(dǎo)SOM[20]，因此不適用于不斷變化的流環(huán)境，而且檢測的指標(biāo)組合與SOM中的特征向量維度是一一對應(yīng)的，若改變了組合，則需要重新引導(dǎo)SOM，擴(kuò)展能力十分有限，靈活性不高，并且隨著數(shù)據(jù)維度增多，該方法的計(jì)算量將成倍增長.

還有一些異常檢測算法采用部分在線學(xué)習(xí)的方式，他們需要有一個(gè)離線學(xué)習(xí)的初始化階段，或是依靠的前瞻之前發(fā)現(xiàn)并標(biāo)記的異常狀態(tài)來進(jìn)行預(yù)測和判別，在靈活性和時(shí)效性上存在缺陷.大多數(shù)基于聚類的方法都屬于這種算法范疇，如自適應(yīng)動態(tài)K-means[21]、數(shù)據(jù)流多類學(xué)習(xí)算法(MIAS)[22]等.

而分層時(shí)間記憶網(wǎng)絡(luò)(Hierarchical Temporal Memeory，HTM)6在創(chuàng)建時(shí)空輸入流的不變表示方面具有前景，可以通過記憶序列的時(shí)空模式的方式同時(shí)滿足無監(jiān)督、實(shí)時(shí)流式分析和在線學(xué)習(xí)三大要求，可以高效地、魯棒地分析實(shí)時(shí)時(shí)序數(shù)據(jù)流，并且對噪聲數(shù)據(jù)具有極高的容忍度[23]，可持續(xù)適應(yīng)檢測數(shù)據(jù)的變化且?guī)缀醪恍枰獏?shù)調(diào)整.

HTM的核心算法組件[24]如圖3所示.

圖3 HTM算法核心組件

原始數(shù)據(jù)通過編碼器編碼成二進(jìn)制向量，然后再經(jīng)HTM的空間池化(Spatial Pooling，SP)算法生成稀疏離散表征(Sparse Distributed Representation，SDR).最后通過HTM的時(shí)間記憶(Temporal Memory，TM)獲得預(yù)測向量.對于給定輸入xt，向量a(xt)是一個(gè)代表當(dāng)前輸入的稀疏二進(jìn)制向量，π(xt)表示對a(xt)的預(yù)測，即下一個(gè)輸入xt+1.HTM網(wǎng)絡(luò)能夠持續(xù)學(xué)習(xí)并建模數(shù)據(jù)流的時(shí)空特征，并被證明在預(yù)測任務(wù)上表現(xiàn)優(yōu)秀[25].

3 企業(yè)多云時(shí)序數(shù)據(jù)實(shí)時(shí)監(jiān)測方案

本節(jié)根據(jù)前兩節(jié)研究內(nèi)容中所描述的多云實(shí)時(shí)監(jiān)測中存在的問題和關(guān)鍵技術(shù)，圍繞時(shí)序數(shù)據(jù)的采集、處理、分析、存儲等方面，設(shè)計(jì)了一個(gè)企業(yè)多云實(shí)時(shí)監(jiān)測方案MCloudMonitor.

3.1 MCloudMonitor總體架構(gòu)

MCloudMonitor主要分為數(shù)據(jù)支持子系統(tǒng)和業(yè)務(wù)支持子系統(tǒng)，其架構(gòu)如圖4所示.

圖4 MCloudMonitor架構(gòu)圖Fig.4 Architecture diagram of MCloudMonitor

其中數(shù)據(jù)支持子系統(tǒng)主要?jiǎng)澐譃椴杉?、傳輸、處理、存儲、展?大層，這5層在系統(tǒng)中的主要作用分別是：

3https：//www.influxdata.com/products/influxdb-overview

4http：//arxiv.org/abs/1901.08304

5https：//flink.apache.org/

6https：//numenta.com/neuroscience-research/research-publications/papers/hierarchical-temporal-memory-white-paper/

1)數(shù)據(jù)采集層：該層主要作用是在各云平臺的資源中實(shí)時(shí)采集各類的Metrics，如CPU使用信息、Mem使用信息、Swap使用信息、Disk使用信息、Net使用信息等.

2)數(shù)據(jù)傳輸層：該層主要作用是借助消息隊(duì)列傳輸采集到的監(jiān)測數(shù)據(jù)，并起到數(shù)據(jù)緩沖的作用，防止因數(shù)據(jù)傳輸量太大或數(shù)據(jù)流阻塞而造成數(shù)據(jù)的丟失.

3)數(shù)據(jù)處理層：由于監(jiān)測數(shù)據(jù)(數(shù)據(jù)源)是實(shí)時(shí)采集、源源不斷的，因此對數(shù)據(jù)的處理是流式的而不是批式的，需要借助Flink流處理框架進(jìn)行在線處理.該層主要作用是對采集到的原始時(shí)序數(shù)據(jù)進(jìn)行一些必要的流計(jì)算預(yù)處理，將加工處理后的數(shù)據(jù)存入存儲層作為數(shù)據(jù)展示層的數(shù)據(jù)源.若為該數(shù)據(jù)的對象設(shè)置了告警，將該數(shù)據(jù)異步發(fā)送至異常檢測模塊.異常檢測模塊在做數(shù)據(jù)分析時(shí)需要考慮到數(shù)據(jù)亂序的情況，具備亂序處理能力，并通過異常檢測算法判斷云資源是否處于異常狀態(tài)，若處于異常狀態(tài)，則將相關(guān)信息發(fā)送至告警模塊.告警模塊生成告警記錄存入存儲層，并異步調(diào)用消息通知服務(wù)向聯(lián)系人發(fā)送通知.

4)數(shù)據(jù)存儲層：該層的主要作用是使用InfluxDB時(shí)序數(shù)據(jù)庫存儲所有的時(shí)序數(shù)據(jù)，包括監(jiān)測數(shù)據(jù)和告警記錄，為后面的數(shù)據(jù)可視化提供數(shù)據(jù)源.除此之外，關(guān)系型數(shù)據(jù)存儲至MySQL關(guān)系型數(shù)據(jù)庫中.為了保證系統(tǒng)低延遲的特性，使用Redis作為內(nèi)存數(shù)據(jù)庫存儲一些臨時(shí)數(shù)據(jù)和熱點(diǎn)數(shù)據(jù)的緩存，減少從MySQL讀取數(shù)據(jù)的時(shí)間開銷.

5)數(shù)據(jù)展示層：該層嵌入Web前端之中，主要作用是將時(shí)序數(shù)據(jù)通過可視化圖表展示出來，通過圖表用戶可以直觀地知道運(yùn)行在不同云平臺的云資源運(yùn)行狀態(tài).

業(yè)務(wù)支持子系統(tǒng)主要包括用戶管理、工作空間管理和輔助服務(wù).

3.2 數(shù)據(jù)支持子系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.2.1 數(shù)據(jù)采集

首先在每個(gè)平臺需要采集的云服務(wù)器中安裝采集探針，它可以采集服務(wù)器運(yùn)行的基本信息和其上的運(yùn)行的軟件的信息，MCloudMonitor當(dāng)前主要采集的是服務(wù)器運(yùn)行的數(shù)據(jù)指標(biāo)，采集探針配置如圖 5所示.

圖5 Telegraf配置

通常來說，從采集工具采集的監(jiān)控?cái)?shù)據(jù)量會很大，因此需要考慮到數(shù)據(jù)量的大小以及未來的數(shù)據(jù)量變化造成的峰谷狀態(tài)，而Kafka無論從性能吞吐量，還是在可靠性和運(yùn)維方面來講，對于監(jiān)測系統(tǒng)來說是最佳的選擇.Kafka中Topic格式為“采集方式-數(shù)據(jù)領(lǐng)域”，本方案中用于傳輸Telegraf探針采集多云數(shù)據(jù)的Topic為telegraf-multicloud，將來增加其他的采集方式和數(shù)據(jù)領(lǐng)域可以增加新的Topic.同一個(gè)采集器始終將數(shù)據(jù)發(fā)往同一個(gè)Broker中，同一host寫入到Topic的同一分片中，由輸出插件kafka配置中routing_tag一項(xiàng)來保證.

3.2.2 數(shù)據(jù)預(yù)處理

借助流計(jì)算來完成時(shí)序數(shù)據(jù)的預(yù)處理，其所在的流式計(jì)算視為主流，主流中對于原始數(shù)據(jù)的加工處理和派發(fā)流程如圖6所示.

圖6 預(yù)處理流程圖

需要先將從Kafka中接收到的各類指標(biāo)數(shù)據(jù)轉(zhuǎn)換成各類Measurement對象，并計(jì)算派生屬性的值.接著通過流計(jì)算解析時(shí)序數(shù)據(jù)中的標(biāo)簽從而獲得被監(jiān)測的對象信息以及其所擁有的指標(biāo)列表并存入關(guān)系型數(shù)據(jù)庫中.這些采集對象信息將存入數(shù)據(jù)庫中，但同步存儲至關(guān)系型數(shù)據(jù)庫時(shí)間開銷較大，因此通過消息隊(duì)列解耦，異步將數(shù)據(jù)存入關(guān)系型數(shù)據(jù)庫中.

為了保證子模塊的單一職責(zé)，將對象是否設(shè)置了告警規(guī)則交由異常檢測子模塊(輔流)來判斷，加速主流計(jì)算的其他處理流程，主流計(jì)算只需要派發(fā)各類指標(biāo)對象至異常檢測子模塊，該過程也使用消息隊(duì)列解耦來實(shí)現(xiàn)異步通信.

最后主流計(jì)算無需等待輔流的完成信號即可將Measurement對象存入時(shí)序數(shù)據(jù)庫的指標(biāo)庫中.

3.2.3 異常檢測

異常檢測子模塊同樣借助流計(jì)算框架來完成，檢測流程如圖7所示.

圖7 異常檢測流程圖Fig.7 Flow chart of anomaly detection

其中檢測對象狀態(tài)步驟分為基本檢測和高級檢測.基本檢測即普通的閾值檢測.高級檢測使用了在線學(xué)習(xí)的模型訓(xùn)練方法，根據(jù)線上數(shù)據(jù)的變化，實(shí)時(shí)調(diào)整模型，并對設(shè)置了告警的對象檢測其當(dāng)前運(yùn)行狀態(tài)是否異?；蚣磳a(chǎn)生異常(所選用的算法能識別出資源即將產(chǎn)生異常的數(shù)據(jù)流變化，其方式與判斷當(dāng)前異常的方式一致，本質(zhì)都是根據(jù)數(shù)據(jù)流偏差來做出判斷).由于在線學(xué)習(xí)使得模型能夠反映線上數(shù)據(jù)的變化，從而提高檢測的準(zhǔn)確率.

上述內(nèi)容中高級檢測所使用的算法是基于分層時(shí)間記憶(HTM)網(wǎng)絡(luò)來設(shè)計(jì)的，對于連續(xù)的輸入流，在每一個(gè)時(shí)間點(diǎn)t，檢測器需要識別云資源狀態(tài).然而HTM本身能做的不是異常識別，而是預(yù)測下一個(gè)流模式，即正常情況下應(yīng)該出現(xiàn)的狀態(tài)，并不能直接給出異常判斷結(jié)果.因此對于HTM預(yù)測的結(jié)果設(shè)計(jì)了如圖8所示兩個(gè)附加處理步驟.

圖8 異常檢測算法主要步驟Fig.8 Main steps of anomaly detection algorithm

首先從兩個(gè)稀疏向量計(jì)算原始異常分?jǐn)?shù)，再得出異常似然值，以此確定系統(tǒng)是否異常.下面詳細(xì)介紹這兩個(gè)步驟:

1)計(jì)算原始異常分?jǐn)?shù)

該分?jǐn)?shù)用來衡量當(dāng)前時(shí)刻HTM網(wǎng)絡(luò)接收到的實(shí)際流模式相對預(yù)測流模式的差異，通過矢量的投影來計(jì)算.在t時(shí)刻，原始異常分?jǐn)?shù)的計(jì)算公式見公式(1).

(1)

若實(shí)際流模式與預(yù)測流模式完全一致，St=0；若兩個(gè)矢量正交，即完全不相似，則St=1；或根據(jù)兩者的相似程度介于0～1之間.由于HTM的持續(xù)學(xué)習(xí)特性，對云資源的行為變更也能進(jìn)行較好的處理.當(dāng)云資源行為變化時(shí)，異常分?jǐn)?shù)在變化時(shí)刻將很高，伴隨著模型適應(yīng)并穩(wěn)定，異常分?jǐn)?shù)會自行降至0.

2)計(jì)算異常似然

原始異常分?jǐn)?shù)用來衡量當(dāng)前輸入可預(yù)測性，可預(yù)測性的變化通常是異常行為的標(biāo)志，但由于云資源運(yùn)行數(shù)據(jù)出現(xiàn)隨機(jī)跳躍或尖峰的情況并不少見，因此將異常分?jǐn)?shù)直接閾值化會導(dǎo)致許多假陽性，產(chǎn)生誤報(bào).

為了處理這類問題，引入第2步計(jì)算異常似然.不通過對原始異常分?jǐn)?shù)限定閾值的方式來判斷數(shù)據(jù)流是否異常，而是通過建模異常分?jǐn)?shù)的分布來衡量當(dāng)前狀態(tài)異常的可能性.因此，異常似然是基于不斷變化的數(shù)據(jù)流整體來定義資源當(dāng)前狀態(tài)異常程度的度量.

具體做法是在原始異常分?jǐn)?shù)之上使用尺寸大小為W的滑動窗口來建模正態(tài)分布，樣本均值和方差隨著窗口的滑動不斷更新，見公式(2)和公式(3).Flink提供了滑動窗口機(jī)制來連續(xù)計(jì)算樣本均值和方差.

(2)

(3)

接著計(jì)算異常分?jǐn)?shù)的短期平均值替代當(dāng)前異常分?jǐn)?shù)起到濾波的作用，再利用高斯尾部概率[26]閾值化來判斷是否將云資源當(dāng)前狀態(tài)數(shù)據(jù)定義為一個(gè)異常，見公式(4)～公式(6).其中W′是用來短期平均值的窗口，W′遠(yuǎn)小于W.

(4)

(5)

Anomaly≡Lt≥1-ε

(6)

在無噪聲的場景中，異常分?jǐn)?shù)樣本集中分布在0附近，異常似然對異常分?jǐn)?shù)的值較為敏感.在有噪聲的場景下異常分?jǐn)?shù)方差較大且均值偏移，分布較為分散，并且通過濾波降低異常似然的敏感度，使得異常分?jǐn)?shù)持續(xù)峰值才會導(dǎo)致異常似然的增大，因此對噪聲具有很強(qiáng)的容忍性.

基于Flink框架實(shí)現(xiàn)的異常檢測模塊如圖9所示.首先以Measurement和Tags為key，通過keyBy算子將DataStream分流成KeyedStream，并借助Flink的KeyedProcessFunction來自定義異常檢測函數(shù).其中高級檢測是根據(jù)算法設(shè)計(jì)的內(nèi)容，借助Flink提供的基于滑動窗口的流處理聚合計(jì)算和Watermark亂序處理機(jī)制來實(shí)現(xiàn)，并封裝成接口供異常檢測模塊調(diào)用，通過Flink來運(yùn)行多個(gè)網(wǎng)絡(luò).由于Flink是有狀態(tài)的流計(jì)算框架，因此可以借助Flink的Keyed State來存放每個(gè)Field對應(yīng)網(wǎng)絡(luò)實(shí)例和異常分?jǐn)?shù)分布實(shí)例的引用.

圖9 基于Flink框架實(shí)現(xiàn)的異常檢測模塊Fig.9 Anomaly detection module based on Flink

4 測試與評估

4.1 異常檢測算法評估

The Numenta Anomaly Benchmark(NAB)是專門為流實(shí)時(shí)應(yīng)用而設(shè)計(jì)的用來評估異常檢測算法的Benchmark，包含了許多帶有異常標(biāo)簽的真實(shí)和模擬的時(shí)序數(shù)據(jù)文件，從服務(wù)器指標(biāo)到工業(yè)機(jī)器上的傳感器再到社交媒體聊天數(shù)據(jù)，涉及算法將應(yīng)對的場景：空間和時(shí)間維度的混合異常、純凈和有噪聲的數(shù)據(jù)類型以及隨時(shí)間變化的數(shù)據(jù)流.本文選用NAB的AmazonCloudwatch提供的AWS服務(wù)器指標(biāo)數(shù)據(jù)集進(jìn)行算法測試，包括CPU利用率，網(wǎng)絡(luò)流入字節(jié)數(shù)，磁盤讀字節(jié)數(shù)，測試結(jié)果如表1所示，其中每個(gè)數(shù)據(jù)集的前15%部分的數(shù)據(jù)用于模型的初始自動校準(zhǔn).

表1 NAB數(shù)據(jù)集測試結(jié)果

由于HTM能夠根據(jù)數(shù)據(jù)流的偏差預(yù)見異常的發(fā)生，因此在測試數(shù)據(jù)的每個(gè)異常點(diǎn)前都設(shè)置一個(gè)預(yù)見窗口，只要算法檢測出的異常點(diǎn)落在該窗口內(nèi)，該窗口中實(shí)際的異常點(diǎn)都標(biāo)記為檢測成功.但若預(yù)見窗口太小，會將檢測結(jié)果視為誤報(bào)，若窗口太大，會將誤報(bào)視為正確結(jié)果，因此權(quán)衡兩者關(guān)系，將預(yù)見窗口的長度定為數(shù)據(jù)總長度的1%.

本文在該數(shù)據(jù)集上還運(yùn)行了另外兩種開源的無監(jiān)督實(shí)時(shí)異常檢測算法的檢測器作為對比實(shí)驗(yàn)，分別為Twitter的ADVec7和隨機(jī)切割森林(Random Cut Forest)[27]，但這兩種算法都不能預(yù)測異常的發(fā)生，因此不設(shè)置預(yù)見窗口.得出的結(jié)果如表2所示.

表2 不同檢測算法的評價(jià)指標(biāo)

從結(jié)果中可知，在處理流數(shù)據(jù)上(即O(N)規(guī)模的數(shù)據(jù))，Twitter ADVec的處理時(shí)間最短，隨機(jī)切割森林的處理時(shí)間最長，兩種算法的檢測器檢測效果均不如本文的異常檢測算法.因此綜合考慮，本文的異常檢測算法表現(xiàn)較優(yōu).

表3 真實(shí)數(shù)據(jù)集測試結(jié)果Table 3 Test results of real data set

除了開源數(shù)據(jù)集外，本文還使用企業(yè)的實(shí)際云資源運(yùn)行數(shù)據(jù)來進(jìn)行測試.由于數(shù)據(jù)量較大、產(chǎn)生較快，因此難以手動對運(yùn)行時(shí)產(chǎn)生的數(shù)據(jù)進(jìn)行實(shí)時(shí)標(biāo)記.但根據(jù)觀察，實(shí)際運(yùn)行環(huán)境中異常出現(xiàn)次數(shù)較少，異常時(shí)間點(diǎn)相對于總數(shù)據(jù)量占比較小，可以先收集企業(yè)所使用云資源的運(yùn)行數(shù)據(jù)并將其可視化，由運(yùn)維人員來手動篩選并標(biāo)記異常時(shí)間點(diǎn).最后將該實(shí)際運(yùn)行所得的數(shù)據(jù)集轉(zhuǎn)為流數(shù)據(jù)逐個(gè)輸入檢測器中，設(shè)置好預(yù)見窗口并進(jìn)行測試，得到如表3所示的測試結(jié)果，計(jì)算得到各項(xiàng)評價(jià)指標(biāo)如表4所示，可以看出使用實(shí)際數(shù)據(jù)進(jìn)行測試得到的結(jié)果也同樣較好.

7https：//blog.twitter.com/engineering/en_us/a/2015/introducing-practical-and-robust-anomaly-detection-in-a-time-series.html

表4 真實(shí)數(shù)據(jù)集測試結(jié)果評價(jià)指標(biāo)

檢測器隨同系統(tǒng)在實(shí)際運(yùn)行中漏報(bào)、誤報(bào)率低且能夠?qū)崟r(shí)地、盡早地檢測出已知和未知的異常，但在檢測起步階段由于數(shù)據(jù)量不足且HTM網(wǎng)絡(luò)通過在線學(xué)習(xí)處于頻繁更新模型階段，檢測器會頻繁將云資源運(yùn)行狀態(tài)誤判為異常，解決方法是通過告警規(guī)則設(shè)置的沉默時(shí)間使得用戶免于在HTM自動校準(zhǔn)階段受到“告警轟炸”.

4.2 功能測試

對基于上述方案實(shí)現(xiàn)的系統(tǒng)進(jìn)行完整功能測試并且測試用例均通過，下面給出部分關(guān)鍵功能的實(shí)現(xiàn)效果.

使用者在安裝配置完采集器后，可以在對象一欄查看采集到的各個(gè)云平臺的被監(jiān)測對象的信息，如圖10所示.

圖10 被監(jiān)測對象的信息Fig.10 Information of monitored objects

使用者可以自定義場景，并配置圖表數(shù)據(jù)源讀取時(shí)序數(shù)據(jù)庫中的時(shí)序指標(biāo)數(shù)據(jù)來滿足不同的運(yùn)維業(yè)務(wù)視角，如圖11所示的多云平臺綜合場景.

圖11 多云資源視圖場景Fig.11 View of multi-cloud resources status

使用者可以至異常檢測庫中配置告警規(guī)則組，還可對告警規(guī)則組進(jìn)行告警通知配置，配置完成后可前往系統(tǒng)的事件界面查看告警歷史記錄，如圖12所示，每條包含發(fā)生時(shí)間、來源、狀態(tài)、檢測庫名稱、異常內(nèi)容.

4.3 壓力測試

對實(shí)現(xiàn)的系統(tǒng)進(jìn)行的壓力測試分為兩部分：

1)云服務(wù)器指標(biāo)數(shù)據(jù)測試：通過采集探針采集服務(wù)器數(shù)據(jù)(cpu，mem，disk，network，system等)，以該數(shù)據(jù)為樣本(333個(gè)數(shù)據(jù)點(diǎn)，137條時(shí)間線).

2)最大承載量測試：通過MockData，生成500個(gè)數(shù)據(jù)點(diǎn)，每個(gè)點(diǎn)包含5個(gè)tag，5個(gè)field(500個(gè)數(shù)據(jù)點(diǎn)，227條時(shí)間線).

圖12 告警記錄Fig.12 Alarm records

測試工具為5.3版本的Jmeter，測試環(huán)境為本系統(tǒng)的預(yù)發(fā)環(huán)境，系統(tǒng)實(shí)例在4核8G單節(jié)點(diǎn)部署，InfluxDB實(shí)例也在4核8G單節(jié)點(diǎn)部署.

表5 壓力測試結(jié)果

每輪測試新建工作空間，通過設(shè)置不同線程數(shù)，每次將數(shù)據(jù)寫入新工作空間來觀察系統(tǒng)的性能.測試結(jié)果如表5所示.從測試結(jié)果可知系統(tǒng)在該預(yù)發(fā)環(huán)境部署下吞吐量均在200/sec左右，且很少出現(xiàn)Error，系統(tǒng)的表現(xiàn)比較穩(wěn)定.

5 總 結(jié)

本文提出了一種企業(yè)多云時(shí)序數(shù)據(jù)實(shí)時(shí)監(jiān)測方案MCloudMonitor，圍繞多云資源運(yùn)行產(chǎn)生的海量時(shí)序數(shù)據(jù)提供時(shí)序數(shù)據(jù)存儲和實(shí)時(shí)流處理服務(wù)，基于分層時(shí)間記憶網(wǎng)絡(luò)來設(shè)計(jì)實(shí)時(shí)在線異常檢測算法并將其整合進(jìn)所實(shí)現(xiàn)的系統(tǒng)之中.除此之外，本文通過測試來評估和調(diào)整該方案的實(shí)現(xiàn)效果，使得該系統(tǒng)能夠幫助運(yùn)維人員從企業(yè)的視角進(jìn)行便捷的多云監(jiān)測，并在實(shí)時(shí)監(jiān)測云資源運(yùn)行狀態(tài)的基礎(chǔ)上，通過告警機(jī)制縮短異常處理響應(yīng)時(shí)間，提升企業(yè)的運(yùn)維效率.

基本的多云實(shí)時(shí)監(jiān)測架構(gòu)已經(jīng)完成，但本文的實(shí)現(xiàn)成果仍存在不足和值得提升之處，如增加PaaS層的監(jiān)測以及異常的聯(lián)合分析，需要后續(xù)的不斷研究、迭代和改進(jìn).