2 トリガー条件式

概要

トリガーで使用される条件式は非常に詳細な指定が可能です。監視する統計情報に関して複雑な論理テストを作成できます。

シンプルで便利な条件式は、以下のようなものです：

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

1トリガー関数

トリガー関数は収集した値や、現在の時間、その他の要素を参照できます。

サポートされている関数のリストが使用可能です。

2 関数のパラメータ

数値関数のほとんどは、引数として秒数を受け取ります。

プリフィクス「#」を使用して、引数に別の意味を持たせることもできます：

last関数は、プリフィクス＃を使用している値に異なる意味 「n個前の値を選択させる」を持たせるので、直近3からさかのぼって値３、7、2、6、5が与えられている場合、last(#2) は7が返され、last(#5)は5が返されます。

パラメータは、それを無視する関数に対しても、与える必要があります。例：last(0)

加えて、avg、count、last、min、max 関数は、秒単位の time_shift パラメータをサポートしています。このパラメータは、過去のある期間のデータを参照することができます。例えば、avg(1h,1d) は、1日前の1時間の平均値が返ります。 トリガー関数内でサポートされている単位を使用できます。例えば、「300」秒のかわりに「5m」（分）、「86400」秒のかわりに「1d」（日）といった単位です。「1K」は「1024」バイトを示します。

3 演算子

トリガーでは以下の演算子がサポートされています（実行プライオリティの高い順）：

4 トリガー条件式の例

例1

Zabbixのプロセッサロードアベレージが高すぎる状態を検出する条件式

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

‘www.zabbix.com:system.cpu.load[all,avg1]’は監視するパラメータの簡易名です。サーバが「www.zabbix.com」、監視するキーが「system.cpu.load[all,avg1]」であることを指定します。関数「last()」は、最新の値を参照することを意味します。「>5」は、www.zabbix.comの最新のプロセッサロードアベレージが5より大きい場合にトリガーが障害になることを意味します。

例2

Zabbixが過負荷であることを検出する条件式

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

この条件式は、現在のプロセッサロードアベレージが5より大きいか、または直近10分間のプロセッサロードアベレージが2より大きい場合に障害になります。

例3

/etc/passwdが変更されたことを検出する条件式

diff関数を使用します：

{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff(0)}>0

この条件式は、/etc/passwdのチェックサムの前回値が最新値と異なる場合に障害になります。

同様の式を使用して、/etc/passwd、/etc/inetd.conf、/kernelなどの重要なファイルの変更を監視できます。

例4

誰かがインターネットから大きいサイズのファイルをダウンロードしていることを検出する条件式

min関数を使用します：

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

この条件式は、直近5分間にeth0で受信したバイト数が100KBを超えた場合に障害になります。

例5

クラスタ化されたSMTPサーバのノードが2つとも停止したことを検出する条件式 2つの異なるホストを1つの条件式に使用します：

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

この条件式は、smtp1.zabbix.comとsmtp2.zabbix.comの両方でSMTPサーバが停止した場合に障害になります。

例6

Zabbixエージェントをアップグレードする必要があることを検出する条件式

str()関数を使用します：

{zabbix.zabbix.com:agent.version.str("beta8")}=1

この条件式は、Zabbix エージェントのバージョンがbeta8(おそらく1.0beta8)である場合に障害になります。

例7

サーバとの疎通がなくなったことを検出する条件式

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

この条件式は、ホスト「Zabbix.zabbix.com」が直近の30分で5回以上疎通がない場合に障害になります。

例8

直近3分間で一度もハートビートを受信しなかったことを検出する条件式

nodata()を使用します：

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

「tick」のタイプには「Zabbixトラッパー」を選択します。このトリガーを使用するには、アイテム「tick」を定義する必要があります。ホストはzabbix_senderを使用して、このパラメータのデータを定期的に送信する必要があります。180秒間データを受信しないと、トリガーの値が障害になります。

例9

夜間のCPU使用率を監視する条件式

time()関数を使用します：

{zabbix:system.cpu.load[all,avg1].min(300)}>2&{zabbix:system.cpu.load[all,avg1].time(0)}>000000&{zabbix:system.cpu.load[all,avg1].time(0)}<060000

このトリガーが障害になるのは、夜間(00:00～06:00)だけです。

例10

クライアントのローカルタイムがZabbix サーバの設定と同期されているかどうかをチェックする条件式

fuzzytime()関数を使用します：

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

MySQL_DBサーバのローカルタイムとZabbixサーバのローカルタイムが10秒以上違っていると、このトリガーが障害になります。

例11

今日のロードアベレージと昨日の同じ時間のロードアベレージを比較する条件式（2番目の time_shift パラメータを使用）

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

この条件式は、直近1時間のロードアベレージが昨日の同じ時間より2倍以上になっている場合に、ステータスを「fire」にします。

5 ヒストリ

トリガーの状態ごとに異なるコンディションを設定する必要がある場合があります。たとえば、サーバ室の温度が20℃を超えたときに障害になり、その後は15℃を下回るまで障害を維持するトリガーを定義する場合を考えます。

この場合、以下のトリガーを定義します：

例1

サーバ室の温度が高すぎる状態を検出する条件式

({TRIGGER.VALUE}=0&{server:temp.last(0)}>20) |
       ({TRIGGER.VALUE}=1&{server:temp.last(0)}>15)

マクロ {TRIGGER.VALUE}の使用方法に注意してください。このマクロは現在のトリガー値を返します。

例2

空きディスク容量が少なすぎる状態を検出する条件式

障害：直近5分間の空きディスク容量が10GB以下

回復：直近10分間の空きディスク容量が40GB以上になったら

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

マクロ {TRIGGER.VALUE} の使用方法に注意してください。このマクロは現在のトリガー値を返します。

本ページは2013/05/04時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は右上の「Translations of this page」から英語版を参照してください。