自學Zabbix3.12.6-動做Action-Escalations配置

點擊返回：自學Zabbix之路

點擊返回：自學Zabbix4.0之路

點擊返回：自學zabbix集錦

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中，因爲通過了八、九、十、11則這4個Step，因此是默認的30分鐘的4倍，即2個小時，到04:00，向Admin發送報警。