3.12.6 自學Zabbix3.12.6-動作Action-Escalations配置
1. 概述
Escalation 的意思是“增大，擴大”，在Zabbix中，它指的意思是一個報警在一定條件下，會執行一些額外 的操作，比個比方，一台服務器磁盤滿了，可能馬上需要通知的是一線的運維工程師。如果6小時后都沒人處理，這個故障且還沒恢復，那么可能就要匯報給經理了。 或者，PHP進程掛了，可能首先是重啟PHP進程，那么如果過了一段時間這個故障還沒有恢復（即PHP進程沒有重啟成功），那么就要通知攻城師來進行恢復了。 這是一個報警擴散的過程，即Escalation 。
Zabbix中，支持的Escalation有以下幾種：
-
發生問題后，第一時間通知用戶。
-
在解決問題前，每隔一段時間就向用戶報警。
-
延遲報警。
-
報警可以升級，發送給更多的用戶。
-
Remote command可以在時間發生后馬上執行，也可以在一定時間沒有解決后才執行。
-
可以向用戶發送恢復通知。
可以定義一個“Escalation Step”，意為“擴散步驟”，定義何時擴散報警，以及如何擴散。
每一個步驟可以定義一個Action和持續時間。步驟要在報警后馬上發出，步驟個數沒有限制，Zabbix只會從第一個開始逐個執行。
Escalation是一個比較復雜的機制，特別是跟其他東西結合起來后，下面看一些常見情況：
-
出問題的Host在發出第一個報警后進入了Maintainence狀態：這個Action剩余的Escalation Step都會被執行。Maintainence狀態不會停止Operation，只會對Action有關系簡單的說，一旦這個Action被執行，那么其中的每一步都會執行。
-
在Time period中定義的時間在發出第一個報警后就結束了：同（A）中的情形，Time period也只會影響Action執行與否，而不會影響Action中的Operation執行與否。
-
在Maintainence狀態時發生了問題，並且在Maintainence狀態結束后依然沒有恢復：所有Escalation Step都是從Host（或者其他）結束Maintainence狀態后開始。
-
當Host在no-data Maintainence狀態時發生問題，在結束no-date Maintainence狀態時，這個問題還沒有恢復：Trigger 的觸發，一定是先於Escalation Step的開始。
-
不同的Escalation Step非常接近相互有重疊的部分：沒一個Escalation都會接替之前的Escalation，但是由於步驟（A）是在問題發生后馬上執行的，所以“之前的Escalation”至少會執行一個動作。這些行為跟Evnet 和 Action相關。
-
在Escalation執行過程中，Action被禁用了：正在發送過程中的信息和之后的那一條信息會被發送。其中后面的那條信息會在發送的信息之前加上“NOTE：Escalation cancelled：action‘<Action name>’ disabled”。這樣，用戶就會知道Action已經被禁用了，之后也不會受到關於這個Action的消息了。
2. 幾個示例
示例1：
要求每隔30分鍾向“MySQL Administration”的User group發送一次報警，一共發送5次。
-
在Action的Operation標簽中，將“Default operation step duration”（默認操作時間間隔）設置為1800秒，即要求中的30分鍾。
-
在Steps的地方設置為“From 1 to 5”，表示Escalation Step的第一步到第五步都是執行這個操作。
-
選擇“MySQL Administration”組作為發送報警的收件人。
通過這樣的設置，假設Action是0點0分觸發的，那么在0點30分，1點，1:30，2:00 都會將報警發送給“MySQL Administration”用戶組中的所有用戶，當然，如果在這個過程中，Trigger 恢復了，那么就會打斷這些事件。
示例2：
如果示例1中的問題一直沒有解決，我們希望吧這個問題通知到更加資深的DBA，可以進行下面的設置。
-
在Operation標簽中，將默認時間設置為36000秒，即10個小時。
-
將escalation steps設置為“From 2 to 2”，意思就是只在第（2）步中執行。
在問題發生后，如果10個小時還沒恢復，那么這個問題就會通知到資深DBA，可以在發送消息的內容中加上類似“這個問題已經10個小時沒有處理”之類的話，提醒收到告警的工程師去解決。
示例3：
當出現問題時，先通知MySQL Administration，如果問題持續10個小時，將這個問題發送給DBA經理，如果還解決不了，會嘗試重啟數據庫。 如果依然解決不了，那么只能郵件通知用戶，最后使用IPMI命令，重啟MySQL服務器。
示例4：
最后看一個自定義Duration的例子，先看是如何設置Action的。
假設問題是在00:00發生的，那么它的執行順序如下。
-
在00:00、00:30、01:00、01:30 會向Zabbix administrators用戶組發送郵件，這是由於我們設置了默認的時間間隔是1800秒，即30分鍾。
-
在02:00 和 02:10向Admin發送郵件。
-
在02:00 、02:10 和 02:20 執行遠程命令。
-
在04:00 向Admin 發送郵件。
這里有幾個理解起來比較麻煩的地方，一個是在圖中，只有02:00 和 02:10 時才會向 Admin發送郵件，而不會在03:00，這是因為在圖中 5-6和5-7都設置了Operation，那么5-7中設置的600秒就會覆蓋5-6中設置的3600秒。在條目3中，因為設置的600秒生效，所以每隔10分鍾向Admin發送一次郵件。 在條目4中，由於經過了8、9、10、11則這4個Step，所以是默認的30分鍾的4倍，即2個小時，到04:00，向Admin發送報警。