2 トリガー条件式

Overview

triggersで使用される式は、柔軟性があります。
これらを使用して、監視する統計に関する複雑な論理テストを作成することができます。

単純な式は、いくつかのパラメータを持つ項目に適用される関数を使用します。この関数は、演算子と定数を使用して、
閾値と比較される結果を返します。

単純で便利な式のシンタックスは function(/host/key,parameter)<operator><constant> です。

例:

  min(/Zabbix server/net.if.in[eth0,bytes],5m)>100K

は、過去5分間の受信バイト数が常に100キロバイト以上であった場合に trigger されます。

構文は全く同じですが、機能的な観点からは、2種類のトリガー式があります:

• problem expression - 問題の条件を定義します。
• recovery expression (オプション) - 問題解決のための追加条件を定義します。

問題式を単独で定義した場合、この式は問題閾値と問題回復閾値の両方として使用されます。
問題式が "TRUE" と評価されるとすぐに、問題が発生します。問題式が "FALSE" と評価されるとすぐに、問題は解決されます。

問題式と回復式の両方を定義する場合、問題解決はより複雑になります：
問題式がFALSEであるだけでなく、回復式もTRUEでなければなりません。これは、hysteresisを作成して、
トリガーのバタつきを回避するのに便利です。

関数

収集した値の計算（平均、最小、最大、合計）、文字列の検索、現在時刻の参照などを行うことができる関数です。

supported functionsの完全なリストが利用可能です。

通常、関数は比較のために数値を返します。文字列を返す場合、= および <> 演算子で比較が可能です 。
(example を参照してください)

関数パラメータ

関数パラメータでは、以下の項目を指定できます。

• ホストと item キー(ホストの item history を参照する機能のみ)
• 関数固有のパラメータ
• その他の式 (ホスト item の history を参照する関数では使用できません。例については other expressions を参照してください)

ホストと item のキーは /host/key として指定することができます。参照する item はサポートされている状態でなければなりません。
（ただし、nodata()関数はサポートされていないアイテムについても計算されます）

関数パラメータとしての他の trigger 式は、trigger における非 history 関数に制限されますが、
calculated itemsでは、この制限は適用されません。

関数別パラメータ

関数別パラメータは、item キーの後に置かれ、item キーとカンマで区切られます。
これらのパラメータの一覧は、supported functionsを参照してください。

数値関数のほとんどは、パラメータとして時刻を受け付けます。この場合、秒、またはtime suffixesを使って
時間を表すことができます。
ハッシュタグを前に付けると、そのパラメータは別の意味を持ちます。

ハッシュタグの付いたパラメータは、関数 last では異なる意味を持ちます - N 番目の前の値を示します。

• last(/host/key,#2)`は'7'を返します。
• last(/host/key,#5)`は'5'を返します。

タイムシフト

オプションのタイム シフトは、関数パラメーターとして時間または値カウンタでサポートされます。 このパラメーターを使用すると、過去のある期間のデータを参照できます。

タイム シフトは、現在の時間を指定するnowで始まり、その後に+N<time unit>または-N<time unit>が続き、N 時間、加算または減算します。

たとえばavg(/host/key,1h:now-1d)は 1 日前の 1 時間の平均値を返します。

絶対時間帯による時間シフト

タイム シフト パラメーターでは、絶対時間帯がサポートされています。たとえば、1 日の場合は午前 0 時から午前 0 時、1 週間の場合は月曜日から日曜日、1 か月の場合は月の最初の日から最後の日です。

絶対時間帯の時間シフトはnowで始まります。現在の時間を指定し、その後に任意の数の時間操作が続きます: /<time unit> - 時間単位の開始と終了を定義します。たとえば1 日の午前 0 時から午前 0 時まで。+N<time unit> または -N<time unit> - N 時間単位の加算または減算。

タイム シフトの値は 0 以上で、期間の最小値は 1 であることに注意してください。

その他の式

関数のパラメータは、次のように他の式を含むことができます。

min(min(/host/key,1h),min(/host2/key2,1h)*10)

関数が item history を参照する場合、他の式を使用することはできませんのでご注意ください。
例えば、次のような構文は使用できません。

min(/host/key,#5*10)

演算子

trigger では、以下の演算子がサポートされています（実行優先度の高い順）:

¹ 文字列オペランドが数値にキャストされるのは、以下の場合です:

• 他のオペランドが数値である場合
• オペランドに = または <> 以外の演算子が使用されている場合。

(キャストに失敗した場合、数値オペランドは文字列オペランドにキャストされ、両方のオペランドは文字列として比較されます)。

not, and, or 演算子は大文字と小文字を区別する。また、空白または括弧で囲む必要があります。

単項の-とnotを除くすべての演算子は、左から右への連想性を持っています。
単項の-とnotは非連想性である(つまり、-(-1)とnot (not 1)は、--1とnot 1の代わりに使用すべきです。)。

評価結果:

• < , <= , > , >= , <> 演算子は、指定された関係が真であれば trigger に'1'を、偽であれば'0'をもたらすものとする。 少なくとも一つのオペランドが不明である場合、結果は不明です。
• 未知のオペランドに対して、and は、オペランドの両方が'0'と等しくない比較をした場合、'1'を生成し、それ以外の場合は、 '0'を生成します。
• 未知のオペランドに対しては、or は一方のオペランドが'0'と等しくない場合にのみ'1'を出力し、そうでない場合は'0'を出力します。
• 既知のオペランドに対する論理否定演算子 not の結果は、オペランドの値が '0' と等しくない場合は '0' となり、オペランドの値が '0' と 等しい場合は '1' となる。未知のオペランドに対しては、notは'Unknown'を生成します。

値のキャッシュ

trigger 評価に必要な値は、Zabbix server によってキャッシュされます。
このため、server 再起動後のしばらくの間、trigger 評価によるデータベースの負荷が高くなります。
item history の値を削除しても(手動またはhousekeeperで)キャッシュはクリアされないため、trigger 関数で定義した期間より古い値になるか、
server が再起動されるまで、キャッシュされた値が使用されます。

trigger の例

例1

Zabbix server のプロセッサの負荷が高すぎます。

last(/Zabbix server/system.cpu.load[all,avg1])>5

関数 'last()' を使用することで、最新の値を参照することができます。
/Zabbix server/system.cpu.load[all,avg1] には監視するパラメータのショートネームが入ります。
ホストが Zabbix server で、監視するキーが system.cpu.load[all,avg1] であることを指定します。最後に、>5 は、Zabbix server からの
最新のプロセッサ負荷測定値が 5 より大きい場合、トリガーが PROBLEM 状態になることを意味します。

例2

www.example.com は、過負荷になっています。

last(/www.example.com/system.cpu.load[all,avg1])>5 or min(/www.example.com/system.cpu.load[all,avg1],10m)>2 

この式は、現在のプロセッサ負荷が5以上であるか、過去10分間のプロセッサ負荷が2以上であった場合に "TRUE" となります。

例3

/etc/passwd が変更された。

(last(/www.example.com/vfs.file.cksum[/etc/passwd],#1)<>last(/www.example.com/vfs.file.cksum[/etc/passwd],#2))=1

この式は、/etc/passwdのチェックサムの以前の値が最新の値と異なる場合に "TRUE" となります。

同様の式は、/etc/passwd, /etc/inetd.conf, /kernel などの重要なファイルの変更を監視するのに便利でしょう。

例4

誰かがインターネットから大きなファイルをダウンロードしている。

min 関数を使って:

min(/www.example.com/net.if.in[eth0,bytes],5m)>100K

eth0の受信バイト数が過去5分以内に100KB以上であれば，この式は "TRUE" となります。

例5

クラスタ化されたSMTPサーバの両ノードがダウン

1つの式に2つの異なるホストが使用されていることに注意してください。

last(/smtp1.example.com/net.tcp.service[smtp])=0 and last(/smtp2.example.com/net.tcp.service[smtp])=0

smtp1.example.comとsmtp2.example.comの両方でSMTPサーバがダウンしている場合、この式は成立します。

例6

Zabbix agent のアップグレードが必要

関数find()を使用して:

find(/example.example.com/agent.version,,"like","beta8")=1

この式は、Zabbix agent のバージョンがbeta8である場合に "TRUE" となります。

例7

サーバにアクセスできない

count(/example.example.com/icmpping,30m,,"0")>5

この式は、ホスト "example.example.com "が過去30分間に5回以上到達不能になった場合に "TRUE" となる。

例8

過去3分以内に heartbeats がない。

関数nodata()を使用して:

nodata(/example.example.com/tick,3m)=1

この trigger を使用するには、Zabbix trapper item として'tick'を定義する必要があります。
ホストはこの item のデータを zabbix_sender を使用して定期的に送信する必要があります。180 秒以内にデータが受信されないと、
trigger の値が PROBLEM になります。

注意 'nodata' は任意の item タイプに使用できることに注意してください。

例 9

夜間の CPU アクティビティ

関数time()を使用し、

min(/Zabbix server/system.cpu.load[all,avg1],5m)>2 and time()>000000 and time()<060000

夜間 (00:00 ～ 06:00) にのみトリガーの状態を true に変更できます。

例 10

例外を除く任意の時点での CPU アクティビティ

関数 time() と not 演算子を使用:

min(/zabbix/system.cpu.load[all,avg1],5m)>2
       and not (dayofweek()=7 and time()>230000)
       and not (dayofweek()=1 and time()<010000)

トリガーは、各週の 2 時間 (日曜日の 23:00 から月曜日の 01:00) を除いて、いつでも状態を true に変更できます。

例11

クライアントのローカルタイムがZabbixサーバのタイムと同期しているかどうかを確認します。

関数fuzzytime()を使用して:

fuzzytime(/MySQL_DB/system.localtime,10s)=0

MySQL_DB と Zabbix server のローカルタイムが10秒以上異なる場合、trigger は障害状態に変更されます。 'system.localtime' は パッシブチェック として設定する必要があることに注意してください。

例 12

今日の平均負荷と昨日の同時刻の平均負荷を比較します (タイム シフトをnow-1dとして使用)。

avg(/server/system.cpu.load,1h)/avg(/server/system.cpu.load,1h:now-1d)>2

この式は、過去 1 時間の平均負荷が昨日の同じ時間の平均負荷を 2 回以上超えた場合に起動します。

例 13

別のアイテムの値を使用して、トリガーのしきい値を取得します。

last(/Template PfSense/hrStorageFree[{#SNMPVALUE}])<last(/Template PfSense/hrStorageSize[{#SNMPVALUE}])*0.1

空き容量が 10% を下回ると、トリガーが起動します。

例 14

評価結果 を使用して、しきい値を超えるトリガーの数を取得します。

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

式内のトリガーのうち少なくとも 2 つが 5 を超えている場合にトリガーが起動します。

例 15

2 つのアイテムの文字列値の比較 - ここでのオペランドは、文字列を返す関数です。

問題: ホストによって Ubuntu のバージョンが異なる場合にアラートを作成する

last(/NY Zabbix server/vfs.file.contents[/etc/os-release])<>last(/LA Zabbix server/vfs.file.contents[/etc/os-release])

例 16

2つの文字列値の比較 - オペランドは次の通りです:

• 文字列を返す関数
• マクロと文字列の組み合わせ

問題：DNSクエリの変更を検出する

アイテムキーは次の通りです:

net.dns.record[8.8.8.8,{$WEBSITE_NAME},{$DNS_RESOURCE_RECORD_TYPE},2,1]

次のように定義されたマクロを使用します。

{$WEBSITE_NAME} = example.com
       {$DNS_RESOURCE_RECORD_TYPE} = MX

通常は以下を返します。

example.com           MX       0 mail.example.com

したがって、DNS クエリの結果が期待される結果から逸脱しているかどうかを検出するためのトリガー式は次のとおりです:

last(/Zabbix server/net.dns.record[8.8.8.8,{$WEBSITE_NAME},{$DNS_RESOURCE_RECORD_TYPE},2,1])<>"{$WEBSITE_NAME}           {$DNS_RESOURCE_RECORD_TYPE}       0 mail.{$WEBSITE_NAME}"

2 番目のオペランドが引用符で囲まれていることに注意してください。

例 17

2 つの文字列値の比較 - オペランドは次のとおりです:

• 文字列を返す関数
• 特殊文字 \ および " を含む文字列定数

問題: /tmp/hello ファイルの内容が以下と等しいかどうかを検出します。

\" //hello ?\"

オプション 1) 文字列を直接書き込む

last(/Zabbix server/vfs.file.contents[/tmp/hello])="\\\" //hello ?\\\""

文字列が直接比較されるときに、\ と " の文字がどのようにエスケープされるか注意してください。

オプション 2) マクロを使用する

{$HELLO_MACRO} = \" //hello ?\"

式:

last(/Zabbix server/vfs.file.contents[/tmp/hello])={$HELLO_MACRO}

例 18

長期間の比較

問題：先月、Exchange server の負荷が10%以上増加した。

trendavg(/Exchange/system.cpu.load,1M:now/M)>1.1*trendavg(/Exchange/system.cpu.load,1M:now/M-1M)

trigger 設定のEvent nameフィールドを使って、例えば次のようなものを受け取るために、意味のある警告メッセージを構築することも可能です。

"Load of Exchange server increased by 24% in July (0.69) comparing to June (0.56)"

以下のようにイベント名を定義する必要があります:

Load of {HOST.HOST} server increased by {{?100*trendavg(//system.cpu.load,1M:now/M)/trendavg(//system.cpu.load,1M:now/M-1M)}.fmtnum(0)}% in {{TIME}.fmttime(%B,-1M)} ({{?trendavg(//system.cpu.load,1M:now/M)}.fmtnum(2)}) comparing to {{TIME}.fmttime(%B,-2M)} ({{?trendavg(//system.cpu.load,1M:now/M-1M)}.fmtnum(2)})

また、このような問題のために、trigger 設定において手動で閉じることができるようにすることも有効です。

ヒステリシス(Hysteresis)

問題状態と回復状態の間に単純な閾値ではなく、インターバルが必要な場合があります。
例えば、サーバルームの温度が20℃以上になったときに問題を報告する trigger を定義し、温度が15℃以下に下がるまで
問題状態を維持したい場合、20℃の単純な trigger 閾値では十分ではありません。

その代わりに、最初に問題が発生した問題事象（温度が20℃以上）に対する trigger 式を定義する必要があります。
次に、回復条件（温度15℃以下）を追加で定義する必要があります。
これは、次のように定義することで行われます。Recovery expression パラメータを定義し、defining trigger
を定義します。

この場合、問題の回復は2つのステップで行われます。

• まず、問題式(20℃以上の温度)は、"FALSE" に評価されなければなりません。
• 次に、リカバリー式(温度15℃以下)を "TRUE" に評価します。

回復式は、問題事象が先に解決された場合にのみ評価されます。

例1

サーバールームの温度が高すぎる

問題式:

last(/server/temp)>20

回復式:

last(/server/temp)<=15

例2

空きディスク容量が少なすぎる

問題式: 直近5分間の空きディスク容量が10GB以下

max(/server/vfs.fs.size[/,free],5m)<10G

回復式: 問題式: 直近10分間の空きディスク容量が40GB以上

min(/server/vfs.fs.size[/,free],10m)>40G

未知のオペランドを持つ式

通常、未知のオペランド (サポートされていないアイテムなど) は、トリガー値をすぐに'不明’にレンダリングします。

ただし、未知のオペランド (サポートされていないアイテム、関数エラー等) が式の評価に認められる場合があります。

• nodata() 関数は、参照された項目がサポートされているかどうかに関係なく評価されます。
• OR および AND を使用した論理式は、未知のオペランドに関係なく、次の 2 つのケースで既知の値に評価できます。
  • ケース 1: "1 or some_function(unsupported_item1) or some_function(unsupported_item2) or ..." は既知の結果 ('1' または "障害") に評価できます。
  • ケース 2: "0 and some_function(unsupported_item1) and some_function(unsupported_item2) and ..." は、既知の結果 ('0' または "OK") に評価できます。
    Zabbix は、サポートされていないアイテムを未知のオペランドとして取得することで、論理式を評価しようとします。 上記の 2 つのケースでは、既知の値が生成されます (それぞれ "障害" または "OK")が、その他すべてのケースでは、トリガーは'不明'と評価されます。
• サポートされているアイテムの関数評価でエラーが発生した場合、関数の値は不明になり、以降の式の評価で不明なオペランドとして使用されます。

上記のように、未知のオペランドは論理式でのみ「消える」場合があることに注意してください。 算術式では、未知のオペランドの結果は常に 不明 になります (0 による除算を除く)。

サポートされていないアイテムがいくつかあるトリガー式が不明と評価される場合、フロントエンドのエラー メッセージは、最後に評価されたサポートされていないアイテムを参照します。