使用 Kibana Alerts 主動通知異常狀況
Last updated
Last updated
使用 Kibana Alerts 之前的準備工作。
了解 Elastic Observability 針對 Kibana Alerts 的整合上有提供哪些 Alert 的設置。
在使用 Kibana Alerts 之前，有以下幾點需要注意及準備的項目：
由於 Kibana 中的敏感資料和 Alerting Rules (警報規則)，儲存時都會進行加密，所以要先準備好加密的密鑰。
密鑰需設定在 kibana.yml 中的 xpack.encryptedSavedObjects.encryptionKey 設定之中，以下是協助產生密鑰的工具及指令：
要讓 Alert 發送通知到外部之後，可以透過連結導回 Kibana，所以會需要設定好外部存取 Kibana 時有效的 Base URL，設定在 kibana.yml 中的 server.publicBaseUrl 。
如果有啟用 Elastic 的 Security 功能時，必須要設定並啟用 TLS 連線。(可參考 )
為了在背景執行的處理程式能安全的存取 Elasticsearch，Kibana alerting 會使用 API key 的安全認證機制，而要使用 API key 的話，就一定要啟用 TLS。
要讓 Elasticsearch 與 Kibana 之間使用 TLS 連線，會有以下幾個設置步驟：
使用 elasticsearch-certutil 配合 http 參數，來建立 TLS 相關的 certificate。
如果你的環境之中沒有 CA (Certificate Authorities)，又或是先前沒有建立過 CA 的話，會要先透過 bin/elasticsearch-certutil 配合 ca 參數來建立 CA。
建立完成 http 使用的 certificate 之後，壓縮檔裡面會有以下的內容：
將 kibana/elasticsearch-ca.pem 檔案，複制到 Kibana 的 config 目錄中，並修改 kibana.yml 中 的 elasticsearch.ssl.certificateAuthorities 設定，以及將 Elasticsearch 的 protocol 改成 HTTPS：
同時也要確保 Elasticsearch 也啟用 TLS 連線有正確設定，並且將先前產生的 http.p12 複制到 config 目錄底下。
重新啟動 Elasticsearch 與 Kibana 。
Kibana Alerts 有支援多種的 Connectors 如下：
寄 Email
寫入 Elasticsearch Index
建立 Jira incident
PageDuty
Slack
Webhook
IBM Resilient
Microsoft Teams
寫到 Kibana 的 ServerLog
建立 ServiceNow incident
建立 Swimlane incident
這些 Connector 建立好之後，就會是 Alert 最後要發送通知時的接口。
Elastic Observability 的功能之中，有針對 Alerts 進行整合，也就是在 Observability 的 UI 當中，針對該服務的特性，有建立能較快速建立 Alerts Rules (規則) 的功能，以下針對 Alerts 設置的部份進行說明。
Log 的部份，能快速針對 Log threshold (門檻) 進行 Alerts 的設置，設置重點如下：
在一段時間區間之中，針對一個特定條件下的 logs 數量，或某兩種條件之間的 logs 數量的比例，達到一個門檻時，發出 alert。
同時這個計算時，能依照特定欄位的值來進行分群 (group by)，也就是上述的規則可以限定在某些條件的分類上執行，例如每台機器分開計算、或是每種服務分開計算。
Metrics 在 Inventory 與 Metric Explorer 的頁面當中，分類提供不同的 Alerts 設置。
在 Inventory 當中，關注的重點就是 Infrastructure，不論是 Host、Docker、Kubernetes 或是 AWS 雲端主機或服務。
所以針對 Inventory 的部份，Alerts 的主要設置重點如下：
當指定的主機或服務，在最近一段時間內，在任何 metrics 的條件下 (例如：CPU 或 Memory 使用率、網路流量、Log rate、甚至是任何一個欄位的平均數…等) 達到指定的門檻時，就發出 Alert。
除了以上的 metrics 條件外，若是在最近一段時間內，沒有任何的 logs 產生，也可以發出 Alert。
另外除了 Alert 的報警之外，也可以定義 Warning 層級的條件。
與 Metrics 中 Alert 設定的差別，主要在於 Inventory 會指定主機或服務相關的範圍。
在 Metric 的部份，主要的設定如下：
支援任何所收集到的 Metrics，在最近的一段時間內，若達到一定的門檻，就發送 Alert。
若是在最近一段時間內，沒有任何的 logs 產生，也可以發出 Alert。
也能支援設定 Warning 的門檻。
在 Uptime 的部份，主要的 Alert 設定有以下三種：
Monitor status: 服務的可用性是否正常。
TLS certificate: 憑證是否快過期。
Uptime duration anomaly: 服務的回應時間是否異常。
在 Monitor 的頁面之中，Uptime 最主要的任務就是確認服務是否還活著，因此 Alert 的設定重點為：
Status Check，在一小段時間區間，如果服務沒有依照預期的結果回應並且超過一定的數量，就發出 Alert。
Availability，在較長的一段時間區間 (例如一個月)，如果服務總共異常超過某個比例 (例如 99.9%)，就發出 Alert，可用作 SLA 的警示。
TLS Certificate 的 Alert 很單純，就只有一個重點：
在 Certificate 剩一段時間就要過期時，發出 Alert。
在 Uptime Monitor 的頁面中，如我們前一篇文章的介紹，可以開啟 Machine Learning 的 Anomaly detecion 的功能。
一但開始這個功能之後，就可以在 Monitor 的回應時間被判定成異常時，主動發送 Alert。
點選 Enable anomaly alert 後的設定畫面如下：
在 Kibana > Stack Management > Rules and Connectors > Connector 裡可以進行設定，有些與 Security 相關的，可能會要使用到 keystore 來保存密鑰，細節相關的設定，可以參考 的說明。
設定細節可以參考 。
設定細節可以參考 。
設定細節可以參考 。
設定細節可以參考 。
設定細節可以參考 。
設定細節可以參考 。
