Pixie 旨在幫助開發(fā)者快速了解并調(diào)試產(chǎn)品系統(tǒng)。為了實現(xiàn)這一目標(biāo),我們將提供支持,幫助開發(fā)者輕松訪問其生產(chǎn)系統(tǒng)中的一系列指標(biāo)和日志數(shù)據(jù)。如,幫助收集系統(tǒng)中各個進(jìn)程的 CPU 和內(nèi)存用量的結(jié)構(gòu)化數(shù)據(jù),以及許多類型的非結(jié)構(gòu)化數(shù)據(jù)(例如HTTP 請求的正文,或者程序發(fā)出的錯誤消息)。
以上只是其中兩個示例,此外我們還收集許多其他類型的數(shù)據(jù)。在本篇文章中,我們將重點(diǎn)介紹在 Pixie 中收集如 HTTP 請求/相應(yīng)正文等大量非結(jié)構(gòu)化數(shù)據(jù)。在可以預(yù)見的未來中,我們認(rèn)為查詢此類非結(jié)構(gòu)化計算機(jī)數(shù)據(jù),可以像查詢結(jié)構(gòu)化數(shù)據(jù)一樣輕松高效。為了實現(xiàn)這一目標(biāo),我們利用最先進(jìn)的 NLP 技術(shù)來學(xué)習(xí)數(shù)據(jù)的結(jié)構(gòu)。
我們將在本文中與您分享經(jīng)驗和進(jìn)展,希望能為您在思考類似問題時提供一些幫助。
HTTP 聚類
假設(shè)使用 Pixie 的開發(fā)者想要了解哪些類型的 HTTP 請求特別慢。他們無需手動篩查大量單獨(dú)的 HTTP 請求,因為我們可以將 HTTP 請求進(jìn)行語義聚類,然后顯示每種語義聚類請求的延遲時間序列。為了對此進(jìn)行說明,我們先講解最終結(jié)果,然后再回過頭來講解如何得到這些結(jié)果。我們將利用 Pixie 對一款名為 Online Boutique 的演示版應(yīng)用進(jìn)行探索。將 Pixie 部署至運(yùn)行 Online Boutique 的 Kubernetes 集群之后,就可以開始了。舉個例子,我們可以看看 Online Boutique 應(yīng)用中的網(wǎng)絡(luò)連接示意圖:
Online Boutique
https://github.com/GoogleCloudPlatform/microservices-demo
從這個服務(wù)示意圖中可以看出,前端服務(wù)處理傳入請求,并將其發(fā)送至各自的微服務(wù)。接下來,我們深入了解一下發(fā)送至前端服務(wù)的 HTTP 請求及其相應(yīng)延遲時間。
HTTP 請求正文延遲時間 (ms)
“product_id=L9ECAV7KIM&quantity=33.325302
“email=someone%40example.com&street_ad
dress=1600+Amphitheatr.。.102.625462
“product_id=OLJCESPC7Z&quantity=3”3.4530790000000002
“product_id=L9ECAV7KIM&quantity=5”4.828718
“product_id=0PUK6V6EV0&quantity=2”5.319163
“email=someone%40example.com&street_ad
dress=1600+Amphitheatr107.361424
”product_id=0PUK6V6EV0&quantity=4“3.81733
”currency_code=EUR“0.203676
”currency_code=USD“0.220932
”product_id=0PUK6V6EV0&quantity=4“4.538055
請求的樣本數(shù)較少,無法立即明確判斷出情況。包含 “email=。..?address=。..” 的請求似乎比其他請求慢很多,但我們無法確定這些示例并非離群值。數(shù)據(jù)就看到這里,接下來,我們使用非結(jié)構(gòu)化文本聚類技術(shù)(稍后對此進(jìn)行介紹),通過 HTTP 請求正文的內(nèi)容對其進(jìn)行語義聚類。
這是各個語義集群請求的第 99 百分位平均響應(yīng)延遲時間圖表。利用此圖表,您可以快速確定發(fā)送至前端服務(wù)的三大類請求,以及這些請求的延遲概況。我們能夠立即看到“電子郵件”請求集群的第 99 百分位平均延遲時間明顯高于其他集群,而且“產(chǎn)品”集群偶爾會出現(xiàn)延遲尖峰。針對這兩種可行的數(shù)據(jù)分析,我們可以進(jìn)一步進(jìn)行調(diào)試。現(xiàn)在,讓我們來深入探討如何達(dá)成這一目標(biāo)。
模型開發(fā)詳細(xì)信息
要求
我們的模型將部署至客戶的產(chǎn)品集群中,因此這些模型必須為輕量級,且具有高性能;理想狀態(tài)下,還應(yīng)具備足夠的速度,能夠在最小 CPU 消耗的前提下以線速處理數(shù)據(jù)。為了保障數(shù)據(jù)隔離,必須在客戶集群中訓(xùn)練客戶數(shù)據(jù)。此外,由于數(shù)據(jù)平面完全包含在客戶集群中,我們對數(shù)據(jù)有嚴(yán)格的存儲空間限制,因此我們必須利用 ML 技術(shù)對我們收集的數(shù)據(jù)進(jìn)行智能采樣。
數(shù)據(jù)集
我們對數(shù)據(jù)隔離有嚴(yán)格要求,因此我們使用 Loghub 數(shù)據(jù)集來引導(dǎo)模型訓(xùn)練。此數(shù)據(jù)集是來自各種上下文的日志消息(Android 系統(tǒng)日志、Apache 服務(wù)器日志、超級計算機(jī)/HPC 日志等)的集合。為了測試未知日志格式的模型泛化,我們保留了 Android 日志數(shù)據(jù)用來進(jìn)行測試,并基于日志數(shù)據(jù)的其余部分進(jìn)行訓(xùn)練。
Loghub
https://github.com/logpai/loghub
我們使用 Google 的 SentencePiece 來對日志消息進(jìn)行詞條化,尤其是利用對詞匯大小為 16k 的子詞的詞條化實現(xiàn)(基于 Unigram 語言模型)。下圖是我們進(jìn)行詞條化后生成的所有 16k 詞匯子詞片段構(gòu)成的詞云圖。字詞的大小表示其在數(shù)據(jù)集中出現(xiàn)的頻率。
SentencePiece
https://github.com/google/sentencepiece
詞云圖,展示對 Logpai Loghub 計算機(jī)日志數(shù)據(jù)集進(jìn)行詞條化后的詞匯子詞片段
此詞云能夠顯示出我們數(shù)據(jù)集的偏向。舉個例子,約 30% 的數(shù)據(jù)為 Windows 日志,從“windows”和“microsoft”詞條的高頻率就可以看出。此外,若您目光敏銳,您可能會發(fā)現(xiàn)我們的數(shù)據(jù)集中有很多“哭臉”,但實際上“):”幾乎總是以左括號開頭,如下例所示:
[Thu Jan 2612:23:072006] [error] config.update(): Can‘t create vm
[Fri Jan 27 1116 2006] [error] [client 202.143.128.18] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /
模型架構(gòu)
我們可以使用此詞條化的數(shù)據(jù)集,利用從左到右的下一字詞預(yù)測(按照 OpenAI’s GPT 模型)來訓(xùn)練基于自注意力的模型。從左到右的下一字詞預(yù)測的任務(wù)是,在給定一系列上文詞條的情況下嘗試預(yù)測下一個詞條。這種從左到右的方式使我們的模型有別于使用雙向上下文的模型,比如 BERT。我們將在未來嘗試雙向模型。此 TensorFlow教程演示了對類似架構(gòu)的訓(xùn)練,唯一的區(qū)別是我們在教程中省略了架構(gòu)的編碼器端。
TensorFlow 教程
https://tensorflow.google.cn/tutorials/text/transformer
下圖展示了我們所使用的架構(gòu)。我們有 6 個解碼器塊,每個塊都有一個自注意力層和一個前饋層。請注意,為簡潔起見,該圖省略了自注意力和前饋層上的跳躍連接,以及與這些跳躍連接相關(guān)的層規(guī)范化。
GPT 類語言模型架構(gòu)
總而言之,此架構(gòu)有 647 萬個參數(shù),與最先進(jìn)的語言模型相比,這是一個非常小的架構(gòu)。舉個例子,DistillBERT 有 6,600 萬個參數(shù)。另一方面,最大版本的 GPT-3 有 1,750 億個參數(shù)。
我們對此架構(gòu)進(jìn)行了 10 個 epoch 的訓(xùn)練,每個紀(jì)元 epoch 大約有 1 億條獨(dú)特的日志消息。在每個 epoch 之后,我們在驗證集上運(yùn)行模型,并將驗證準(zhǔn)確率最高的紀(jì)元中的模型用作最終模型。在保留的 Android 日志數(shù)據(jù)上,我們下一字詞預(yù)測的測試準(zhǔn)確率達(dá)到 63.13%。鑒于我們尚未進(jìn)行超參數(shù)調(diào)優(yōu)或其他優(yōu)化,此準(zhǔn)確率水平在未來還有很大的提升空間。
我們現(xiàn)在有一種方法可以從上下文中預(yù)測計算機(jī)日志數(shù)據(jù)中的未來詞條,并且具有不錯的準(zhǔn)確性。然而,這并不能立即幫助我們實現(xiàn)從數(shù)據(jù)中提取結(jié)構(gòu)化特征的最初目標(biāo)。為了進(jìn)一步實現(xiàn)這一目標(biāo),我們將探索語言模型生成的特征空間,而不是語言模型的預(yù)測。
我們的目標(biāo)是將復(fù)雜的數(shù)據(jù)空間轉(zhuǎn)換為固定維度的特征空間,然后將其用于后續(xù)任務(wù)。為了實現(xiàn)這一目標(biāo),我們需要將語言模型的輸出轉(zhuǎn)換為一個固定維度的向量,我們稱之為特征向量。要實現(xiàn)此目標(biāo),一種方法是使用 BERT 那樣的模型。
使用 BERT 這類模型,將預(yù)訓(xùn)練語言模型擴(kuò)展到監(jiān)督任務(wù)的方法是在句子的 《CLS》(或 《s》)詞條的輸出上添加一個全連接網(wǎng)絡(luò),然后在全連接網(wǎng)絡(luò)中,對某些分類任務(wù)的模型進(jìn)行微調(diào)(如下圖所示)。由此得出的自然特征向量可作為 Softmax 層之前的輸出。
Alammar, J (2018),轉(zhuǎn)換器圖解
我們計劃在未來對這種方法進(jìn)行進(jìn)一步研究,但是現(xiàn)在我們想看看在不添加任何額外監(jiān)督的情況下能得到什么結(jié)果。這需要一種啟發(fā)式方法將我們的輸出序列轉(zhuǎn)換為固定長度的向量。實現(xiàn)此目標(biāo)的一種方法是,在輸出的序列維度上使用最大池化運(yùn)算符。假設(shè)我們的語言模型輸出一個 256 維向量的序列,那么序列維度最大池化將輸出一個單獨(dú)的 256 維向量,其中每個維度都是序列的所有輸出中該維度的最大值。這種方法背后的理念是,在最終表示中包含具有更強(qiáng)響應(yīng)的神經(jīng)元更為重要。
結(jié)果
我們可以測試這種方法對 Loghub 數(shù)據(jù)子集(我事先將其手動標(biāo)記為不同語義集群)進(jìn)行聚類的效果如何。以下是手動標(biāo)記的測試數(shù)據(jù)集中的三個日志消息。前兩個被標(biāo)記為在同一個語義集群中,因為兩者都與文件查找失敗有關(guān),最后一個來自不同的集群,因為它是關(guān)于刷新數(shù)據(jù)的無關(guān)消息。
Loghub
https://github.com/logpai/loghub
[Wed Nov 0922:30:052005] [error] [client 216.138.114.25] script not found or unable to stat: /var/www/cgi-bin/awstats.p
[Sat Jan 2819:29:292006] [error] [client 211.154.174.50] File does not exist: /var/www/html/modules
20171230-12:25:37:318|Step_StandStepCounter|30002312|flush sensor data
同時可以利用手動標(biāo)記的測試集,衡量模型分離不同集群的效果。為了實現(xiàn)這個目標(biāo),我們使用 KMeans 算法根據(jù)模型的輸出進(jìn)行聚類,然后將這種聚類結(jié)果與手動標(biāo)記的聚類結(jié)果進(jìn)行比較。在此測試集上,模型調(diào)整后的隨機(jī)性分?jǐn)?shù)是 0.53,0.0 是隨機(jī)標(biāo)記,1.0 是完美標(biāo)記。與下一字詞預(yù)測的準(zhǔn)確率一樣,此性能不是很好,但卻是一個很好的起點(diǎn)。
我們還可以查看模型特征空間的低維度表示,使用 PCA 將維數(shù)減少至二。下圖顯示了測試數(shù)據(jù)集中每個點(diǎn)的嵌入的前兩個 PCA 維度。顏色代表點(diǎn)所屬的語義集群。請注意,由于這些是嵌入空間的二維子空間中的分布圖,點(diǎn)的絕對位置幾乎沒有意義,更多的意義來自每個集群的緊密度。在下圖中,我們可以看到模型很好地分離了一些類,但在其他類上卻失敗了。
模型特征空間的二維表示
使用此方法,我們應(yīng)該能夠在 Pixie 中對非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行聚類,并用其語義集群 ID 對其進(jìn)行標(biāo)記,從而從非結(jié)構(gòu)化數(shù)據(jù)中提取結(jié)構(gòu)化特征。到目前為止,此特殊特征的可解釋性并不是很高,但未來我們會著手于這一點(diǎn)
推斷
現(xiàn)在,讓我們嘗試在 Pixie 系統(tǒng)中實現(xiàn)此方法。為此,我們首先需要將模型轉(zhuǎn)換為 TensorFlow Lite,然后將其加載到 Pixie 執(zhí)行引擎中。決定使用 TensorFlow Lite 是因為我們需要盡可能減少消耗,并且我們希望未來能夠靈活地將其部署至異構(gòu)邊緣設(shè)備,包括 Raspberry PI 和 ARM 微控制器。
轉(zhuǎn)換至 TensorFlow Lite 十分簡單。我們?yōu)樽约旱哪P蛣?chuàng)建一個 TF 函數(shù)并調(diào)用內(nèi)置轉(zhuǎn)換器來生成一個 TensorFlow Lite 模型 Protobuf 文件:
model = tf.keras.models.load_model(model_path)
@tf.function(input_signature=[tf.TensorSpec([1, max_length], dtype=tf.int32)def pred_fn(encoded_text):# Create a mask that masks out 0 tokens, and future tokens for next word prediction.
mask = create_padded_lookahead_mask(max_length)
# Our saved model outputs both its next word predictions, and the activations of its final layer. We only use the activations of the final layer for clustering purposes.
model_preds, last_layer_output = model([encoded_text, mask], training=False)
# Max pool over the seq dimension.return tf.reduce_max(last_layer_output, axis=1)
converter = tf.lite.TFLiteConverter.from_concrete_functions([fn.get_concrete_function()])
tflite_model = converter.convert()
Pixie 的查詢引擎可以查詢和使用 Pixie 收集的數(shù)據(jù)。此引擎已經(jīng)有了 KMeans 運(yùn)算符,所以我們需要做的就是將我們的 TFLite 模型加載到引擎中,然后編寫一個自定義的 PxL 腳本(一個基于 Python/Pandas 的 Pixie 腳本語言中的腳本)來對我們的數(shù)據(jù)進(jìn)行聚類。我們正在開發(fā)一個公共 API,為的是將自定義 ML 模型加載到引擎中,但現(xiàn)在我們將使用一些內(nèi)部特征來實現(xiàn)這一目標(biāo)。模型加載完成后,我們就可以在 Pixie 平臺中的任何非結(jié)構(gòu)化數(shù)據(jù)上使用此模型。
責(zé)任編輯:haq
-
數(shù)據(jù)
+關(guān)注
關(guān)注
8文章
6909瀏覽量
88849 -
機(jī)器學(xué)習(xí)
+關(guān)注
關(guān)注
66文章
8382瀏覽量
132444
原文標(biāo)題:利用機(jī)器學(xué)習(xí)在 Pixie 上進(jìn)行非結(jié)構(gòu)化數(shù)據(jù)處理
文章出處:【微信號:yingjiansanrenxing,微信公眾號:硬件三人行】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論