創作人：金端/扈臣聰
審稿人：周海清
Kibana 的 Alert 子產品主要用于 Elastic Stack 的監控告警。以一種相對較低的使用成本，将複雜的查詢條件，編輯完成後監控不同的 Elastic Stack 的技術産品中産生的資料，最終把符合條件的告警資訊以需要的方式回報給使用者。
Alert 的組成
Alert 主要由三個部分組成：
Condition 條件
也是 Alert Type，檢測需要執行的查詢或者統計。
Condition 的概念執行主要由 alert type 承擔。Alert Type 通過簡單的參數設定将涉及 Elasticsearch 的查詢結果和其它資料源的複雜計算完美實作。比如：監控的程式 APM 資料2分鐘内 CPU 使用均值高于0.9；某個業務資料索引中，10分鐘内購買失敗次數占比超總量的30%等等.
Schedule 檢測周期
Alert 的執行周期。Schedule 的設定按照每隔多久循環來設定，從每秒到每月不等，但并不能設定具體哪月哪天。
Action 告警動作
即滿足告警條件後需要執行的操作，主要是将需要的告警資訊發送給第三方系統，在 Kibana 背景執行。
Action 可以分解為三個要素：
- action type，發送的第三方系統類型定義。
- connection，告警發送的連接配接資訊，比如email的host和端口等
- properties，告警資訊所需要引用的參數值。
Alert 與 Elasticsearch 的 Watcher不同的是，Alert 運作在 Kibana 而不是 Elasticsearch，相關任務資料也是存儲在 Kibana 的索引中，而 Elasticsearch 的 Watcher 資料則是在 Watcher 的索引中。
在更高的層次上，Kibana Alert 允許跨用例（如 APM、Metrics、Scurity 和 Uptime）進行豐富的內建。預先打包的 Alert Type 簡化了設定，隐藏了複雜的檢測細節，同時提供了跨 Kibana 的一緻接口。
Alert Instances 的概念和抑制重複告警
在檢查一個 condition 條件時，Alert 可能會識别該條件的多次出現。每出現一次符合 condition 條件的情況，Kibana 就生成一個 Alert Instances，即警報執行個體。那麼 Kibana 分别跟蹤每個警報執行個體，并對每個執行個體采取行動。
重複告警
以下面的圖示例，将每個平均 CPU 為> 0.9 的伺服器作為 Alert Instance 進行跟蹤。然後将每個超過門檻值的伺服器都将發送單獨的電子郵件。
那就會帶來一個問題，當 Alert Instances 過多的時候，就會造成大量通知重複發送，即 Alert Noise 的現象。
比如一個警報每分鐘監控三個伺服器的 CPU 使用情況> 0.9，就發送郵件通知從業人員:
- 第一分鐘：伺服器 X123 的 CPU > 0.9。
其中一封郵件發送通知從業人員伺服器 X123 的 CPU 過高。
- 第二分鐘：X123 和 Y456 的 CPU > 0.9。
發送了兩封郵件，一封是關于 X123 的，一封是關于Y456的。
- 第三分鐘：X123, Y456, Z789 的 CPU > 0.9。
發送了三封郵件，分别是 X123，Y456，Z789。
在上面的例子中，對于相同的條件，在3分鐘的時間内，向伺服器 X123 發送了3封郵件。
抑制重複告警
Kibana 針對這個情況做了抑制重複通知的優化，主要是通過設定通知間隔來抑制重複多餘的告警。比如在上面的例子中，将警報重新通知間隔設定為5分鐘，那麼 Alert 發送通知的情況則如下：
- 第一分鐘：伺服器 X123 > 0.9
郵件發送報告伺服器 X123 的 CPU 過高；
- 第二分鐘：X123 和 Y456 > 0.9
郵件發送報告伺服器 Y456 的 CPU 過高；
- 第三分鐘：X123, Y456, Z789 > 0.9
郵件發送報告伺服器 Z789 的 CPU 過高。
當然過了五分鐘後，如果伺服器 X123 > 0.9還是存在，那麼繼續會發送郵件，報告伺服器 X123 的 CPU 過高。
Kibana Alert 的實作機制
Kibana Alert 将 Alert Check 的資訊和 Action 的資訊，持久化在 Elasticsearch 在背景執行。這有兩個主要好處:
- 持久性：所有的任務相關的資訊都存儲在 Elasticsearch 中，是以如果 Kibana 重新啟動，Alert 和 Action 将從它們停止的地方恢複；
- 伸縮性：多個 Kibana 執行個體可以從 Elasticsearch 中讀取和更新相同的任務隊列，允許 Alert 和 Action 跨執行個體分布。如果現有的 Alert 執行數量超出了現有的 Kibana 執行個體的容量上限，可以增加額外的 Kibana 執行個體。
Kibana 背景任務的執行機制
- 每隔3秒輪循 Elasticsearch 任務索引以查找過期任務；
- 任務執行後在 Elasticsearch 索引中更新，使用樂觀并發控制來防止沖突；
- 任務在 Kibana 伺服器上運作。每個 Kibana 執行個體最多可以運作 10 個并發任務，是以每個間隔最多可以聲明 10 個任務；
- 對于重複背景檢查的 Alert，任務完成後将按照檢查間隔再次排程。
因為每3秒輪詢一次任務，并且每個 Kibana 執行個體隻能同時運作10個任務，是以 Alert 和 Action 任務可能會在以下情況延遲運作：
- 警報使用較小的檢查間隔。最低間隔時間可能是 3 秒，但建議間隔時間為 30 秒或更高
- 許多警報或操作必須同時運作。在這種情況下，挂起的任務将在 Elasticsearch 中排隊，并且每隔 3 秒從隊列中取出 10 個任務
- 長時間運作的任務占用槽位的時間較長，留給其他任務的槽位較少
完整的 Alert 流程
Alert 由 Condition（條件）、Action 和 Schedule 組成。當條件滿足時，就會建立警報執行個體來呈現和調用操作。為了使 Action 設定和更新更容易，Action 包含了與第三方連接配接互動的 Connector 。
下面的例子将這些概念聯系在一起:
- 隻要警報的條件得到滿足，就會建立一個警報執行個體。這個示例檢查平均 CPU 為 > 0.9 的伺服器。三個伺服器滿足條件，是以建立了三個執行個體；
- Action 執行時，警報中設定的模闆将被實際值填充。在這個示例中，建立了三個操作，模闆字元串 {{server}} 被替換為每個執行個體的伺服器名；
- Kibana 調用這些 Action，将它們發送給第三方內建，比如郵件服務；
- 發送這些資訊時，Action 會結合 Connector 中設定的資訊發送。比如：郵件的 host/port/使用者名/密碼。
如何配置 Alert
目前 Kibana 提供了一種内置的警報類型：索引門檻值類型（index threshold）。索引門檻值警報類型，允許您指定要查詢的索引、聚合字段和時間視窗。但底層 Elasticsearch 查詢的詳細資訊是隐藏的。根據設定的查詢條件，将結果與門檻值進行比較，并在滿足門檻值時進行後續的排程執行。
操作示範
在 Stack management 的 Alert 中 Create alert，建立一個名為 test-alert 的告警。該告警用于檢查索引test-es中fail_num的累計數量，test-alert每分鐘檢查一次，最多5分鐘告警通知一次，标簽為test。
索引test-es的資料如下：
PUT test-es
POST test-es/_mapping
{
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis"
},
"fail_num" : {
"type" : "long"
},
"user" : {
"properties" : {
"id" : {
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
}
}
}
}
}
POST _bulk
{ "create" : { "_index" : "test-es", "_id" : "1" } }
{ "@timestamp" : "2021/04/20 23:30:30" ,"user.id":"may","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "2" } }
{ "@timestamp" : "2021/04/20 23:33:31" ,"user.id":"may","fail_num":"4"}
{ "create" : { "_index" : "test-es", "_id" : "4" } }
{ "@timestamp" : "2021/04/20 23:46:30" ,"user.id":"jack","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "5" } }
{ "@timestamp" : "2021/04/20 23:50:30" ,"user.id":"may","fail_num":"6"}
{ "create" : { "_index" : "test-es", "_id" : "6" } }
{ "@timestamp" : "2021/04/20 23:49:30" ,"user.id":"jack","fail_num":"3"}
{ "create" : { "_index" : "test-es", "_id" : "7" } }
{ "@timestamp" : "2021/04/20 23:49:30" ,"user.id":"jack","fail_num":"3"}
{ "create" : { "_index" : "test-es", "_id" : "8" } }
{ "@timestamp" : "2021/04/20 23:50:30" ,"user.id":"bill","fail_num":"9"}
{ "create" : { "_index" : "test-es", "_id" : "9" } }
{ "@timestamp" : "2021/04/20 23:52:30" ,"user.id":"jack","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "10" } }
{ "@timestamp" : "2021/04/20 23:53:30" ,"user.id":"jack","fail_num":"1"}
選擇 Index threshold
配置 condition 條件為：監控索引 test-es 中10分鐘内，如果 fail_num 總計超過5次則告警。
其中，WHEN 條件可選擇為 count，average，sum，min 和 max。
count 為統計文檔數，不需要填寫字段，其餘方法會自動比對出可計算類型的字段，比如 long 類型。
OVER 條件可以配置聚合全部文檔或者分組。如果使用了分組，即 top，那麼當每個組超過門檻值時，将為每個組建立一個 Alert Instance。在配置中，top 會設定分組數量，限制高基數字段上的執行個體數量。比如上圖中隻檢查 user.id.keyword 數量最多的3組。
相關的查詢結果會有一張時序圖來展現，如下圖：
從圖中看出前三個是 may 6次、jack 9次、bill 9次。
再設定一個 Action，此處是寫進索引 alert-record
儲存後，過段時間 Alert 的詳情裡就有了 Alert Instance 的相關資訊。
其中 Status 為 Active 的是待執行 Action 操作的。不管 Alert Instance 在被監控判斷的期間是否被靜音( Mute )，最終狀态都為 OK。
關于 Actions
預設定 Connector 和 Action
可以在 kibana.yml 中預設值 Connector 或者 Action Type。
預設 Connector 需要将配置和相關證書設定清楚，不可以數組對象的形式設定，且配置完以後不可修改。相比之下在 Kibana 啟動後，再設定 Connector 相對靈活許多。
Connector 和 Action 的具體配置可參考官方網站。
Action 的變量傳入
在設定 Action 時，根據 Action Type 的不同，會設定不同的 properties。比如，email 配置 Subject 和 Message；Index 提供 document。具體細節參考每個類型的具體 action 配置。
雖然各個 Properties 不一樣，但是在配置時都可以把 Alert 中監控到的資料，作為變量傳入報警資訊中。使用 Mustache 模闆文法 {{variable name}}，可以在檢測到一個 Condition 時将警報值傳遞給一個 Action。
可用的變量因 Alert Type 不同而不同，可以使用 "Add variable" 按鈕來通路清單。
下圖是 email 的可傳入參數：