深入淺出Zabbix 3.0 -- 第八章 管理告警

第八章? 管理告警

在本章中可以了解到Triggers（觸發(fā)器）的配置和Actions（動作）的配置，詳細介紹觸發(fā)器的規(guī)則表達式、告警、告警升級等，

作為一個監(jiān)控解決方案，告警是不可或缺的功能。當從監(jiān)控對象上收集的監(jiān)控項的值滿足系統(tǒng)中設定的閾值即產(chǎn)生告警事件，依據(jù)告警事件的不同類型，產(chǎn)生相應的告警動作，給用戶發(fā)送告警信息，或者執(zhí)行命令等等。Zabbix中的告警流程如下圖7-1所示。

圖 8-1

8.1 觸發(fā)器

我們知道在Zabbix中是通過監(jiān)控項收集監(jiān)控數(shù)據(jù)，然后這些數(shù)據(jù)會保存在數(shù)據(jù)庫中。有時候在某個監(jiān)控指標出現(xiàn)問題時想讓系統(tǒng)能及時通知我們，這就需要告訴系統(tǒng)監(jiān)控指標的數(shù)據(jù)在什么情況下是有問題的，也就是常說的閾值。而觸發(fā)器就是通過邏輯表達式對監(jiān)控指標的數(shù)據(jù)進行運算，將其結果與定義的閾值進行比較，從而判斷該監(jiān)控指標的狀態(tài)是否正常。

在Zabbix中，無論觸發(fā)器的表達式有多復雜，最終我們得到的結果不是True（真）就是False（假）。這個結果直接關系到觸發(fā)器的狀態(tài)，當結果為False時觸發(fā)器的狀態(tài)是OK，意味著該數(shù)據(jù)是正常的。結果為True時觸發(fā)器的狀態(tài)是PROBLEM，意味著該數(shù)據(jù)是有問題的，這個對應關系要記清楚。

如果在觸發(fā)器中使用了基于時間的函數(shù)nodata()、date()、dayofmonth()、dayofweek()、time() 和now()時，Zabbix server會對觸發(fā)器每隔30秒重新進行運算。如果同時使用了基于時間的函數(shù)和其他函數(shù)，當接收到一個新值并且每隔30秒將重新進行運算。

近日完成《深入淺出?zabbix 4.0》視頻教程的錄制并正式發(fā)布，該教程基于 zabbix 4.2 ，對Zabbix進行全面講解。歡迎大家圍觀。課程鏈接：https://edu.51cto.com/sd/ce000?

8.1.1 理解觸發(fā)器的表達式

在觸發(fā)器中使用的表達式非常靈活，通過它們也可以創(chuàng)建復雜的邏輯運算。讓我們一起來看個簡單的表達式的格式。

{<server>:<key>.<function>(<parameter>)}<operator><constant>

例如：{Testsrv:vfs.fs.size[/var,pused].delta(600)}>3

可以看到一個觸發(fā)器表達式主要有兩部分組成：

• 應用到監(jiān)控項數(shù)據(jù)的函數(shù)。

• 對函數(shù)結果進行算術和邏輯運算。

在上面的例子中指定了完整的監(jiān)控項key，即 Testsrv:vfs.fs.size[/var,pused]和應用的函數(shù) delta(600)，其運算結果使用運算符大于號（>）和常量 3 進行比較。

我們可以在觸發(fā)器表達式中引用多個監(jiān)控項，每個監(jiān)控項應用一個函數(shù)。同一個監(jiān)控項也可以在表達式中使用兩次，但是要明確指定完整的監(jiān)控項，例如：

{test:log[/tmp/operations.log,,,10,skip].nodata(600)}=1 or

{test:log[/tmp/operations.log,,,10,skip].str(error)}=1

如果operations.log至少10分鐘沒有收到新的行，或者在log文件中發(fā)現(xiàn)一個錯誤，該觸發(fā)器的狀態(tài)會變?yōu)?/span>PROBLEM。

觸發(fā)器表達式中不僅可以從同一主機引用監(jiān)控項，也可以從不同的主機或代理服務器（如果你能訪問它們）中引用監(jiān)控項，例如：

{Proxy1:server1:agent.ping.last(0)}=0 and

{Proxy2:server2:agent.ping.last(0)}=0

如果主機server1和server2同時都ping不同時觸發(fā)器的狀態(tài)會變?yōu)?/span>PROBLEM。即便主機是被不同的代理服務器監(jiān)控也一樣工作的很好。

所有在Calculate checks中可以應用的函數(shù)都可以在觸發(fā)器表達式中應用，更詳細的可用函數(shù)的定義可以參考Zabbix官方網(wǎng)站（https://www.zabbix.com/documentation/3.0/manual/appendix/triggers/functions）。

很多觸發(fā)器函數(shù)可以接收seconds（秒）和 #num參數(shù)，這兩個參數(shù)的含義如下：

• seconds：指定一個時間期間，單位為秒。觸發(fā)器將使用指定期間內(nèi)的監(jiān)控項值進行函數(shù)運算。例如：sum（600）表示對最近600秒內(nèi)監(jiān)控項的值求和。600秒也可以寫成10m（分鐘），86400可以寫成1d（天）。

• #num：指定次數(shù)。觸發(fā)器將使用指定的最近次數(shù)收集監(jiān)控項的值進行函數(shù)運算。例如：sum（#5）表示最近5次收集的值進行求和。

需要注意的是使用last函數(shù)時#num的含義有所不同，#num表示最近第幾次。例如某個監(jiān)控項最近5次收集的值分別是3（最新的）、7、2、6、5，last（#2）將返回7，last（#5）將返回5。

在觸發(fā)器中我們使用哪個參數(shù)比較好呢？建議在Passive（被動式）監(jiān)控方式中各種監(jiān)控項數(shù)據(jù)都是由Zabbix server定期的收集，在這種情況下使用seconds會比較好，如果你修改了相關監(jiān)控項的監(jiān)測時間間隔會對#num參數(shù)會有影響，從而影響觸發(fā)器。而使用seconds參數(shù)可能更接近實際的監(jiān)測，在日后觸發(fā)器的維護中你能夠更容易的理解觸發(fā)器的定義。對于使用active（主動式）監(jiān)控方式的監(jiān)控項，尤其是trapper監(jiān)控項和log文件，我們不能保證有一個穩(wěn)定的、可靠的監(jiān)測時間間隔，所以使用#num通常是最好的選擇。

在avg、count、last、min和max函數(shù)中還支持使用第二個參數(shù) time_shift，這個參數(shù)允許從過去的某個時間期間引用數(shù)據(jù)。例如：avg（1h，1d）將返回前一天1小時的平均值。在這里我們要注意，觸發(fā)器只使用歷史數(shù)據(jù)，因此使用time_shift參數(shù)時指定期間內(nèi)的歷史數(shù)據(jù)必須能正常訪問。

Zabbix在觸發(fā)器中支持下面的運算符（優(yōu)先級由高到低）如表8-1所示。

表 8-1

注意not、and和or運算符必須是小寫的，所有運算符中除了一元負號運算符和not運算符，都是從左到右結合。

下面我們結合一些例子更好的理解觸發(fā)器的使用。

• {www.zabbix.com:system.cpu.load[all,avg1].last()}>5

www.zabbix.com:system.cpu.load[all,avg1]指定了完整的監(jiān)控項，意思是主機www.zabbix.com上的監(jiān)控項system.cpu.load[all,avg1]，使用函數(shù)last（）收集最近一次的值，使用運算符 > 與常量5進行比較，如果最近一次的監(jiān)控項值大于5時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {www.zabbix.com:system.cpu.load[all,avg1].last()}>5or {www.zabbix.com:system.cpu.load[all,avg1].min(10m)}>2

最近一次的CPU負載平均值大于5或最近10分鐘的負載平均值大于2時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1

監(jiān)測/etc/passwd文件的前一個checksum值和最近一次的值不同時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100K

最近5分鐘網(wǎng)絡接口eth0接收的字節(jié)數(shù)大于100KB時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {smtp1.zabbix.com:net.tcp.service[smtp].last()}=0and {smtp2.zabbix.com:net.tcp.service[smtp].last()}=0

監(jiān)測不同主機上的SMTP服務都停止時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {zabbix.zabbix.com:icmpping.count(30m,0)}>5

監(jiān)測主機在過去30分鐘超過5次ping不通時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {zabbix.zabbix.com:tick.nodata(3m)}=1

例子中tick必須使用Zabbix tgapper監(jiān)控方式，主機定期通過zabbix_sender發(fā)送tick的值到服務器，如果在3分鐘（180秒）沒有接收到數(shù)據(jù)時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {zabbix:system.cpu.load[all,avg1].min(5m)}>2and {zabbix:system.cpu.load[all,avg1].time()}>000000 and {zabbix:system.cpu.load[all,avg1].time()}<060000

例子中使用了time函數(shù)，只在晚上00:00 – 06:00之間，最近5分鐘CPU負載大于2時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {MySQL_DB:system.localtime.fuzzytime(10)}=0

例子中使用了fuzzytime函數(shù)，當主機MySQL_DB的本地時間和Zabbix server的本地時間相差超過10s時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2

例子中使用了第二個參數(shù)time_shift，如果最近1小時CPU負載的平均值是昨天相同時間的2倍時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {TemplatePfSense:hrStorageFree[{#SNMPVALUE}].last()}<{TemplatePfSense:hrStorageSize[{#SNMPVALUE}].last()}*0.1

當剩余存儲容量低于總容量的10%時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• ({server1:system.cpu.load[all,avg1].last()}>5)+ ({server2:system.cpu.load[all,avg1].last()}>5) +({server3:system.cpu.load[all,avg1].last()}>5)>=2

當3臺主機中至少有兩臺主機最新的CPU負載平均值超過5時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

• {zbserver:grpsum["cluster","proc.num[listener]", last, 0].last(0)} /

{zbserver:grpsum["cluster","agent.ping", last, 0].last(0)} < 0.5

Aggregated 和Calculated 監(jiān)控項在定義觸發(fā)器時也是非常有用的。在例子中正常提供服務的服務器和可用服務器的比值低于0.5時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM。

有時候觸發(fā)器必須在不同的情況下使用不同的條件，例如，機房溫度超過20℃觸發(fā)器狀態(tài)變?yōu)?/span>PROBLEM，然后觸發(fā)器一直處于PROBLEM狀態(tài)，直到溫度低于15℃恢復為OK狀態(tài)?？赏ㄟ^定義下面的觸發(fā)器來實現(xiàn)。

({TRIGGER.VALUE}=0 and {server:temp.last()}>20) or

({TRIGGER.VALUE}=1 and {server:temp.last()}>15)

在這個觸發(fā)器定義中我們使用了{TRIGGER.VALUE}，{TRIGGER.VALUE}返回當前觸發(fā)器的值。{TRIGGER.VALUE}為0是OK狀態(tài)，{TRIGGER.VALUE}為1是PROBLEM狀態(tài)。當觸發(fā)器的狀態(tài)是OK時，{TRIGGER.VALUE}=0的運算結果是1，{TRIGGER.VALUE}=1的運算結果是0，因此在溫度超過20℃時，觸發(fā)器返回的狀態(tài)是1，也就是PROBLEM狀態(tài)。

為了加深理解，在來看看這個例子，最近5分鐘磁盤剩余空間的最大值小于10GB時觸發(fā)器的狀態(tài)就會變?yōu)?/span>PROBLEM，然后觸發(fā)器一直處于PROBLEM狀態(tài)，直到最近10分鐘磁盤剩余空間的最小值大于40GB恢復為OK狀態(tài)。

({TRIGGER.VALUE}=0and {server:vfs.fs.size[/,free].max(5m)}<10G) or

({TRIGGER.VALUE}=1and {server:vfs.fs.size[/,free].min(10m)}<40G)

8.1.2 觸發(fā)器依賴

在一個大型的基礎架構中，某種應用服務或主機的可用性并不取決于其自身是否可用，它可能依賴于其他連接的設備的可用性。例如，交換機發(fā)生故障時你不僅收到路由器的告警通知，同時你也會收到所有連接到該交換機上主機的告警通知，實際上只是交換機發(fā)生故障，導致Zabbix server不能通過交換機對主機進行監(jiān)控。由此可以看到交換機和主機之間的依賴關系，我們可以在主機上定義的觸發(fā)器中設置對交換機可用性的依賴關系，當交換機發(fā)生故障時，與其連接的主機會在交換機不可用的情況下跳過任何觸發(fā)器的監(jiān)測，直到依賴的交換機變?yōu)榭捎?，也就是交換機可用性的觸發(fā)器狀態(tài)變?yōu)?/span>OK。

這種觸發(fā)器級別的依賴特性非常靈活和強大，具有最明顯的優(yōu)勢，你可以定義在不同主機上的單個服務之間的依賴關系。例如，你有多個web服務器上的web應用連接到一個數(shù)據(jù)庫服務器，如果數(shù)據(jù)庫不可用時web應用也不會正常運行，因此你可以設置一個web監(jiān)控觸發(fā)器和數(shù)據(jù)庫可用性之間的依賴關系。同一臺服務器中可能運行著多個不同的服務或應用，你可以設置這些服務或應用的觸發(fā)器和主機可用性之間的依賴，或者和其他服務或應用觸發(fā)器的依賴關系。

觸發(fā)器依賴雖然配置簡單，但是也很容易變得復雜，增加維護工作量。因此我們要選擇關鍵的、少量的依賴關系進行配置，這樣可以幫助我們從大量告警通知中解脫出來，更專注于解決遇到的問題。

8.1.3 觸發(fā)器告警級別

Trigger severity（觸發(fā)器告警級別）是一個可以附加到觸發(fā)器中的簡單的標簽。在web前端頁面中使用不同的顏色顯示告警級別，在用戶配置中還可以為不同的告警級別定義不同的告警聲音，相同的監(jiān)控項可以在不同的級別上創(chuàng)建不同的動作，例如，我們創(chuàng)建2個觸發(fā)器，其中一個在磁盤容量剩余10%時觸發(fā)warning級別的告警，另一個在磁盤容量5%時觸發(fā)critical告警。

Zabbix支持以下告警級別：

• Not classified：未分類故障，顯示為灰色。

• Information：一般信息，顯示為亮藍色。

• Warning：警告信息，顯示為×××。

• Average：一般故障，顯示為橙色。

• High：嚴重故障，顯示為亮紅色。

• Disaster：災難，顯示為紅色。

Zabbix中也可以自定義告警級別的名稱，在Administration--> General --> Trigger severities頁面中，自定義相應級別的名稱，例如，Important。如果需要將自定義的名稱翻譯成本地語言，需要編輯<frontend_dir>/locale/zh_CN/LC_MESSAGES/frontend.po文件，在文件中添加2行內(nèi)容：

msgid "Important"

msgstr "重大故障"

???? 編輯完成后保存，執(zhí)行下面的命令生成frontent.mo。

???? # msgfmt –vfrontend.po –o frontend.mo

8.1.3 創(chuàng)建觸發(fā)器

在介紹創(chuàng)建觸發(fā)器之前，我們先看看創(chuàng)建觸發(fā)器時配置頁面中各參數(shù)的含義，點擊Configuration --> Hosts/Template --> Triggers 頁面中，點擊右上角的Create trigger按鈕進入觸發(fā)器配置頁面。如下圖8-2所示。

圖 8-2

Trigger標簽中各參數(shù)的含義如下：

• Name：觸發(fā)器名稱。在名稱中支持宏變量，包括：{HOST.HOST}、{HOST.NAME}、{HOST.CONN}、{HOST.DNS}、{HOST.IP}、{ITEM.VALUE}、{ITEM.LASTVALUE} 和 {$MACRO}。$1，$2，… ，$9可以引用表達式中的常量。$1 - $9會被解析為應用的常量的值，例如觸發(fā)器名稱為Processor load above $1 on {HOST.NAME}，如果定義的表達式為{New host:system.cpu.load[percpu,avg1].last()}>5，那么該觸發(fā)器觸發(fā)后名稱為自動變?yōu)?/span>Processor load above 5 on New host。

• Expression：用于計算觸發(fā)器狀態(tài)的邏輯表達式。

• Multiple PROBLEM eventsgeneration：選中此項后，每次判斷觸發(fā)器的狀態(tài)為PROBLEM時就會生成一個事件。需要對監(jiān)控項故障一直發(fā)送告警通知的場景中使用此項。

• Description：觸發(fā)器的描述信息?？梢园糜诮鉀Q特定問題的指令，負責人員的聯(lián)系方式等。也可以像觸發(fā)器名稱一樣包含宏變量。

• URL：如果定義了URL，在Monitoring -->Triggers頁面中點擊觸發(fā)器名稱時可以看到一個URL連接，可以使用{TRIGGER.ID}、幾個{HOST.*} 宏變量和用戶定義的宏變量。如下圖8-3所示。

  

圖 8-3

• Severity：設置觸發(fā)器告警級別。

• Enabled：勾選此項為啟用觸發(fā)器。

Dependencies標簽如下圖8-4所示。

圖 8-4

點擊Dependencies字段中的Add連接，在彈出頁面中選擇需要依賴的觸發(fā)器點擊Select按鈕即可。

介紹完觸發(fā)器配置頁面各參數(shù)的含義，下面通過為Zabbix server主機中定義的agent.ping監(jiān)控項創(chuàng)建觸發(fā)器的過程來看看觸發(fā)器創(chuàng)建的步驟。

1、???在Trigger標簽中的Name字段中填寫觸發(fā)器的名稱，例如Zabbixagent on {HOST.NAME} is unreachable for 5 minutes。在名稱中我們使用了宏變量{HOST.NAME}，這樣我們在通知中能看到是哪個主機觸發(fā)告警。

2、???在Expression字段中我們填寫表達式。如果對表達式足夠熟悉，在這里自己手工輸入就可以?；蛘唿c擊右側的Add按鈕在彈出頁面中選擇和設置各項參數(shù)。如下圖8-5所示。

圖 8-5

???????? 在本例中監(jiān)控項選擇Zabbix server主機中定義的Agent.ping，Function中選擇No datareceived during period of time T,then N = 1,0 – otherwise ，Last of（T）中設置時間參數(shù)，N中設置常量。點擊 Insert按鈕返回。此時我們會看到Expression字段中已經(jīng)有了一個表達式。如下圖8-6所示。

圖8-6

3、???點擊Expression字段下面的Expression constructor測試表達式，在這里也可以構造復雜的表達式。如下圖8-7所示。

圖 8-7

勾選需要測試的表達式，點擊Test進入測試頁面，選擇表達式返回值VALUE為1，點擊Test按鈕可以看到表達式的結果，TRUE為1，FALSE為0。如下圖8-8所示

圖 8-8

4、???需要每次都生成告警事件時選中MultiplePROBLEM events generation。

5、???填寫觸發(fā)器的描述信息。

6、???可選填寫觸發(fā)器的相關URL。

7、???選擇觸發(fā)器的告警級別。

8、???如啟用該觸發(fā)器勾選此項。

9、???該觸發(fā)器依賴其他觸發(fā)器時，到Dependencies標簽頁面中添加。

10、點擊Add按鈕保存。

8.2 事件

Zabbix中的Event（事件）是基于時間戳的，記錄某一時刻發(fā)生了什么事。事件本身沒有什么意義，但在Zabbix告警體系中有很重要的位置，事件是系統(tǒng)生成動作（如發(fā)送告警郵件）的基礎。

Zabbix中生成的事件類型主要有以下幾種：

• trigger events（觸發(fā)器事件）：每當一個觸發(fā)器的狀態(tài)發(fā)生變化時（OK --> PROBLEM --> OK）生成事件，是Zabbix中使用最頻繁和最重要的事件來源。

• discovery events（發(fā)現(xiàn)事件）：當檢測到主機或服務時生成事件。例如，每次Zabbix監(jiān)測到Service Up或Service Down，Host Up 或Host Down，Host Discovered或Host Lost等。

• auto registration event（自動注冊事件）：當?active agent?是由服務器自動注冊時生成事件。

• internal events（內(nèi)部事件）：當一個監(jiān)控項或low-level discovery規(guī)則變?yōu)?/span>unsupported（不支持）/ normal（正常），觸發(fā)器的狀態(tài)變?yōu)?/span>unknown（未知）/ normal時生成事件。

在Monitoring --> Events頁面中點擊事件的日期和時間可以瀏覽每個事件的詳細情況。

8.3 動作

當系統(tǒng)中產(chǎn)生相應的事件后，需要發(fā)送通知或執(zhí)行命令等，在Zabbix中如何解決的呢？實際上Zabbix提供了獨立的Actions（動作）組件，對系統(tǒng)中產(chǎn)生的多種類型的事件作出響應，動作是完全獨立于主機和模板的，每個動作是全局定義的。

每個動作由三個部分組成，分別是：

• 動作的定義

• 觸發(fā)動作的條件

• 動作執(zhí)行的操作

• 創(chuàng)建動作

在Configuration --> Actions頁面右上角，點擊Event source下拉框選擇事件源，然后點擊Createaction按鈕進入配置頁面。如下圖8-9所示。

圖 8-9

Action標簽中各參數(shù)的含義如下：

• Name：唯一的動作名稱。

• Default subject：默認標題，可以包含宏變量。

• Default message：默認信息內(nèi)容，可以包含宏變量。

• Recovery message：勾選后，故障恢復正常時（PROBLEM --> OK）會發(fā)送一次恢復信息。需要注意的是，要接收一個恢復信息，在action conditions中必須設置Triggervalue=Problem。Trigger value=OK不需要設置，否則恢復信息不會發(fā)送。恢復信息從PROBLEM事件中繼承acknowledgment狀態(tài)和歷史（當使用{EVENT.ACK.HISTORY} 和{EVENT.ACK.STATUS}宏變量時）。如果在恢復信息中使用 {EVENT.*} 宏變量，它將從PROBLEM事件引用。{EVENT.RECOVERY.*} 宏變量只能在恢復信息中擴展使用，它將從recovery/OK事件引用。

• Recovery subject：恢復信息標題?？梢园曜兞?。

• Recovery message：恢復信息，可以包含宏變量。

• Enabled：勾選此項為啟用該動作。

在這個配置頁面，我們可以給動作配置一個唯一的名稱，定義一個默認的信息，在信息中可以引用特定事件有關的數(shù)據(jù)，例如主機、監(jiān)控項或觸發(fā)器的名稱，監(jiān)控項和觸發(fā)器的值，還有URL等。

當我們創(chuàng)建動作時，系統(tǒng)在默認的信息中已經(jīng)使用了一些宏變量。實際上，由于動作是全局的，所有在Zabbix中定義的宏變量都可以在動作的信息中使用。另外觸發(fā)器能夠從多個主機監(jiān)測多個監(jiān)控項，你可以引用所有涉及到的主機和監(jiān)控項（最多9個不同的主機或監(jiān)控項）。通過使用這些宏變量可以提供豐富的信息內(nèi)容，當你看到發(fā)送的信息時能夠了解故障相關的詳細信息。

默認的信息可以通過多種方式發(fā)送，例如通過郵件、SMS、chat等，可以在動作中定義使用不同的告警發(fā)送方式發(fā)送信息。

8.3.2動作條件的配置

一個事件只有匹配定義的conditions時action才會執(zhí)行。在Conditions標簽頁面中我們可以定義基于事件的主機、觸發(fā)器和觸發(fā)器值的conditions，在這里可以通過AND/OR結合不同的單一條件組合成我們需要的conditions。如下圖8-10所示。

圖 8-10

Conditions標簽頁面中各參數(shù)的含義如下：

• Type of calculation：運算類型（各condition之間的邏輯運算符）。選項有：

• AND：所有條件必須同時滿足。

• OR：滿足條件中的一個即可。

• AND/OR：條件的組合。不同類型的條件用AND，同類型的條件用OR。例如。

Host group?= Oracle servers
Host group?= MySQL servers
Trigger name?like 'Database is down'
Trigger name?like 'Database is unavailable'

結果為：

(Host group= Oracle servers?or?Hostgroup = MySQL servers)?and?(Trigger name like 'Database is down'?orTrigger name like 'Database is unavailable')

• Custom expression：用戶自定義的計算公式，公式中必須包括所有的條件（大寫的A、B、C等），and或者or（小寫），也可以包括空格、制表符和括號。在AND/OR中的例子表示成(A or B) and (C or D)，自定義的表達式可以是多種形式的，如：(A and B) and (C or D) ，(A and B) or(C and D) ，((A or B) and C) or D 等等。

• Conditions：添加的條件。

• New condition：選擇要添加的條件，根據(jù)不同的事件來源可供選擇的項目會有所不同。支持的操作符有：

• = 等于

• <> 不等于

• like 包含

• not like 不包含

每次創(chuàng)建動作時，系統(tǒng)會自動添加兩個條件（可以刪除）：

• Trigger value = PROBLEM：只在PROBLEM時發(fā)送信息。如果你想接收一個恢復信息，這個條件必須設置。

• Maintenance status = notin?maintenance：主機維護期間不發(fā)送信息。

如果觸發(fā)器的狀態(tài)從OK變成PROBLEM，當前觸發(fā)器的狀態(tài)為PROBLEM。如果觸發(fā)器的狀態(tài)從PROBLEM變成OK，當前觸發(fā)器的狀態(tài)為OK。

8.3.3 動作執(zhí)行操作的配置

通過Operations標簽中的設置，可以定義動作中實際要采取的操作，主要有兩方面組成：一方面是定義操作的steps（步驟），另一方面是定義每個步驟中實際的操作。

最簡單的場景就是只定義了一個步驟，在這個步驟中將默認的信息發(fā)送給一組已定義的收件人。但在實際環(huán)境中，特定需求會讓場景變得越來越復雜，需要定義多個步驟和操作。

點擊Operations標簽并點擊Actionoperations中的New鏈接，操作的配置頁面如下圖8-11所示。

圖8-11

Operations標簽頁面中各參數(shù)的含義如下：

• Default operation step duration：每個操作步驟中默認的時間間隔，最小為60秒。

• Action operations：顯示動作中定義的操作。

• Operation details：每個操作的詳細配置。

• Step：定義操作的步驟。如上圖中是從1到1。這里需要注意如果定義成0意味這個這個步驟會一直執(zhí)行下去，直到觸發(fā)器的狀態(tài)發(fā)送變化。

• Step duration：步驟中使用的時間間隔。最小為60秒，如設置為0則使用Default operation step duration 中定義的值。多個操作可以分配給相同的步驟，如果這些操作使用不同的Step duration，則使用定義最短的時間間隔。

• Operation type：操作類型是send message。

• Send to user groups：點擊Add去選擇接收信息的用戶組，這個用戶組在主機上至少要有讀權限。

• Send to users：點擊Add去選擇接收信息的用戶，這個用戶在主機上至少要有讀權限。

• Send only to：發(fā)送信息到所有定義的media（告警方式）或選定的用戶。

• Default message：如果選中，將發(fā)送定義的默認信息。

• Subject：自定義信息的標題。

• Message：自定義信息的內(nèi)容，內(nèi)容中可以使用宏變量。

• Operation type：操作類型是remote command

• Target list：選擇在當前主機（current host）、其他主機或主機組中執(zhí)行命令。

• Type：選中命令的類型：IPMI、Custom script、SSH、Telnet或Global script。

• Execute on：在Zabbix agent或Zabbix server上執(zhí)行。

• Commands：需要執(zhí)行的命令。

• Conditions：執(zhí)行操作的條件，Not Ack為僅在沒有對事件響應時執(zhí)行，Ack為僅在對事件響應后執(zhí)行。

• 不同事件中操作的定義

在所有事件中都可以定義的操作有：

• 發(fā)送信息（sendmessage）

• 執(zhí)行遠程命令（remotecommand）

Discovery 事件中可以定義的操作有：

• add host（添加主機）

• remove host（刪除主機）

• enable host（啟用主機）

• disable host（禁用主機）

• add to group（添加到組）

• delete from group（從組中刪除）

• link to template（鏈接到模板）

• Unlink to template（取消到模板的鏈接）

• set host inventory mode（設置主機資產(chǎn)記錄的模式）

auto-registration事件中可以定義的操作有：

• add host（添加主機）

• disable host（禁用主機）

• add to group（添加到組）

• link to template（鏈接到模板）

• set host inventory mode（設置主機資產(chǎn)記錄的模式）

• 發(fā)送信息的配置

當出現(xiàn)故障時通過發(fā)送告警信息是通知管理者最簡單有效的方法，也是Zabbix中使用最多的方法。

為了能正常發(fā)送和接收信息，首先需要定義media（告警方式）和使用該media的信息接收人（用戶），其次需要配置動作。信息接收人必須對這些主機產(chǎn)生的事件有讀權限，能夠正常訪問觸發(fā)器的表達式，否則信息發(fā)送不會成功。

信息發(fā)送的情況可以通過Monitoring --> Events頁面中查看，在頁面Actions列中可以看到完成動作的統(tǒng)計信息，綠色的數(shù)字表示發(fā)送信息，紅色的In progress表示正在執(zhí)行action，Failed表示動作執(zhí)行失敗。如果點擊事件的日期和時間的鏈接，在事件詳細頁面中的Message action中可以看到該事件中詳細的信息發(fā)送成功或失敗的情況。在Reports --> Action log頁面中可以看到所有動作詳細情況。

在Operations標簽中，點擊New鏈接添加step，選擇Operation type為Send message，如下圖8-12所示。

圖 8-12

在上圖8-12中，配置了step 1 到 5，每過10分鐘發(fā)送一次信息。

?

8.3.3.1 遠程命令的配置

當滿足條件時可以在被監(jiān)控主機上執(zhí)行事先定義好的命令，完成一些特定的任務，例如：

• 一些應用（web 服務器、中間件、CRM等）沒有響應時自動重啟。

• 服務器不響應時使用IPMI重啟服務器。

• 磁盤空間滿后清除無用的文件釋放空間。

• 根據(jù)CPU負載情況把虛擬機從一個物理機遷移到另一個物理機。

• 當一個云基礎設施中的資源（CPU、內(nèi)存、磁盤等）添加或刪除新的節(jié)點。

配置遠程命令的動作和發(fā)送信息的動作類似，不同的只是定義的操作類型不同。配置遠程命令的動作時有一些限制，遠程命令不能超過255個字符；不支持active agent方式；不支持由Zabbix proxy監(jiān)控的Zabbix agent上執(zhí)行遠程命令（如果需要建議從Zabbix server 直接連接到agent）。遠程命令中可以包含宏變量，也可以執(zhí)行多行命令。需要在Zabbix agent上支持命令（customscripts）時，必須在zabbix_agentd.conf中將EnableRemoteCommands參數(shù)設置為1，并重啟zabbix agent服務使配置生效。

下面通過一個例子看一下配置遠程命令的步驟。

在Configuration --> Actions頁面右上角，點擊Event source下拉框選擇事件源，然后點擊Createaction按鈕進入配置頁面。在Action標簽中配置名稱和默認信息，在Conditions標簽中配置條件，如下圖8-13所示。

圖 8-13

在Operations標簽中添加操作，operationtype選擇remote command。如下圖8-14所示。

圖 8-14

在本例中Zabbix將通過命令 sudo/etc/init.d/apache restart重新啟動Apache服務，要確認命令可以在Zabbix agent上執(zhí)行，需要配置zabbix用戶能夠執(zhí)行sudo。

# visudo

zabbix ALL=NOPASSWD: ALL?? ????? ?# 允許zabbix用戶運行所有的命令時不需要密碼

或者配置zabbix用戶只執(zhí)行重啟apache服務

zabbix ALL=NOPASSWD: /etc/init.d/apache restart? ???????????? ?#只允許重啟apache服務

8.3.3.1 告警升級的配置

即使動作依賴于一個單一的事件，也并不是說它只能執(zhí)行一個單一的操作，實際上，它可以執(zhí)行任意數(shù)量的操作，甚至是在無限長的時間內(nèi)或直到執(zhí)行操作的條件發(fā)生變化。完成這些需要我們配置Escalation（告警升級）。在多個Escalationstep中可以同時發(fā)送告警信息或自動化執(zhí)行命令，可以將告警信息發(fā)送到不同的用戶組或用戶，也可以在故障沒有解決或事件沒有acknowledged（響應）之前同一信息定期重復發(fā)送。

通過Escalation配置可以實現(xiàn)靈活多變的告警，我們可以實現(xiàn)：

• 發(fā)生故障后第一時間通知用戶。

• 可以重復發(fā)送告警通知直到故障解決。

• 延遲發(fā)送告警通知。

• 告警信息可以逐級發(fā)送，根據(jù)情況可以設置將信息發(fā)送給部門經(jīng)理或更高級的用戶。

• 遠程命令可以發(fā)生故障后立即執(zhí)行，也可以在一段時間內(nèi)沒有解決故障后執(zhí)行。

• 可以發(fā)送故障恢復信息。

?

下面我們通過舉兩個例子來看看，例子一的配置如下圖8-15所示。

?

圖 8-15

從上圖8-15中我們看到step 1是立即執(zhí)行的，發(fā)送信息到一個用戶組，然后延遲1分鐘執(zhí)行后續(xù)步驟。一分鐘后開始執(zhí)行step 2，在主機上執(zhí)行遠程命令。在step 2中使用了默認的時間間隔3600秒，因此在過了1小時后開始執(zhí)行step 3，步驟3、4、5的配置是相同的，每隔10分鐘會發(fā)送信息到用戶組。30分鐘后開始執(zhí)行step 6，在這個步驟中我們添加了一個條件Event acknowledged = Not Ack，因此事件還沒有響應時會發(fā)送信息到admin用戶。你可能注意到step 6的下一個步驟是step 0，step 0 的意思是永遠執(zhí)行這一步，它會按照步驟中設置的Duration(sec)這個時間間隔不斷重復的執(zhí)行下去，直到觸發(fā)器的狀態(tài)發(fā)生變化。但是如果你在動作中沒有使用Trigger value = PROBLEM這個條件，即使觸發(fā)器狀態(tài)變成OK時step 0也會一直執(zhí)行下去，因此需要設置step 0時一定要小心。

例子二配置如下圖8-16所示。

?

圖 8-16

動作中默認操作步驟時間間隔是1800秒，開始執(zhí)行后Step 1 - 4 分別在0:00、0:30、1:00、1:30給MySQL administrators發(fā)送信息。Step 5和6在2:00和2:10給Database manager發(fā)送信息（step 6不是3:00發(fā)送信息，是因為后面step 5 - 7中設置的600秒覆蓋了step 5-6中的設置）。Step 5 - 7在2:00、2:10、2:20發(fā)送信息（step duration設置時600秒）。Step 11在4:00發(fā)送信息（step 8 – 11使用默認的時間間隔1800秒）。

在實際環(huán)境中使用告警升級時需要注意下面一些情況：

• 在主機進入維護狀態(tài)時，正在執(zhí)行的動作中定義的操作會繼續(xù)執(zhí)行，維護狀態(tài)只影響動作，對動作中定義的操作沒有任何影響。

• 動作中定義的Timeperiod結束時，正在執(zhí)行的動作中定義的操作會繼續(xù)執(zhí)行，Timeperiod只影響動作，對動作中定義的操作沒有任何影響。

• 維護狀態(tài)中發(fā)生故障，并在維護狀態(tài)結束后還沒有解決時，動作中定義的告警升級步驟在維護結束后開始執(zhí)行。

• 在無數(shù)據(jù)的維護期間發(fā)生故障直到維護結束后還沒有解決時，必須等觸發(fā)器觸發(fā)后才能執(zhí)行定義的告警升級步驟。

• 不同告警升級步驟的配置重疊時，每一個新的告警升級的執(zhí)行將取代前面的告警升級，前面的告警升級不管有多少步驟，至少執(zhí)行一步。

• 告警升級執(zhí)行過程中，如果出現(xiàn)動作禁用、基于觸發(fā)器的事件刪除、觸發(fā)器禁用或刪除、觸發(fā)器相關的主機或監(jiān)控項禁用、監(jiān)控項禁用或刪除、主機禁用等情況時，正在發(fā)送中的信息和告警升級中配置的其他信息會被發(fā)送。只是后面發(fā)送的信息中會加上(NOTE: Escalation cancelled)，比如說動作禁用時會在信息前加上NOTE: Escalation cancelled: action '<Action name>' disabled，通過這種方法通知用戶取消告警升級。取消的原因也可以通過設置Debug Level = 3從日志文件中查看。

• 告警升級執(zhí)行過程中動作被刪除后，不會在發(fā)送信息。設置Debug Level = 3時從日志文件中可以查看，如escalationcancelled: action id:334 deleted。

本文出自?http://ustogether.blog.51cto.com/8236854/1929384，如需轉載請與作者聯(lián)系。