トリガーで使用される式は、柔軟性があります。
これらを使用して、監視する統計に関する複雑な論理テストを作成することができます。
単純な式は、いくつかのパラメータを持つ項目に適用される関数を使用します。この関数は、演算子と定数を使用して、
閾値と比較される結果を返します。
式の構文はfunction(/host/key,parameter)<operator><constant>
です。
例:
は、過去5分間の受信バイト数が常に100キロバイト以上であった場合に trigger されます。
構文は全く同じですが、機能的な観点からは、2種類のトリガー式があります:
問題式を単独で定義した場合、この式は問題閾値と問題回復閾値の両方として使用されます。
問題式が "TRUE" と評価されるとすぐに、問題が発生します。問題式が "FALSE" と評価されるとすぐに、問題は解決されます。
問題式と回復式の両方を定義する場合、問題解決はより複雑になります:
問題式がFALSEであるだけでなく、回復式もTRUEでなければなりません。これは、hysteresisを作成して、トリガーのバタつきを回避するのに便利です。
収集した値の計算(平均、最小、最大、合計)、文字列の検索、現在時刻の参照などを行うことができる関数です。
supported functionsの完全なリストが利用可能です。
通常、関数は比較のために数値を返します。文字列を返す場合、= および <> 演算子で比較が可能です 。
(example を参照してください)
関数パラメータでは、以下の項目を指定できます。
ホストと item のキーは /host/key
として指定することができます。参照する item はサポートされている状態でなければなりません。
(ただし、nodata()関数はサポートされていないアイテムについても計算されます)
関数パラメータとしての他の trigger 式は、trigger における非 history 関数に制限されますが、
calculated itemsでは、この制限は適用されません。
関数別パラメータは、item キーの後に置かれ、item キーとカンマで区切られます。
これらのパラメータの一覧は、supported functionsを参照してください。
数値関数のほとんどは、パラメータとして時刻を受け付けます。この場合、秒、またはtime suffixesを使って
時間を表すことができます。
ハッシュタグを前に付けると、そのパラメータは別の意味を持ちます。
式 | 説明 |
---|---|
sum(/host/key,10m) | 過去10分間の値の総和 |
sum(/host/key,#10) | 直近の10件の値の合計値 |
ハッシュタグの付いたパラメータは、関数 last では異なる意味を持ちます - N 番目の前の値を示します。
オプションのタイム シフトは、関数パラメーターとして時間または値カウンタでサポートされます。 このパラメーターを使用すると、過去のある期間のデータを参照できます。
タイム シフトは、現在の時間を指定する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 であることに注意してください。
パラメータ | 説明 |
---|---|
1d:now/d | 昨日 |
1d:now/d+1d | 当日 |
2d:now/d+1d | 過去 2 日間 |
1w:now/w | 先週 |
1w:now/w+1w | 今週 |
関数のパラメータは、次のように他の式を含むことができます。
関数が item history を参照する場合、他の式を使用することはできませんのでご注意ください。
例えば、次のような構文は使用できません。
min(/host/key,#5*10)
trigger では、以下の演算子がサポートされています(実行優先度の高い順):
優先度 | 演算子 | 定義 | 不明な値の注意事項 | オペランドを強制的にfloatにする 1 |
---|---|---|---|---|
1 | - | 単項負 | -Unknown → Unknown | Yes |
2 | not | 論理否定 | not Unknown → Unknown | Yes |
3 | * | 乗算 | 0 * Unknown → Unknown (yes, Unknown, not 0 - 算術演算では不明) 1.2 * Unknown → Unknown |
Yes |
/ | 分割 | Unknown / 0 → error Unknown / 1.2 → Unknown 0.0 / Unknown → Unknown |
Yes | |
4 | + | 算術プラス | 1.2 + Unknown → Unknown | Yes |
- | 算術マイナス | 1.2 - Unknown → Unknown | Yes | |
5 | < | 未満。 演算子は次のように定義されます: A<B ⇔ (A<B-0.000001) |
1.2 < Unknown → Unknown | Yes |
<= | 以下。 演算子は次のように定義されます: A<=B ⇔ (A≤B+0.000001) |
Unknown <= Unknown → Unknown | Yes | |
> | 超過。 演算子は次のように定義されます: A>B ⇔ (A>B+0.000001) |
Yes | ||
>= | 以上。 演算子は次のように定義されます: A>=B ⇔ (A≥B-0.000001) |
Yes | ||
6 | = | 等しい。 演算子は次のように定義されます: A=B ⇔ (A≥B-0.000001) and (A≤B+0.000001) |
No 1 | |
<> | 等しくない。 演算子は次のように定義されます: A<>B ⇔ (A<B-0.000001) or (A>B+0.000001) |
No 1 | ||
7 | and | 論理積 | 0 and Unknown → 0 1 and Unknown → Unknown Unknown and Unknown → Unknown |
Yes |
8 | or | 論理和 | 1 or Unknown → 1 0 or Unknown → Unknown Unknown or Unknown → Unknown |
Yes |
1 文字列オペランドが数値にキャストされるのは、以下の場合です:
(キャストに失敗した場合、数値オペランドは文字列オペランドにキャストされ、両方のオペランドは文字列として比較されます)。
not, and, or 演算子は大文字と小文字を区別する。また、空白または括弧で囲む必要があります。
単項の-とnotを除くすべての演算子は、左から右への連想性を持っています。
単項の-とnotは非連想性である(つまり、-(-1)とnot (not 1)は、--1とnot 1の代わりに使用すべきです。)。
評価結果:
trigger 評価に必要な値は、Zabbix server によってキャッシュされます。
このため、server 再起動後のしばらくの間、trigger 評価によるデータベースの負荷が高くなります。
item history の値を削除しても(手動またはhousekeeperで)キャッシュはクリアされないため、trigger 関数で定義した期間より古い値になるか、
server が再起動されるまで、キャッシュされた値が使用されます。
Zabbix server のプロセッサの負荷が高すぎます。
関数 'last()' を使用することで、最新の値を参照することができます。
/Zabbix server/system.cpu.load[all,avg1]
には監視するパラメータのショートネームが入ります。
ホストが Zabbix server で、監視するキーが system.cpu.load[all,avg1] であることを指定します。最後に、>5
は、Zabbix server からの
最新のプロセッサ負荷測定値が 5 より大きい場合、トリガーが PROBLEM 状態になることを意味します。
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" となります。
/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のチェックサムの以前の値が最新の値と異なる場合に真となります。
同様の式は、/etc/passwd, /etc/inetd.conf, /kernel などの重要なファイルの変更を監視するのに便利でしょう。
誰かがインターネットから大きなファイルをダウンロードしている。
min 関数を使って:
eth0の受信バイト数が過去5分以内に100KB以上であれば,この式は "TRUE" となります。
クラスタ化された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サーバがダウンしている場合、この式は成立します。
Zabbix agent のアップグレードが必要
関数find()を使用して:
この式は、Zabbix agent のバージョンがbeta8である場合に "TRUE" となります。
サーバにアクセスできない
この式は、ホスト "example.example.com "が過去30分間に5回以上到達不能になった場合に "TRUE" となる。
過去3分以内に heartbeats がない。
関数nodata()を使用して:
この trigger を使用するには、Zabbix trapper item として'tick'を定義する必要があります。
ホストはこの item のデータを zabbix_sender を使用して定期的に送信する必要があります。180 秒以内にデータが受信されないと、
trigger の値が PROBLEM になります。
注意 'nodata' は任意の item タイプに使用できることに注意してください。
夜間の CPU アクティビティ
関数time()を使用
トリガーの状態が障害に変わるのは夜間(00:00 - 06:00)のみです。
例外を除く任意の時点での 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)を除いて、状態が障害に変わる可能性があります。
クライアントのローカルタイムがZabbixサーバのタイムと同期しているかどうかを確認します。
関数fuzzytime()を使用して:
MySQL_DB と Zabbix server のローカルタイムが10秒以上異なる場合、trigger は障害状態に変更されます。 'system.localtime' は パッシブチェック として設定する必要があることに注意してください。
今日の平均負荷と昨日の同時刻の平均負荷を比較します (タイム シフトをnow-1d
として使用)。
この式は、過去 1 時間の平均負荷が昨日の同じ時間の平均負荷を 2 回以上超えた場合に起動します。
別のアイテムの値を使用して、トリガーのしきい値を取得します。
last(/Template PfSense/hrStorageFree[{#SNMPVALUE}])<last(/Template PfSense/hrStorageSize[{#SNMPVALUE}])*0.1
空き容量が 10% を下回ると、トリガーが起動します。
評価結果を使用して、しきい値を超えるトリガーの数を取得します。
(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つが真である場合、トリガーが起動します。
2 つのアイテムの文字列値の比較 - ここでのオペランドは、文字列を返す関数です。
問題: ホストによって Ubuntu のバージョンが異なる場合にアラートを作成する
last(/NY Zabbix server/vfs.file.contents[/etc/os-release])<>last(/LA Zabbix server/vfs.file.contents[/etc/os-release])
2つの文字列値の比較 - オペランドは次の通りです:
問題:DNSクエリの変更を検出する
アイテムキーは次の通りです:
次のように定義されたマクロを使用します。
通常は以下を返します。
したがって、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 番目のオペランドが引用符で囲まれていることに注意してください。
2 つの文字列値の比較 - オペランドは次のとおりです:
問題: /tmp/hello
ファイルの内容が以下と等しいかどうかを検出します。
オプション 1) 文字列を直接書き込む
文字列が直接比較されるときに、\ と " の文字がどのようにエスケープされるか注意してください。
オプション 2) マクロを使用する
式:
長期間の比較
問題:先月、Exchange server の負荷が10%以上増加した。
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 設定において手動で閉じることができるようにすることも有効です。
問題状態と回復状態の間に単純な閾値ではなく、インターバルが必要な場合があります。
例えば、サーバルームの温度が20℃以上になったときに問題を報告する trigger を定義し、温度が15℃以下に下がるまで
問題状態を維持したい場合、20℃の単純な trigger 閾値では十分ではありません。
その代わりに、最初に問題が発生した問題事象(温度が20℃以上)に対する trigger 式を定義する必要があります。
次に、回復条件(温度15℃以下)を追加で定義する必要があります。
これは、次のように定義することで行われます。Recovery expression パラメータを定義し、defining trigger
を定義します。
この場合、問題の回復は2つのステップで行われます。
回復式は、問題事象が先に解決された場合にのみ評価されます。
リカバリー式が "TRUE" であることだけでは、問題式がまだ "TRUE" である場合に問題を解決することができません!
サーバールームの温度が高すぎる
問題式:
回復式:
空きディスク容量が少なすぎる
問題式: 直近5分間の空きディスク容量が10GB以下
回復式: 問題式: 直近10分間の空きディスク容量が40GB以上
通常、未知のオペランド (サポートされていないアイテムなど) は、トリガー値をすぐに'不明’にレンダリングします。
ただし、未知のオペランド (サポートされていないアイテム、関数エラー等) が式の評価に認められる場合があります。
nodata()
関数は、参照された項目がサポートされているかどうかに関係なく評価されます。1 or some_function(unsupported_item1) or some_function(unsupported_item2) or ...
" は既知の結果 ('1' または "障害") に評価できます。0 and some_function(unsupported_item1) and some_function(unsupported_item2) and ...
" は、既知の結果 ('0' または "OK") に評価できます。不明
になり、以降の式の評価で不明なオペランドとして使用されます。上記のように、未知のオペランドは論理式でのみ「消える」場合があることに注意してください。 算術式では、未知のオペランドの結果は常に 不明
になります (0 による除算を除く)。
不明
になる式は、トリガーの状態 ("障害/OK") を変更しません。 したがって、状態が"障害" (ケース 1 を参照) であった場合、既知の部分が解決されても ('1'が'0'になる)、トリガー状態を変更せず同じ障害状態のままになります。
サポートされていないアイテムがいくつかあるトリガー式が不明
と評価される場合、フロントエンドのエラー メッセージは、最後に評価されたサポートされていないアイテムを参照します。