有了好的監控項，也還得有好的觸發器，纔能有效觸發zabbix報警動作，雜亂無章的觸發器只會增添zabbix報警系統的負擔，同時也給運維人員帶來的大量的垃圾信息，所以一個好的監控系統中，觸發器的設計也是需要動腦子的。當然今天在這裏也只不過拋磚引玉，給大家簡單示範一下。
正常來說，比如磁盤使用率達到60%，可能就需要引起運維人員的關注了，達到80%時就必要及時進行報警處理了，否則可能因數爆盤帶來的失誤就不可容忍了。
當然，類似於這類的觸發器添加起來，可能也就相對簡單了，無礙乎60%定義爲告警等級，80%定義爲嚴重等級，60%可以讓zabbix發一封郵件給運維人員，80%時就讓zabbix發一條短信給運維人員。
觸發器詳細定義過程
觸發器的表達式可以直接手寫，但這需要對zabbix的語言非常瞭解，不適合大衆使用，可以點擊add進行表達式的構造合成，詳細過程如下
使用率達到80%的觸發器只是等級不同，還有就是函數N的賦值不一樣而已
表達式構造詳細頁面
這裏只是簡單的帶大家一起創建了一些簡單的觸發器，實際運用中，多個觸發器之間可能存在一定的依賴關係，比如說php-fpm是需要前端的nginx傳送應用需求過來的，但nginx端口的運行是建立在主機沒有宕機的情況之上的，所以這一系列的觸發器之間就存在比較清晰的依賴關係了，nginx依賴於主機不宕機，php-fpm依賴於nginx服務正常運行。
這裏需要說明一下的是443端口是nginx提供的https服務作爲後臺網站使用的
Add按鈕添加表達式
添加依賴主機不宕機的觸發器
依賴頁面添加對應依賴監控項
添加成功後的結果
接下來再配置php-fpm依賴於nginx服務運行的觸發器
php-fpm依賴於nginx服務運行的觸發器配置成功如下圖所示
再這裏簡單陳述一下邏輯關係最終生效的效果，就是當被監控服務宕機後zabbix服務器端獲取不到back.port.443和php.port.9000端口狀態的數據時，不會額外去觸發back.port.down和php.port.down這兩個觸發器，而是直接觸發一個host.offline一個觸發器。對於被監控服務器來說，主機都已經宕機了，nginx服務和php服務很顯然端口監聽也是失敗的，但此時，還讓zabbix服務器端這兩個服務不可用已經沒有實質性的意義了。最終所實現的一個終極思想就是一次報警直接定位根本問題。
補充板塊
zabbix異於模版的監控項及觸發器的設計
對於異於模板的item個例，可以先禁用對應主機上的模版監控項，並克隆該監控項，進行修改後即可單獨應用於此主機，觸發器也是如此。
克隆異於模版的監控項，修改後單獨應用於此主機，如下圖所示
克隆異於模版的觸發器，修改後單獨應用於此主機，如下圖所示
注意：模版上原有的監控項或者觸發器名稱前面都會帶有模版的名稱，而單獨屬於此主機的就只有監控項或者觸發器自身的名稱。
下面以克隆原有模版上的觸發器爲例，簡單展示一下操作過程
這是原有模版的觸發器內容，需要做如下操作
至此一個觸發器的設計思想給大家分享完了，希望之前對觸發的依賴關係不太明白的，讀完本文能夠有所幫忙，如果覺得本系列博文讀後之後有所幫忙的朋友，幫忙點個關注加個贊！
錯誤之處，還望高人留言指正。