透過 Machine Learning 發現異常的問題

本篇學習重點

了解 Elastic Observability 中，透過 Machine Learning 可以得到什麼樣的協助

Elastic Stack 中的 Machine Learning

AIOps 這個議題在近幾年愈來愈火紅，以往我們總是只能透過進行監視、建立好規則觸發警報，來了解系統是否發生異常，但若是我們沒有自己觀察到的部份，或是規則沒有定義清楚的地方，往往很難有效且即時的發現問題，一般都是等到造成更嚴重的影響，嚴重到我們被通知道，我們知道有發生問題，而透過 Machine Learning 的能力，就是希望能在更嚴重的災情發生之前，我們就能主動被提醒是否有異常，進而防止災情的發生。

要說到 Elastic Stack 中所使用到 Machine Learning 的能力，主要有個兩部份：

Anomaly Detection (異常偵測)：主要是針對隨時間增長的數據，透過不斷收集新的資料來進行非監督學習 (unsupervised learning) 並創建正常行為的模式，使用這個模式比對新進來的資料，判斷是不是有異常的狀況發生。
Data Frame Analytics (資料框分析)：使用 data frame 的方式進行資料分析，並且提供 outlier detection (異常值分析)、regression (回歸) 演算法、classification (分類) 的三種方式。

由於我自己本身對 Machine Learning 這部份並不熟悉，因此也不便多做說明，有興趣的可以查看官方文件 - Machine Learning。

在 Elastic Observability 中使用 Machine Learning

雖然我對於 Machine Learning 不熟悉，同時也聽過不同的評論表示 Elastic Stack 裡使用到的 Machine Learning 只是基本的能力，並沒有太過華麗，不過或許是這樣反而更容易讓非 Machine Learning 專業的人上手，同時所關注的點會是在如何能確實的協助我們在 Observability 這件事情上。

接下來我就從 Elastic Observability 當中的四大功能 Logs、Metrics、Uptime、APM ，裡面所使用到 Machine Learning 的部份來進行說明。

Logs

首先在 Logs 的畫面中，功能表中就有 Anomalies 與 Categories 的選項，這兩個功能都是透過 Machine Learning 的能力所執行的功能，主要能協助我們做到：

某種類型的 Logs 數量發生異常 (變多、變少、突然出現)。
特定行為的 Logs 數變多，例如某個 IP 突然有大量的存取，並且告訴我們異常的時間區段在哪邊。
除了 Machine Learning 本身的機制能通知我們之外，因為有 Categories 將 Logs 進行相似的分類並使用視覺呈現，我們也可以更容易的透過肉眼來檢視是否有異常狀況發生。

Anomalies

Logs 的 Anomaly 主要是針對 log entry rates (輸入率) 來進行異常的判斷。

第一次進入時，會需要建立 Machine Learninng 的 job (工作)，只需要選擇起始的時間，以及針對哪個 indes 進行處理即可。

當 ML job 開始執行後，同時也收集一段時間的資料之後 (一般來說有二週以上的資料會較準確)，我們在 Anomalies 可以看到，針對不同的 dataset (這個欄位是 Elastic Common Schema 所定義的，同時也就是 ECS 正規化的好處)，在不同的時間點，有哪些可能是異常的狀態。

並且會用簡單的分數來協助我們判斷，並且在 Anomaly 可以直接看到異常的描述。

針對底下的項目展開，可以看到最近幾則判定為異常的 events 的原始 logs 長什麼樣子，從上圖的時間軸，也能快速的針對這段有異常的時間區段來設置時間的篩選，也能進一步跳轉到 Elastic Machine Learning 功能的 Anomaly Explorer 畫面進行深入的分析。

Metrics

Metrics 裡使用 Machine Learning 主要可以協助我們針對 Metrics 數據判斷是否有異常，例如：

CPU 或 Memory 用量突然增加
某個服務的網路存取量異常高
某台 host 沒有 inbound 的流量

而 Metrics 裡要啟用 Machine Learning，是在 Inventory 裡面來啟用，並透過右上角的 Anomaly detection。

同樣的設定上也相當單純，選擇起始的時間，並且指定是否有要使用哪個欄位值來做 partition。

至於檢視異常狀況，也是透過右上角的 Anonmaly detecion 的選項，同時點選 Anomalies 的頁籤，可以看到 Machine Learning 協助判斷出來的異常資訊。

透過 Actions 的選單，可以快速的跳到 Anomaly Explorer 或是在 Metrics 的 Inventory 畫面中檢視。

點選 Show in inventory 之後，會直接帶入篩選值，以及切到時間到異常發生的時段。

Uptime

在 Uptime 裡，Machine Learning 主要協助的是：

某次請求的回應時間，是否與先前相比異常。

設定啟用 Anomaly detection 的方式，是要進入某個定義好的 Monitor 項目之中：

點選進入之後，在 Monitor duration 的畫面裡，可以看到 Enable anomaly detection 的選項。

一旦啟用對後，若有回應時間特別久的異常發生，在 Monitor duration 裡就可以直接看到。

APM

APM 的部份，與 Machine Learning 有較完整的 APM anomaly detection 的整合，針對

Span
Transaction Duration
Error
Throughput
User Agent 的特定屬性行為

上述的各項都有較完整的整合，這部份的資訊可以參考官方文件 - Machine Learning - APM anomaly detection integration。

而設定的部份，也是在右上角的 Anomaly detection 進行設定。

而異常發生時，在 APM 的相關畫面都能看到標示，Service 頁面會出現 Hearth 的欄位：

Transaction 的畫面會將異常 Duration 的區段標示出來：

Service Map 當中，有異常的服務也會變成黃色或紅色，點選下去也會出現異常的分析資訊：

以上的介紹，是針對 Elastic Observability 中，透過 Machine Learning 在 Logs、Metrics、Uptime、Traces 裡整合的相關功能說明，有興趣的朋友可以進一步的從官方文件 - Machine Learning 查閱 Machine Learning 的進階用法，特別是 Anomaly Explorer 裡面擁有更多詳細的功能，對於異常的深入分析會有所幫助。

參考資料

Previous有效的使用 Observability 的資料 Next使用 Kibana Alerts 主動通知異常狀況

Last updated 4 years ago