Zabbix 監控之 - 警示篇 Actions

標籤：zabbix 警示 action 郵件 簡訊 警示 監控警示

通常，一個警示的產生，是這樣的一個過程。

如果某種條件符合，那麼警示。

抽象成電腦語言，就是：

if (ConditionA == true){Alet();}

還可以選擇給誰警示（哪個使用者）、怎樣警示（警示途徑），具體如下：

if (ConditionA == true){Alert(userA.email);Alert(userB.sms);}

如果處理問題不一定要警示，可以在伺服器對於一些簡單問題上運行一些命令的初步處理，比如Nginx掛了，自己就可以嘗試的重啟服務，則這又成了：

if (ConditionA == true){Alert(email);Alert(sms);Excute(command);}

再擴充一些，可能條件更複雜一些：

if (ConditionA == true && ConditionB != true){Alert(email);Alert(sms);Excute(command);}

這就是Zabbix的“警示”了，為什麼這裡的“警示”需要加上引號呢？ 其實，發生問題後，去執行一些命令，這已經不是狹義上的“警示”了。在Zabbix 中，這個被定義為Action（動作） ，就是當某種Condition符合時，會進行一些操作，這些操作就叫做Action。 Condition譯為“條件”，在Zabbix中，Action的觸發是需要條件的，比如屬於某個Host Group的Host，某個Trigger是Problem狀態了，等等，，

在Zabbix中，警示的途徑是依附於使用者的。即不能直接將一個Action設定為給某個郵箱發郵件，一定要設定Action向某個使用者發送警示，發送警示的途徑是郵箱，那麼就會發送到使用者的預先設定郵箱地址。 這個郵箱地址叫做使用者的Media ，即連絡方式。

下面來介紹Action的設定。

1，Action

 Action是Zabbix非常強大的功能，可以基於Event的不同狀態，執行不同的操作。 最常見的就是警示時，將警示通過各種方式發送給對應的使用者。

 目前Zabbix支援Action動作根據下面所列出的Events觸發。

• Trigger Events：當Trigger的狀態變化，即從OK 到 Problem 或從 Problem 到OK時都會產生。

• Discovery Events：當發生網路Discovery的時候產生。

• Auto Registration Events： 當有新的Zabbix Agent自動註冊到Zabbix的時候產生。

• Internal Events：當Item變為“異常”狀態 或者Trigger變為“未知”狀態時產生。

  
  

  
  

下面進入Action的配置。

1. 從功能表列的“Configuration” → “Actions” 進入介面。

2. 在“Event source”下拉框中，可以選擇只顯示依賴於某種源頭的Action。

3. 單擊Action條目後，可以看到三個標籤：“Action”、“Condition”、“Operations”。 “Action”用來定義Action本身的一些屬性和說明；“Condition”用來定義觸發Action的各種條件組合關係；“Operations”定義的是Action觸發後的一些操作。

預設是建立基於Trigger Events的Action，如果需要其他的，選擇對應的選項即可。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/74/2E/wKiom1YWgw6x0uVpAADDx7yEPNM913.jpg" title="1.png" alt="wKiom1YWgw6x0uVpAADDx7yEPNM913.jpg" />

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/74/2C/wKioL1YWg9jwQxt4AAKW0dERClA180.jpg" title="2.png" alt="wKioL1YWg9jwQxt4AAKW0dERClA180.jpg" />

“Action”標籤，有下面的屬性可以設定。

• Name：唯一的Action名字。

• Default subject：警示的預設標題。

• Default message：警示的預設內容。

• Recovery message：恢複訊息，是否在警示恢複正常後發送訊息。 Zabbix將“OK”狀態的Trigger認為是一個恢複recovery event。 注意：如果使用了Escalation機制，Recovery event只會觸發一次。對已Recovery的警示，可以像發出警示的郵件一樣，設定警示標題和內容。

    以下幾點需要注意：

    1，自訂的恢複資訊，只針對Condition，是“Trigger value is PROBLEM”的生效。

    2，恢複資訊只會發送給那些之前收到過關於這個Action警示資訊的人。

    3，恢複資訊和Action 依賴PROBLEM產生的Evnet維護同一份ACK狀態。

    4，在Recovery資訊中，EVENT.*Macro中的資料，都是基於出問題的Event，而不是Recovery。

    5，在Recovery資訊中，EVENT.RECOVERY.* 表示的是出自Recovery event的資料。

• Recovery subject：Recovery資訊的標題。

• Recovery message：Recovery資訊中的內容。

• Enabled： 是否啟用這個Action。

2，Operation

Operation指的是Action觸發以後具體的操作，在Zabbix中，可以定義下面這些操作：

1. 發送一條資訊。

2. 執行一個命令（包括IPMI）。

對於discovery事件，還有額外的一些操作：

1. 添加一個Host。

2. 移除一個Host。

3. 啟用一個Host。

4. 禁用一個Host。

5. 將Host添加到一個Host group。

6. 將Host從一個Host grou中刪除。

7. 關聯到一個Template。

8. 取消和一個Template的關聯。

對於auto-registration事件，也有額外的一些操作：

1. 添加一個Host。

2. 禁用一個Host。

3. 添加Host到一個Host group。

4. 關聯到一個Template。

在配置Action的Operation標籤頁時，可以看到目前配置的Operation，單擊“New”按鈕。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/74/2F/wKiom1YWiEeShv9hAAIDGo1FCgw334.jpg" title="3.png" alt="wKiom1YWiEeShv9hAAIDGo1FCgw334.jpg" />

隨後會出現配置一個新的Operation的介面

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/74/2F/wKiom1YWiMPQK7EVAANZ09sKD6w656.jpg" title="4.png" alt="wKiom1YWiMPQK7EVAANZ09sKD6w656.jpg" />

以下對各部分進行詳細說明。

• Default operation setp duration：最小是60秒，若設定為1小時（即這裡的3600秒），則表明執行了一個操作後，要等待1個小時，才會執行下一個操作。

• Action operations：需要設定的有Steps、Details、Start in、Duration（sec）和Action。

• 
  

  • Steps：在escalation（警示的升級和擴散）的時候，會按照Step的順序來執行，從1開始。

  • Details：操作的類型和目標。 從Zabbix 2.2開始，還會顯示在發送資訊時的media type（通知類型），使用者的名字也會顯示。

  • Start in：在Event發生後多久執行操作。

  • Duration（sec）：顯示的是Step的期間，如果Step使用了預設的“Default期間”，那麼顯示“Default”。

  • Action：顯示的是兩個標籤“Edit”和“Remove”，用來編輯和移除Operation的操作。

• Operation details：用來設定一個Operation的具體設定。

下面我們來看看Operation details的設定。

• Step：在Escalation的過程中的執行計畫。

• From：表明從哪一步開始。

• To：表明到哪一步結束。

• Step duration：每一步持續的時間，如果填0，就是用上面的“Default operation setp duration”中的值。可以在同一個步驟中，進行多個操作。如果這些操作有多個duration，那麼會選擇最短的那個生效。

• Operation type：選擇操作的類型，可以選擇的有如下兩種。

    - Send message：給使用者發送資訊（郵件，SMS資訊 等，，）

    - Remote command：遠程執行命令。

注意：對於discovery事件和auto-registration 事件，可以在這裡選擇更多的操作。

Operation具體執行的操作是Operation的核心。在Zabbix中，“Send message”和“Remote command”是最重要的兩個Operation。

警示的核心是什嗎？其一，是將問題通知到負責人； 其二，是對警示有對應的措施。 前者對應的是“Send message”功能，後者對應的是“Remote command”功能。

比方說，當一台PHP伺服器的PHP進程意外退出後，Zabbix一邊發送郵件給負責人，一邊向Zabbix Agent發出命令，讓他重啟PHP伺服器上的PHP進程。這是非常棒的處理流程。

下面，一起看下如何訂製Operation。

首先看“Send message”，這個應該是所有Action都會具備的Operation。就算能夠自動回復（比如PHP進程重啟），也需要將出錯的資訊及時發送給負責人。 對於“Send message”的配置有如下幾點。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/74/2D/wKioL1YWkOXSlQoHAAFANxcGgAw067.jpg" title="5.png" alt="wKioL1YWkOXSlQoHAAFANxcGgAw067.jpg" />

• Send to User groups：可以添加一些User Group，將警示批量的發送給User Group中的所有User。

• Send to User：類似於“Send to User groups”，只是發送警報的對象換成使用者。

• Send only to：選擇是給“Send to User groups” 和 “Send to User”中發送訊息時使用的Media type。 比如選擇了“Email” ，那麼就會向前面的User 寄送電子郵件。

• Default message：使用預設的訊息格式。 預設這個是被打上勾的，取消選擇，可以看到預設定義的訊息格式。

• Conditions：在後面進行介紹，因為它的設定是“Send message” 和“Remote command”所共有的。

注意，追魚一個Host的警示，Zabbix只會把這個警示發送給這個Host至少有“讀”許可權的使用者。Trigger中至少一個運算式關聯的Host是正常工作的，即在Host中看到綠色的標識，

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/74/30/wKiom1YWktDAAXN-AAAMHp34V8c364.jpg" title="1.png" alt="wKiom1YWktDAAXN-AAAMHp34V8c364.jpg" />

對於發送出去的訊息，怎麼查看曆史訊息呢？ 怎麼獲知什麼時間發送了什麼訊息呢？ 

在Monitoring→Events中可以看到有觸發的Action列表。紅色表示Action是失敗的；“In progress”表示Action已經被觸發了； “Failed”表示沒有Action觸發成功。

我們單擊Event的時間，可以看到Action的細節，包括髮送了資訊的具體內容。

同時，我們也可以通過“Administration”→“Audit”在過濾條件中選擇Action 就可以看到過去一段時間內發生的所有Action。

“Remote command”的參數有以下幾種。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/74/30/wKiom1YWlBuw2-vVAAE-jl5Pi2Y551.jpg" title="2.png" alt="wKiom1YWlBuw2-vVAAE-jl5Pi2Y551.jpg" />

• Target list：選擇命令執行的Host，可以選擇發生問題的Host，指定某個Host 或者 Host group。

• Type：選擇執行的命令的類型，其中“IPMI”、“SSH”、“Telnet”很好理解，主要看剩下的兩個。

  • Custom script：執行在Commands 對話方塊中的Shell命令。

  • Global script：執行在Administration→Scripts中定義的一些命令。

• Excute on：可以選擇在Zabbix Agent還是Zabbix Server 上運行命令。

• Conditions：後面進行單獨介紹。

Remote command 最大的好處是什麼呢？ 是自動。  Zabbix會根據配置的條件，去執行對應的命令，下面看看Remote command的應用情境。

1. 應用無法響應時，自動重啟某些應用。

2. 當伺服器不響應時，使用IPMI的“reboot”命令重啟伺服器。

3. 在磁碟要滿了的情況下，自動刪除一些檔案（比如/tmp）。

4. 根據CPU負載，自動進行虛擬機器調配。

5. 彈性計算，根據系統情況，新增或刪除雲節點。

Zabbix無法通過Zabbix Proxy向Zabbix Agent發送，一定要從Zabbix Server 發起。而且，發送的命令長度也有限制，即不能超過255個字元，這個對於一般命令綽綽有餘了，只要不是cat某個檔案之類的，都足夠了。如果在多行寫多個命令，Zabbix會按照順序執行。而且在Remote command中，還支援Macro定義。

相比上面介紹的發送訊息，Remote command稍顯複雜。在Agent上執行的自訂指令碼（即Custom scripts）一定要在Zabbix_agentd.conf中預先定義，而且在zabbix_agentd.conf中“EnableRemoteCommands”這一項要設定為1，否則無法遠程執行命令。這是必然的，因為Active預設的Zabbix Agent其實根本沒有在伺服器上安裝Zabbix Agent，怎麼能發送命令給它執行呢？

對於遠程執行命令，許可權也是個問題。 預設情況下，Zabbix是沒有許可權來重啟系統服務的，如果Zabbix使用者想要有某個許可權，需要修改下sudoer檔案。

$ vim  sudoer#允許“Zabbix”使用者不要求輸入密碼就可以運行所有root許可權的命令zabbix ALL=NOPASSWD: ALL#允許“zabbix”使用者可以在不要求輸入密碼的情況下運行/etc/init.d/httpd restart ，即重啟apachezabbix ALL=NOPASSWD: /etc/init.d/httpd restart

如果Host上某一類的Interface有多個（比如有多個Zabbix Agent執行個體），那麼Zabbix會選擇預設的去運行。

對於剩下的“Coditions”，它有兩個選項“Not ACK” 和 “ACK”，  “ACK”是“Acknowledge”的縮寫，在Zabbix中，以為某個Evnet是否被人“認領”了，可以理解為，有沒有在處理這個事情。 這裡的“Not ack”和 “Ack”表達的在這種情況下需要執行Operation。如果選擇“Not ack”，那麼只有當Evnet沒有被“Ack”的情況下需要執行。

3，Condition

警示，肯定是基於某個條件的，比如某個伺服器的CPU負載超過20%。 在Zabbix，這種“條件”就是Trigger，那不能對每一個Trigger都設定一個Action吧？  最好的辦法就是定義某一類的Trigger如果出問題了，就同意觸發某個Action。Zabbix就是這麼做的，它在Trigger和Action之間，抽象了一個Condition的概念。“Condition”的中文意思是“情況”，可以理解為某一種條件。即Action不是直接和Trigger掛鈎，而是可以配置一組條件，如果都滿足這些條件，就執行Action。 比如CPU負載超過20%這個Trigger，可能對於消耗CPU的伺服器來說不需要警示，但是對於不消耗CPU的伺服器來說就需要了。  那麼可以組合這兩個條件“CPU負載超過20%”和“伺服器是CPU密集型”，對應到Zabbix，就是“CPU>20” 且 “Host屬於CPU Host group”。

最常用的是基於Trigger的Evnet，在下表中，提到的Host等，指的都是和這個Event相關的Trigger中關聯的Host。

本文出自 “Professor哥” 部落格，轉載請與作者聯絡！

Zabbix 監控之 - 警示篇 Actions