Zabbixのトリガーとは
Zabbixではホスト(監視機器)にて収集するデータの設定としてアイテムを設定する。
アイテムはホストに直接設定するほかに、監視設定を定義しているテンプレートへ設定できる。
ホストからどのデータを収集するかをアイテム設定にて制御し、アイテムが障害となるか判断する設定としてトリガーがある。
基本としてホスト、アイテム、トリガーの設定で監視機器、監視内容、障害条件を構成していく。
また、障害となった際に実行するアクションという設定により
障害となった監視アイテムの処理を設定することになる。
トリガーは基本的に論理式(トリガーの条件式という)の構成となっている。
アイテムが収集したデータを設定したトリガーの条件式の結果から
監視の状態を以下のステータスに分類します。
|
状態 |
説明 |
備考 |
|
正常 |
トリガー条件式に合致しない(論理式の結果が偽の状態) |
|
|
障害 |
トリガー条件式に合致した状態(論理式の結果が正の状態) |
|
|
不明 |
トリガー条件式の計算ができない状態 |
アイテムが取得不可などにより発生 |
条件式に合致しない場合はトリガーは常に正常のステータスとなっている。
トリガー(Zabbix6.0)
https://www.zabbix.com/documentation/6.0/jp/manual/config/triggers
トリガーの設定
下記の設定画面にて各項目の設定を行います。

以下が設定する項目となります。
■必須項目
名前 : 任意の名称
条件式: 障害判定の式
■任意項目
深刻度: 障害の深刻度
正常イベントの生成:
トリガーが正常ステータスとする方式
L 条件式 :条件式の結果が偽で復旧
L 復旧条件式:復旧用の条件式で復旧
L なし : 自動で復旧しない
障害イベント生成モード:
障害のイベントを発行する方法
L 単一: トリガーステータスが正常の時のみ発行
L 複数: 条件式の結果が正になるたびに発行
手動クローズを許可:
生成された障害イベントを任意でクローズ操作可能にする
トリガーの条件式
記載した通りアイテムの取得した内容からどのような条件時に障害とするのか判定をする式を設定いたします。
※数学の時間に近い
先に説明いたしますが式の構成(構文)は以下となります。
function(/host/key,parameter)<operator><constant>
・function:計算の関数
・/host/key :対象ホストおよび障害判定を行うアイテムキー
・parameter:関数で設定するパラメータ
・operator:演算子(>,=など)
・constant: 演算子とする定数
トリガーの関数(function)
関数(function)はZabbixにて指定値が存在する。※数学でいう公式がある
5 サポートされている関数
https://www.zabbix.com/documentation/6.0/jp/manual/appendix/functions
例としまして上記マニュアルページにあるヒストリ関数のうち「last」という関数を紹介する。
last関数:アイテムの最後に取得した値に関する関数
使用例:last (/host/key,#1)>80
上記を説明すると「/host/key」の最後に取得した値(#1は最後から1番目を表す)が「80」を超えた場合。という条件式となる。
トリガー運用の考え方
先ほどの例で紹介したトリガーについて作成した考えとして以下のような設定依頼の元、作成された場合の運用を考える。
依頼事項:HOST1のCPUが80%を超えた際に障害としたい。
条件式:
last(/HOST1/system.cpu.util[all,system,],#1) >80
上記のように設定した場合、一見障害として通知されるため問題ないと考えるが
以下のように推移していた際にどうなるのか。
状態:最新値が80,81,79,81。。。というの推移の場合

図に記載した通り、2分ごとに障害と判断され、その都度、障害通知が発生し監視ステータスが正常と障害を行き来することとなる。
Zabbixの負荷にもなり、かつ顧客へのアラート設定を実施していた場合、大量にアラート発報が起きることで誤動作などが起きていると錯覚することにもなりかねない。
上記からアラート発報頻度を抑えるように以下の障害設計を考えてみる。
障害設計:3分間、取得値が80%を超えた際に障害とする
※取得結果を数えて割り出すような関数もZabbixにはある。
この設計に即した関数として「count」関数を利用する。
count関数:定義した評価期間の比較演算子の条件値のカウント数
条件式:
count(/HOST1/system.cpu.util[all,system,],3m, “gt”,”80″)=3
上記を説明すると「CPU」の取得した値が直近3分(3m)「80」を超えた回数が3回の場合障害。という条件式となる。

トリガーの作成
トリガーの作成は先に示した画面の各設定を記載していくことで作成する。
しかしトリガーの条件式については式の記載方法が間違っていたり、関数を調べるなど時間がかかってしまうがある程度直感的に操作できるようなUI設定になっている。
※条件式の欄にある「追加」を押下することで設定画面が表示される

上記UI上の「アイテム」と「関数」などに使用する設定を入力することである程度記載可能となる。
今回のcount関数を利用する場合は以下となる。
1.アイテムと関数を選択
2.各条件に合うパラメータを指定
最新のT⇒ 3m ※計算する期間
O⇒ gt ※取得値の条件
V⇒ 80 ※取得値の判定地
結果⇒ = 3 ※count関数で割り出された回数

今回はlast関数およびcount関数について例として記載したが以下のような関数も存在する。
nodata関数:アイテムの取得値が指定時間の間受信されていない
使用例: nodata(/HOST1/system.cpu.util[all,system,],3m)=1
上記だと「3分間、値が何も取得されていない場合、障害とする」という式になる。
基本的にZabbixはアイテム設定にある監視間隔に沿って、値を取得する。
そのため、主要な監視で利用することは多くないが以下のようなアイテムで利用する場合がある。
・監視間隔の設定がない、Zabbixトラッパーによる外部から送信される値に設定する。※定期的にデータが送られる監視などで利用する。
・定期的に障害となるアイテムの場合、監復旧条件式にそのアイテムの監視間隔より短くnodata関数を設定することで、障害を復旧させるために利用する。
※nodataは30秒より短く指定できないため、監視間隔は確認して利用する。

(←参考になった場合はハートマークを押して評価お願いします)