在我之前的文章里,我有講述很多有關使用機器學習來針對數據做異常監測的文章。你可以在 “開發者上手指南” 里的 “機器學習” 章節中找到。在今天的練習中,我將使用最新的 Elastic Stack 9.0.2 來展示如何在 Elasticsearch 中使用機器學習的方法來進行異常監測。很多人可能想問:為什么我們需要機器學習?我們知道針對我們全觀測性:指標,日志及跟蹤,我們可以采集大量的數據,但是其中的 95% 及以上的數據大多數可以稱之為垃圾,因為它們不可能為我們提供任何的有價值的信息。只有當某些指標或者個體發生異常的時候,我們可以稱之為事件。這也是我們在可觀測性里非常關注的事件,比如一個指標突然增加,或者突然減少,或者某類的日志數量突然增加,這些都是對運維人員非常重要的信號。它們可以為運維人員提供有價值的信息并提前預防可能發生的事情。即便如此,我們的運維人員不可能一天24小時在機器旁不斷地觀看儀表盤來查看可能出現的異常事件。在這種情況下,我們可以通過機器學習的方法來代替我們人類來追蹤這些事件。我們可以通過人工智能針對歷史數據進行學習,并用學到的知識來針對數據進行檢測及預測。當異常發生時,我們甚至可以充分利用告警機制來通知有關的運維人員,并積極干預可能出現的故障。這個就是機器學習的目的所在!
準備好試用異常檢測了嗎?請按照本教程操作:
-
試用 Data Visualizer
-
為 Kibana 示例數據創建異常檢測作業
-
利用結果識別數據中的潛在異常
在本教程結束時,你應該對機器學習有一個良好的了解,并希望能激發你使用它來檢測自己數據中的異常。
需要更多背景信息?查看 Elasticsearch 入門介紹,了解術語并掌握 Elasticsearch 的基本工作原理。
安裝
如果你還沒有安裝好自己的 Elasticsearch 及 Kibana,請參考如下的文章來進行安裝:
-
如何在 Linux,MacOS 及 Windows 上進行安裝 Elasticsearch
-
Kibana:如何在 Linux,MacOS 及 Windows 上安裝 Elastic 棧中的 Kibana
在安裝時,我們可以選擇 Elastic Stack 8.x/9.x 的文章來進行安裝。
啟動白金試用
機器學習運行于機器學習節點。這項功能需要訂閱才可以進行使用。更多訂閱方面的知識,請參考?訂閱 | Elastic Stack 產品和支持 | Elastic
在我們安裝完 Elasticsearch 及 Kibana 后,我們可以按照如下的步驟來啟動白金試用:
啟動白金試用,直到你看到上面的頁面顯示的信息!
添加數據到 Elasticsearch
我們使用 Kibana 中自帶的數據。按照如下的步驟來安裝數據:
這樣,我們就在 Elasticsearch 里創建了一個叫做?kibana_sample_data_logs 的索引:
探索 Kibana 中的數據
我們打開 Kibana,導航至 Machine Learning:
可選:你可以更改隨機采樣行為,這會影響 Data Visualizer 每個分片使用的文檔數量。你可以使用自動隨機采樣,在準確性和速度之間取得平衡;也可以使用手動采樣,自定義采樣百分比;或者關閉該功能,使用完整數據集。Kibana 示例數據中的文檔數量相對較少,所以你可以關閉隨機采樣。對于更大的數據集,請注意,使用較大的采樣規模會增加查詢運行時間并加重集群負載。
我們可以點擊上圖中的 clientip 字段來顯示各個 IP 地址的分布:
我們點擊 response.keyword 字段來查看各個響應代碼的分布情況:
我們點擊 url.keyword 字段來查看請求來自哪些地址:
對于數值字段,Data Visualizer 會提供關于最小值、中位數、最大值和最高值、不同值的數量以及它們的分布情況的信息。你可以使用分布圖更好地了解數據中的數值是如何聚集的。例如:
提示:記下 @timestamp 字段中的日期范圍。它們是相對于你添加示例數據的時間而言的,你稍后在教程中會需要這些信息。
現在你已經熟悉了 kibana_sample_data_logs
索引中的數據,你可以創建一些異常檢測作業來分析它。
提示:你可以在異常檢測向導中查看可選字段的統計信息。側邊彈出窗口中顯示的字段統計信息提供了更有意義的上下文,幫助你選擇相關字段。
在 Kibana 中創建示例異常檢測作業
重要:此頁面上的結果可能與你在使用示例數據集時實際獲得的值不同。這種行為是預期的,因為數據集中的數據點可能會隨著時間而變化。
Kibana 示例數據集包含一些預配置的異常檢測作業供你試用。你可以使用以下任一方法來添加這些作業:
方法一:
方法二:
向導會創建三個 job 和三個 datafeeds。
Datafeeds, buckets, 及?detectors
Datafeeds從 Elasticsearch 中檢索時間序列數據,并將其提供給異常檢測作業進行分析。
job 使用 bucket 將時間序列劃分為批次進行處理。例如,三個示例 Web 日志 job 都使用 1 小時的 bucket span。
每個異常檢測作業包含一個或多個 detector,它們定義了執行的分析類型(例如 max、average 或 rare 分析函數)以及要分析的字段。一些分析函數用于查找單個異常數據點。例如,max 會識別一個 bucket 中出現的最大值。其他函數則在整個 bucket 范圍內執行聚合操作。例如,mean 會計算 bucket 中所有數據點的平均值。
更多信息請參見 Datafeeds、Buckets 和 Function reference。
如果你想查看所有作業和數據提要的配置詳情,可以在 Machine Learning > Anomaly Detection > Jobs 頁面查看。或者,你也可以在 GitHub 上查看配置文件。不過為了本教程的目的,以下是每個作業目標的簡要概述:
-
low_request_rate 使用 low_count 函數查找異常低的請求速率
-
response_code_rates 使用 count 函數,并按 response.keyword 值分區分析,以查找按 HTTP 響應代碼分類的異常事件速率
-
url_scanning 使用 high_distinct_count 函數,對 clientip 字段進行群體分析,以發現訪問異常高不同 URL 數量的客戶端 IP
下一步是查看結果,了解這些作業生成了哪些類型的洞見!
查看異常檢測結果
在數據提要啟動且異常檢測作業處理了一些數據后,你可以在 Kibana 中查看結果。
提示:根據你機器的性能,可能需要等待幾秒鐘,機器學習分析才能生成初步結果。
機器學習功能會分析輸入的數據流,建立其行為模型,并根據每個作業中的 detector 進行分析。當事件偏離模型時,該事件被識別為異常。你可以立即看到所有三個作業都發現了異常,這些異常在每個作業的泳道中以紅色方塊顯示。
在 Kibana 中,有兩個工具可以用來查看異常檢測作業的結果:Anomaly Explorer 和 Single Metric Viewer。你可以點擊左上角的圖標在這兩個工具之間切換。你也可以編輯作業選擇,查看不同子集的異常檢測作業。
單指標作業結果
其中一個示例作業(low_request_rate)是單指標異常檢測作業。它只有一個使用 low_count 函數的 detector 和有限的作業屬性。如果你想判斷網站請求速率何時顯著下降,可以使用類似這樣的作業。
讓我們在 Single Metric Viewer 中先看這個簡單的作業:
-
在 Machine Learning 中選擇 Jobs 標簽,查看異常檢測作業列表。
-
點擊 low_request_rate 作業 Actions 列中的圖表圖標,在 Single Metric Viewer 中查看結果。
-
使用日期選擇器的相對模式,選擇起始日期為一周前,結束日期為一個月后,以覆蓋大部分被分析的數據點。
該視圖包含一個圖表,顯示實際值和預期值隨時間的變化。只有當作業啟用了 model_plot_config 時才可用。它只能顯示單個時間序列。
圖表中的藍線代表實際數據值。藍色陰影區域代表預期值的范圍。上下界之間的區域是模型最可能的值,置信水平為 95%。也就是說,有 95% 的概率實際值會落在該范圍內。如果值超出該區域,通常會被識別為異常。
如果你從數據開始滑動時間選擇器到結束,可以看到模型隨著處理更多數據而不斷改進。開始時,預期值范圍較寬,模型還未捕捉到數據的周期性。但它會快速學習并開始反映數據中的模式。
Anomaly scores
任何超出模型預測范圍的數據點都會被標記為異常。為了提供合理的結果視圖,每個 bucket 時間間隔都會計算一個異常得分。異常得分的范圍是 0 到 100,表示相對于之前觀察到的異常,該異常的重要性。高異常得分的值以紅色顯示,低得分的值以藍色表示。異常得分高的時間間隔非常重要,需要進一步調查。
將時間選擇器滑動到包含紅色異常數據點的時間段。如果你將鼠標懸停在該點上,可以看到更多信息。
注意:你可能會注意到時間序列中的一個高峰,但它沒有被標記為異常,因為這個作業只檢測低計數異常。
對于每個異常,你可以在查看器的 Anomalies 部分看到關鍵細節,如時間、實際值和預期(“typical/典型”)值,以及它們的概率。例如:
在 Actions 列中,有更多選項,比如 Raw data,會為相關文檔在 Discover 中生成查詢。你也可以在操作菜單中通過自定義 URLs 添加更多鏈接。
默認情況下,表格包含時間線上所選區間內所有嚴重性達到 “warning” 及以上的異常。例如,如果你只關注嚴重異常,可以更改此表的嚴重性閾值。
Anomaly explanation 部分提供每個異常的更多洞見,如異常類型和影響,方便你解讀作業結果。
你還可以在 Single Metric Viewer 中通過拖選一段時間來添加注釋,并寫入描述。注釋是指特定時間段內的事件備注,既可以由用戶創建,也可以由異常檢測作業自動生成,用于反映模型變化和重要事件。
識別出異常后,下一步通常是嘗試確定這些情況的背景。例如,是否有其他因素導致了問題?異常是否局限于特定的應用或服務器?你可以通過疊加更多作業或創建多指標作業開始排查這些情況。
高級或多指標作業結果
從概念上講,多指標異常檢測作業相當于運行多個獨立的單指標作業。但將它們捆綁在一個多指標作業中,你可以看到所有指標和實體的總體得分以及共享的影響因素。因此,多指標作業比許多獨立單指標作業擴展性更好。當檢測器間存在共享影響因素時,它們還能提供更好的結果。
Influencers
創建異常檢測作業時,你可以指定一些字段作為影響因素(influencers)。這些字段包含可能影響或導致異常的對象或信息。response_code_rates 和 url_scanning 作業中都有影響因素。
最佳實踐是不選擇太多影響因素。一般來說,選三個以內就足夠了。選太多會讓結果復雜難懂,且會增加分析開銷。更多詳情請參見 Influencers。
你還可以配置異常檢測作業,根據分類字段將單個時間序列拆分成多個時間序列。例如,response_code_rates 作業有一個 detector,根據 response.keyword 拆分數據,然后使用 count 函數判斷事件數量是否異常。如果你想按響應代碼查看高低請求率,可以使用這樣的作業。
我們先在 Anomaly Explorer 中查看 response_code_rates 作業:
-
在 Machine Learning 中選擇 Jobs 標簽,查看異常檢測作業列表。
-
點擊 response_code_rates 作業行中的圖標,打開 Anomaly Explorer 查看結果。
-
對于該作業,你可以選擇為每個 client IP 或響應代碼顯示單獨的泳道。例如:
因為該作業使用 response.keyword 作為分區字段,分析會針對該字段的每個不同值分別建立獨立的基線。通過按實體查看時間模式,你可能會發現合并視圖中隱藏的異常。
在異常時間線下方,有一個包含注釋的區域。你可以使用注釋部分右側的選擇器來篩選事件類型。
在 Anomaly Explorer 左側,有一個列表顯示該時間段內所有檢測到異常的主要影響因素(influencers)。該列表包括最大異常得分,這些得分是在所有 detector 的每個 bucket 中,為每個影響因素匯總的。此外,還顯示了每個影響因素的異常得分總和。你可以利用這個列表幫助縮小可能的原因,關注最異常的實體。
點擊泳道中的某個區段,可以獲取該時間段內異常的更多信息。例如,點擊 response.keyword 值為 404 的泳道中的紅色區段:

你可以看到異常發生的具體時間。如果作業中有多個 detector 或指標,你還能看到是哪個捕捉到了異常。你還可以通過點擊操作菜單中的“ View Series” 按鈕,切換到 Single Metric Viewer 查看該時間序列。
圖表下方有一個表格,提供更多信息,比如典型值和實際值,以及促成異常的影響因素。例如:
如果你的作業有多個 detector,表格會匯總異常,顯示每個 detector 和實體(即 “found for” 列中顯示的字段值)中嚴重性最高的異常。要查看所有異常且不進行匯總,可以將 Interval 設置為“Show all”。
在此示例數據中,404 響應代碼的激增受特定客戶端影響。類似情況可能表明該客戶端正在訪問異常頁面或掃描你的網站,試圖訪問異常的 URL。這種異常行為值得進一步調查。
提示:你在 Anomaly Explorer 每個部分看到的異常得分可能會有些差異。這是因為每個作業都會生成 bucket 結果、influencer 結果和 record 結果,每種結果都會計算異常得分。異常時間線使用的是 bucket 級別的異常得分,主要影響因素列表使用的是 influencer 級別的異常得分,異常列表使用的是 record 級別的異常得分。
群體作業結果
最后一個示例作業(url_scanning)是一個群體異常檢測作業。正如我們在 response_code_rates 作業結果中看到的,有一些客戶端似乎正在訪問異常數量多的 URL。url_scanning 示例作業提供了另一種方法來調查此類問題。它有一個 detector,使用 high_distinct_count
函數作用于 url.keyword
字段,以檢測該字段中異常多的唯一值數量。然后,它會分析這種行為是否在以 clientip
字段定義的客戶端群體中表現出差異。
如果你在 Anomaly Explorer 中查看 url_scanning 異常檢測作業的結果,會發現其圖表格式有所不同。例如:
在這個例子中,每個 client IP 的指標是相對于同一 bucket 中其他 client IP 來分析的,我們再次看到 IP 為 30.156.16.164 的客戶端行為異常。
如果你還想嘗試另一個群體異常檢測作業的例子,可以添加示例電子商務訂單數據集。它的 high_sum_total_sales
作業用于判斷哪些客戶在某個時間 bucket 中的購買金額相對于其他客戶而言異常。在這個示例中,有兩個客戶被發現存在異常事件:
創建預測
除了檢測數據中的異常行為,你還可以使用機器學習功能來預測未來的行為。
在 Kibana 中創建預測的方法如下:
1)在 Single Metric Viewer 中查看你的作業結果(例如 low_request_rate 作業)。在 Anomaly Detection 頁面中點擊 Actions 列的 View series 按鈕即可進入該視圖。
2)點擊 Forecast。
3)指定預測的持續時間。該值表示從最后一個被處理的記錄開始,向未來預測多遠。你必須使用時間單位。在這個例子中,持續時間是一周(1w
):
4)在 Single Metric Viewer 中查看預測結果:
圖表中的黃色線表示預測的數據值。黃色陰影區域表示預測值的上下邊界,也反映了預測的置信度。注意,隨著預測時間越長,邊界通常會變寬(也就是說置信度降低),當置信度過低時,預測將停止。
5)可選:將預測結果與實際數據進行對比。
隨著作業處理更多數據,你可以再次點擊 Forecast 按鈕,選擇將某個預測結果疊加在實際數據上進行查看。圖表中將同時顯示:實際數據值、期望值的上下邊界、異常點、預測數據值,以及預測值的上下邊界。這種實際數據與預測數據的組合可以幫助你判斷機器學習功能對未來行為的預測能力。
如果你想在 Kibana 示例數據上查看這種對比效果(該數據集文檔數量有限),可以在創建預測前重置作業并只分析部分數據。例如,在 Kibana 的 Job Management 頁面重置一個異常檢測作業,或使用 reset anomaly detection jobs API。重新啟動該作業的數據提要時,選擇一個位于示例數據中段的日期作為搜索結束日期。默認情況下,數據提要在到達該日期時停止,異常檢測作業也會關閉。此時創建預測。然后,你可以重新啟動數據提要,處理剩余數據,從而生成如上述所示的結果。
提示:Kibana 示例數據集的時間戳是相對于你添加數據集的時間生成的,不過其中一些日期位于未來。因此,在本教程中,當你重新啟動數據提要時,不要使用 “No end time (Real-time search)” 選項。請指定合適的結束日期,以便立刻處理全部數據。
現在你已經看到使用示例數據創建預測是多么簡單,可以考慮在你自己的數據中想要預測哪些類型的事件。想了解更多信息和思路,請參閱 Forecast future behavior。