一、觸發器
1、觸發器（trigger）
“監控項”僅負責收集資料，而通常收集資料的目的還包括在某名額對應的資料超出合理範圍時給相關人員發送告警資訊，“觸發器”正是用于為監控項所收集的資料定義門檻值
每一個觸發器僅能關聯至一個監控項，但可以為一個監控項同時使用多個觸發器；事實上，為一個監控項定義多個具有不同門檻值的觸發器，可以實作不同級别的報警功能
一個觸發器由一個表達式構成，它定義了監控項所采集的資料的一個門檻值
一旦某次采集的資料超出了此觸發器定義的門檻值，觸發器狀态将會轉換為“Problem”；而當采取的資料再次回歸至合理範圍内時，其狀态将重新傳回到“OK”
2、觸發器表達式
觸發器表達式高度靈活，可以以之建立出非常複雜的測試條件
zabbix server item每次擷取到一個新值都會使用觸發器表達式計算它的狀态如果使用基于時間的表達式
基本的觸發器表達式格式如下所示：
{<server>:<key>.<function>(<parameter>)}<operator><constant>
某主機上某個key使用某個函數（參數）所得的值 和 設定的值比較
server：主機名稱；
key：主機上關心的相應監控項的key；
function：評估采集到的資料是否在合理範圍内時所使用的函數，其評估過程可以根據采取的資料、目前時間及其它因素進行；
目前，觸發器所支援的函數有：
avg、 求平均值
count、 指定時間内或次數内數值統計
change 指定時間内或次數内倒數第2次于倒數第1次的內插補點，對于字元串，0沒有變化，1表示有變化；
date、 目前日期
dayofweek、 本周第幾天 dayofmonth 本月第幾天
delta、 指定時間内或次數内最大值與最小值的差
diff、 指定時間内或次數内倒數第2次于倒數第1次的值，有沒有不同；常用于監控檔案
regexp 檢查最後一次采樣的資料是否能夠被指定的模式所比對：1表示比對，0表示不比對
iregexp 不區分大小的正規表達式
last 最近采樣的資料
max、min、nodata（沒有資料）、
now 傳回時間戳
prev 倒數第二個采樣值
str 從最後一次的采樣中查找此處指定的字元串；0表示找到，1表示沒找到
strlen 字元串長度比較
sum 求和
parameter：函數參數；大多數數值函數可以接受秒數為其參數，而如果在數值參數之前使用“#”做為字首，則表示為最近幾次的取值，如sum(300)表示300秒内所有取值之和，而sum(#10)則表示最近10次取值之和；
此外，avg、count、last、min和max還支援使用第二個參數，用于完成時間限定；
例如，max(1h,7d)将傳回一周之前的最大值；
一個例子：
{www.magedu.com:system.cpu.load[all,avg1].last(0)}>3
表示主機www.magedu.com上所有CPU的過去1分鐘内的平均負載的最後一次取值大于3時将觸發狀态變換
對last函數來說，last(0)相當于last(#1)
更多觸發器表達式的例子：
http://www.ttlsa.com/zabbix/zabbix-trigger-expression/
3、觸發器間的依賴關系
在一個網絡中，主機的可用性之間可能存在依賴關系
例如，當某網關主機不可用時，其背後的所有主機都将無法正常通路
如果所有主機都配置了觸發器并定義了相關的通知功能，相關人員将會接收到許多告警資訊，這既不利于快速定位問題，也會浪費資源
正确定義的觸發器依賴關系可以避免類似情況的發生，它将使用通知機制僅發送最根本問題相關的告警
注意：目前zabbix不能夠直接定義主機間的依賴關系，其依賴關系僅能通過觸發器來定義
4、觸發器等級
severity通常用來定義目前item的一個狀态的嚴重性。我們可以根據不同的嚴重性來定義不同的事件，例如報警，zabbix自帶如下嚴重性定義。
嚴重性 定義 顔色
無類别 未知的嚴重性 灰色
資訊 供參考 亮綠燈
警告 應該引起注意 ×××
常見問題 常見問題 橙色
高 重要的事情發生 紅色
災難 災難，會造成損失 亮紅色
可視化顯示，不同級别顯示不同顔色，例如一般嚴重性為綠色
聲音報警,不同的級别不同聲音.
使用使用者自定義媒體報警，例如嚴重問題發短信，其他問題發送郵件。
根據嚴重性來定義是否報警
可以自定義觸發器嚴重性以及顔色，請參考：customise trigger severity names and colours.
5、建立觸發器
建立觸發器步驟:
點選Configuration（配置） → Hosts（主機）
點選hosts（主機）相關行的trigger
點選右上角的建立觸發器（create trigger），你也可以修改清單中的觸發器
在表單中輸入相應的資訊：
建立觸發器可用的各屬性說明
Name：觸發器名稱，
名稱可以包含宏變量： <code>{HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {ITEM.VALUE}, {ITEM.LASTVALUE}</code> and <code>{$MACRO}</code>.
$1, $2…$9 可以被用來關聯表達式的常量
示例：
name：Processor load above $1 on {HOST.NAME}”
表達式：system.cpu.load[percpu,avg1].last(0)}>5
會顯示為：Processor load above 5 on ttlsa雲伺服器
Expression：邏輯表達式，用于評估觸發器狀态；
Multiple PROBLEM events generation：依賴于目前觸發器的“Problem”狀态生成其它事件；
Description：目前觸發器的描述資訊；
URL：在screen的“Status of Trigger”中顯示的内容的連結；
在Monitoring → Triggers中，可以看到URL并且可以點選，一般情況下他需要配合觸發器ID來使用，在url中包含觸發器ID（宏變量 {TRIGGER.ID}），這樣可以直接點選到具體觸發器中。
Severity：目前觸發器的嚴重級别；
Enabled：是否啟用目前觸發器；
二、事件（event）
我們前面花了大量時間去學習item、trigger都是為發送報警做準備的，什麼是事件通知呢？簡單的說故障發生了，zabbix會發郵件或者短信給你，告訴你伺服器的一些狀況。
1、event
Zabbix的事件是基于時間戳進行标記的，它們是采取動作(action)如發送郵件通知的基礎，其主要來源于三種途徑
觸發器(trigger)事件：Trigger events
觸發器狀态每次發生改變，都會生成相應“事件”，且通常包含詳細資訊，如發生的時間及新的狀态等；
發現(discovery)事件：Discovery events
zabbix會周期性地掃描“網絡發現規則”中指定的IP範圍，一旦發現主機或服務，就會生成一個或幾個發現事件；
發現事件有8類：Service Up、Service Down、Host Up、Host Down、Service Discovered、Service Lost、Host Discovered和Host Lost；
主動agent自動發現事件（也稱作“自動注冊事件”）：Auto registtation events
當一個此前狀态未知的主動agent發起檢測請求時會生成此類事件；
内部事件：Internal events
Item變成不再支援或trigger變成未知狀态
LLD：
low level disvcovery，較低層的自動發現
三、執行動作（Action）
Action由conditions（條件）和operations（操作）組成。當滿足指定的條件，然後執行操作。這就是一個action。
operations包含兩個操作：
Send message
發送資訊，就是發送報警
remote command
遠端指令，就是執行zabbix-server伺服器端的指令，對于zabbix-agetn是遠端指令
下面我們來分别示範下這兩種操作的用法：
1、Send message
發送資訊報警是有先決條件的：
zabbix-server将報警資訊發送給誰？
肯定是要發送給zabbix-server上的某個使用者
如何才能通知到此使用者呢？
zabbix-server上的每個使用者都配置有接受通知的媒體(Media type)
了解了這個兩個問題，配置報警資訊的發送就很簡單了。
在zabbix中，通知媒體是指發送通知資訊的通道，其通常有以下幾種類型：
E-mail：電子郵件，即通知郵件的方式傳送通知資訊；
隻能發送給本伺服器上的其它使用者，不能發送到外部的郵件位址，那這有毛用，我們都是使用腳本來實作發送E-mail
SMS：手機短信，即通過連接配接至zabbix伺服器GSM Modem發送通知；需要短信網關裝置
Jabber：jabber消息；Jabber是一個開放的、基于XML的協定，能夠實作基于Internet或LAN的即時通訊服務；
自定義的通知腳本：我們隻能使用這個了
以上方式不能滿足需求時，zabbix可以調用位于其配置檔案/etc/zabbix/zabbix_server.conf “AlertScriptsPath”變量所定義的腳本查找目錄中的腳本來完成通知功能；
腳本中可使用$1,$2,$3來調用action中的郵件的收件人,Default subject(主題), default message（内容）
1）定義一個通知媒體 ### 媒介類型 (Media type)
Aministration --> Media types
可以看到有3個預設的通知示警媒介類型，這是系統預設給的配置示例，我們不動，
選擇create media type：
SMTP server：SMTP 郵件伺服器，localhost表示使用本伺服器做郵件伺服器就隻有本系統内的使用者才能收的到郵件
SMTP helo：SMTP helo值，通常情況下是頂級域名。SMTP伺服器間需要交換資料時，先會探測對發是否線上，一般和SMTP 郵件伺服器一樣就可以
SMTP email：發件人
2）使用者綁定通知媒體
Aministration --> Media types --> add
tyepe：選擇媒介類型，自己之前建立的
send to：發送給，就是收件人
when active：報警時間限定，例如1-5,09:00-18:00，隻有工作日的9點到18點才會通知，實際工作中，我們應該是相反。
Use if severity：嚴重性類型，隻接收指定的類型,例如info不想接收，那我不勾選即可。
Status：媒介狀态Enabled - 啟用中.Disabled - 已禁用.
3）定義動作
點選configuration（配置）-> Actions（報警）-> 選擇事件來源 --> create action
注意：下面的截圖和我後面的配置不一樣，不願截圖了，使用别人的截圖來說明
action主要屬性的說明：
Name：目前action的獨有名稱；
Default subject：預設的消息主題，可以使用宏；
Default message：預設的消息，可以包含宏；
Recovery：監控項從“問題”狀态恢複之後是否發送的消息；如果啟用，恢複消息僅發送給監控項轉換為“問題”狀态時的通知對象；
Recovery subject：恢複消息主題，可以包含宏；
Recovery message：恢複消息，可以包含宏；
Enabled：是否啟用目前action；
配置完action的基本内容之後，接下來配置條件
Type Of calculation：
各種條件之間的關系，包含AND、OR 以及AND/OR，如上圖是AND關系，同時要滿足以上機器不在維護狀态以及觸發器值為PROBLEM才會觸發報警的動作。
接下來是“操作”标簽，如下：
此處沒有報警的動作，當你滿足了報警條件也沒有任何意義，因為你不執行任何報警的操作，那還要action做什麼，對吧？話說回來，每個action都必須配置operations。
圖檔上的step說的可能不是很明白，
step可以用來設定報警更新：
表示階段，1表示第一次報警，如果2表示第二次報警。
action operations可以添加多個，如下：
如上圖，我們可以看出第1-10次報警都會發郵件給Admin這個使用者，每次郵件間隔為300秒，
第4-10次開始（故障發生15分鐘後）便會發送郵件給administrators這個組。
這邊可以實作故障開始時發送郵件給值班運維，多少分鐘還沒處理好發送郵件給主管或者經理，甚至是老闆，呵呵。
如果我們監控的某服務，此時服務挂了而引起的事件，我們也可以這樣設定：
step 1：使用腳本，重新開機這個服務
step 2：服務還沒起來，再發送資訊報警
最後儲存之後可以看到我們配置好的action了，隻要滿足action條件便會出發報警操作。
上面3個步驟都配置好了，我們觸發一個報警的動作： # 觸發前面設定的too many interrupts觸發器
可以在Monitoring ——> Triggers 看到觸發器的狀态
Monitoring --> Events 看到事件觸發的動作成功了
檢視郵件：
我們就成功的使用自帶的E-mail通知媒體實作了報警，不過這個說了沒毛用吧，一般都不用的，這裡隻是示範下配置過程。
2、remote comman
（1） 給zabbix定義sudo規則：
（2）不支援(active)主動模式的agent，就是說自動注冊的用戶端不支援
（3）不支援代理模式
（4）指令長度不得超過255字元
（5）可以使用宏
（6）zabbix-server僅執行指令，而不關心指令是否執行成功
前提：
zabbix-agent要配置為支援執行遠端指令：
在用戶端修改配置檔案/etc/zabbix/zabbix_agentd.conf
指令如果用到以其它使用者身份執行時，指令本身要以sudo執行：sudo /etc/rc.d/init.d/httpd restart
在配置好監控項和觸發器之後，一旦正常工作中的某觸發器狀态發生改變，一般意味着有異常情況發生，此時通常需要采取一定的動作(action)，如告警或者執行遠端指令等
并非所有的觸發器狀态發生改變的場景都需要對其進行幹預，如轉變為“OK”狀态時，相應地，如果觸發器的狀态轉變為“Problem”，就需要告知所有關心其相關監控名額的人員了。
是以，Zabbix的通知機制也稱作基于事件的通知機制，也隻有了解了事件本身，才能定制出符合需求的通知系統
Action的操作(operation)：
zabbix支援的操作有兩類：“發送通知”和“執行遠端指令”
而對于“發現”類事件來說，其支援的操作還有添加主機、移除主機、啟用主機、禁用主機、添加到組、從組中删除、連結到模闆及從模闆上拆除關聯等
對于“自動注冊”類事件來說，支援的操作為添加主機、禁用主機、添加到組及連結至模闆等
Operation相關的屬性說明：
Step：告警更新(escalation)排程方式；
From：操作開始的位置；即第幾次更新間隔時間到達後檢測仍然有“問題”時開始執行操作；
To：直到哪一步為止，其減去From中的數字再加1即表示要操作的次序；0表示無限；
Step duration：前述自定義告警更新的時間間隔，0表示使用預設；
Operation type：操作類别；標明不同的操作類别，其後續的其它屬性也有所不同；
Send message：發送消息；
Remote command：執行遠端指令；
Conditions：執行操作的條件；
Not ack：僅在事件為“未知(unacknowledged)”時執行操作；
Ack：僅在事件可被識别(acknowledged)時執行操作；
類别為“Send message”時的相關屬性：
Send to User groups：給標明組中的所有使用者發送通知；
Send to users：給標明的使用者發送通知；
Send only to：發送通知時所使用的媒介，all為所有媒介；
Default message：如果啟用，則發送預設消息；
Subject：消息的自定義主題，可以包含宏；
Message：要發送的消息内容，可以使用宏；
類别為“remote command”時的相關屬性：
Target list：遠端指令執行的目标主機，可以是目前主機、其它主機或主機組；
Type：指令類型；
IPMI：IPMI指令；
Custom script：自定義腳本，可以選擇其是在zabbix server上還是zabbix agent上執行；
SSH： 通過ssh執行指令，需要提供目标主機上的使用者帳号、相關的認證方式及認證所需要額外資訊；
Telnet：通過telnet執行指令，需要指定使用者名、密碼及遠端主機telnet服務監聽的端口；
Global script：全局腳本，執行“Administration→Scripts”定義的腳本的其中之一；
Commands：要執行的指令；
告警更新(escalation)
escalation用于實作用于定制發送通知或執行遠端指令的方式，
常用于實作如下場景：
出現問題時立即發送通知；
問題得不到解決時多次發送通知給使用者；
按需延遲發送通知；
問題長久得不到解決時發送給級别更高的使用者；
立即執行遠端指令或經過一個預定的時長後仍未解決問題時執行遠端指令；
故障恢複時發送相關資訊；
實際操作中，action的escalation機制的實作依賴于“escalation step(更新步長)”，step是一個時間長度；
為了簡化操作過程，可以為step定義預設的時長，隻有在必要時才為action自定義其step
可以在任何有效的step到達時啟動action，第1個step表示立即啟動；
如果要延遲啟動action，可以選擇在後面的其它step上啟動
下面示例表示延遲一個step之後才啟用action
為更好的了解，這裡總結一下
1、Zabbix完整的監控配置流程大體上由如下步驟組成：
host group --> hosts --> Applications --> items（存儲于mysql）--> triggers（ok-->problem）--> events --> actions --> User groups --> Medias --> Users
graph（zabbix-web） --> screen
主機組的劃分：
伺服器的用途、系統版本、應用程式、地理位置、業務單元
2、如何添加主機到zabbix server
discovery：
自動發現，定義discovery規則
zabbix-server會自動掃描某個範圍（網段）内活動的主機，會自動納入監控
auto_registrion：
用戶端自動注冊，
low level disvcovery:
較底層的自動發現，用于差別底層裝置（如：linux和windows）