Zabbix 7.0のトリガー設定には、障害イベント生成モード（PROBLEM event generation mode）があります。
日本語UIでは「単一」「複数」、英語UIでは Single / Multiple と表示されます。
この設定は、トリガーが Problem と評価されたときに障害イベントを何件作るかを決めます。
しきい値監視とログ監視では選び方が変わるため、公式マニュアルの定義を基準に整理します。
単一は「初めて Problem になったときに1件」、複数は「Problem と評価されるたびに1件」です。
再通知の用途で複数を選ぶ必要はありません。
障害イベント生成モードとは何か
トリガーは式の評価結果に応じて状態を持ち、状態の変化などに応じてイベントを生成します。
公式マニュアルでは、トリガーが作るイベントを Problem（障害）と OK（復旧）の2種類として説明しています。
障害イベント生成モードは、Problem 側のイベントをいつ・何件作るかを制御するパラメータです。
トリガー設定画面（Data collection > Hosts > Triggers）の「PROBLEM event generation mode」で選択します。
PROBLEM event generation mode — Mode for generating problem events: Single – a single event is generated when a trigger goes into the ‘Problem’ state for the first time; Multiple – an event is generated upon every ‘Problem’ evaluation of the trigger.
引用：1 Configuring a trigger – Zabbix Documentation 7.0
目的はシンプルです。
「状態が続いている間は1件にまとめるか」「評価が TRUE になるたびに別イベントとして残すか」を用途に合わせて選ぶことです。
単一と複数の動作比較
公式の定義を、運用で見やすい比較表にまとめます。
用語は日本語UIと英語UIの両方を併記します。
| 項目 | 単一（Single） | 複数（Multiple） |
|---|---|---|
| 公式の定義 | トリガーが初めて Problem 状態になったときにイベントを1件生成 | トリガーが Problem と評価されるたびにイベントを生成 |
| Problem が続いている間 | 追加の障害イベントは作らない | 評価が TRUE になるたびに新規イベントを作る |
| 典型用途 | CPU・メモリ・ディスクなどしきい値監視 | ログ監視、トラップ処理など |
| イベント件数の増え方 | 障害1回につき基本1件 | 評価回数に応じて増える |
| 復旧まわり | 多くの場合「すべての障害」クローズで足りる | 個別クローズが必要ならタグ一致クローズを併用 |
トリガーイベント生成の説明でも、障害イベントの作成条件は次のとおりです。
OK状態のトリガーで式が TRUE になったとき、および複数生成が有効な場合は式が TRUE になるたび、です。
A problem event is created: when a trigger expression evaluates to TRUE if the trigger is in OK state; each time a trigger expression evaluates to TRUE if multiple problem event generation is enabled for the trigger.
引用：1 Trigger event generation – Zabbix Documentation 7.0
単一（Single）の動き
単一では、トリガーが OK から Problem へ入った最初のタイミングで障害イベントが1件できます。
その後も式が TRUE のままであれば、同じ障害状態が続くだけで、追加の障害イベントは生成されません。
たとえば CPU 使用率がしきい値を超えたまま数分続く場合、監視間隔ごとに値が取れてもイベントは増え続けません。
「障害が発生したこと」を1件として扱う、通常のしきい値監視向けの設定です。
複数（Multiple）の動き
複数では、トリガー式が Problem（TRUE）と評価されるたびに障害イベントが生成されます。
すでに Problem 状態であっても、評価のたびに別イベントとして積み上がります。
公式のトリガーレベルイベント相関の説明では、このモードはログ監視やトラップ処理などで通常使われる、と明記されています。
「同じ状態の継続」ではなく「同じトリガーでも発生のたびに記録したい」用途向きです。
しきい値監視での具体例（単一）
CPU 使用率や空きディスクなど、値がしきい値を超えている間ずっと TRUE になる監視では、単一が基本です。
例として、平均 CPU 負荷がしきい値を超えたときに障害とするトリガーを考えます。
last(/My host/system.cpu.load[percpu,avg1])>5障害イベント生成モードを単一にすると、負荷が5を超えて Problem になった時点でイベントが1件できます。
その後も負荷が高いままであっても、同じトリガーから障害イベントが増え続けることはありません。
値が5以下に戻り式が FALSE になると、OKイベント生成の設定に従って復旧イベントが作られ、関連する障害がクローズされます。
しきい値監視では、多くの場合 OKイベントの生成は「式」（Expression）、OKイベントがクローズは「すべての障害」（All problems）で足ります。
監視間隔を短くしても、単一なら「取得頻度」と「障害イベント件数」は切り分けられます。
間隔そのものの設計は、別記事のカスタムインターバル解説も参考になります。
コンテキストスイッチ数のようなメトリクス監視も、通常は単一想定のしきい値監視です。
イベント生成モード自体より、式としきい値の設計が先になります。
ログ監視での具体例（複数）
ログに「Stopping」などの行が出るたびに障害として残したい場合は、複数を使います。
公式のトリガーレベルイベント相関の例でも、Problem event generation mode を Multiple にするよう案内されています。
find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1複数にしておくと、該当行が検出されるたびに障害イベントが生成されます。
単一のままでは、最初の1件のあと同じトリガー状態が続いても、行ごとの発生をイベントとして積み上げられません。
復旧側では、たとえば「Starting」を含む行で復旧式を置く例が公式に示されています。
ただし「すべての障害」でクローズすると、別サービス由来の未解決障害までまとめて閉じる可能性があります。
find(/My host/log[/var/log/syslog],,"regexp","Starting")=1個別に閉じたいときは、次の組み合わせが公式の手順です。
- 障害イベント生成モード：複数（Multiple）
- OKイベントがクローズ：タグの値が一致する場合はすべての障害（All problems if tag values match）
- 一致用のタグ（Tag for matching）：相関に使うタグ名を指定
- トリガーのタグ：ログ行からサービス名などを抽出するタグ値を設定
この仕組みはトリガーレベルイベント相関と呼ばれます。
公式では「同じトリガーが作った複数の障害を、タグで識別して個別に閉じる」ための機能として説明されています。
Windows のイベントログ監視でも、行・イベント単位で扱いたいケースでは複数が候補になります。
取得側の実践手順は次の記事が近いです。
設定によるイベント生成の違い
障害イベント生成モードは単独ではなく、OKイベント生成と OKイベントがクローズとセットで理解すると迷いが減ります。
公式のトリガーイベント生成ページでは、OKイベントがどの障害を閉じるかも整理されています。
| 関連設定 | 主な選択肢 | 障害イベント生成モードとの関係 |
|---|---|---|
| OKイベントの生成 | 式 / 復旧式 / なし | 「なし」は、複数生成と組み合わせて発生通知だけ行う用途にも使えると公式に記載 |
| OKイベントがクローズ | すべての障害 / タグ一致の障害のみ | 複数で個別クローズしたいとき、タグ一致クローズを使う |
| 一致用のタグ | タグ名を指定 | タグ一致クローズ選択時は必須 |
None – an OK event is never generated. This can be used in conjunction with multiple problem event generation to simply send a notification when something happens.
引用：1 Trigger event generation – Zabbix Documentation 7.0
つまり「複数」は、ログやトラップのように発生単位でイベントを残すためのモードです。
「同じ障害を繰り返し通知したい」ための設定ではありません。
再通知・エスカレーションはアクション側の設定で行います。
障害イベント生成モードを複数にしても、それは新規 Problem イベントの増加であり、同一障害の再通知設定とは役割が異なります。
しきい値監視で単一のまま障害が続く場合、通知の繰り返しはアクションのエスカレーションで設計します。
ログ監視で複数を使う場合は、イベント件数とアクション条件が増える前提で、タグ設計とクローズ条件まで同時に決めます。
どちらを選ぶかの目安
迷ったときは、次の観点で選ぶと公式の使い分けに沿います。
- 状態が続いている間は1件でよいか → 単一
- 評価や検出のたびに別イベントとして残したいか → 複数
- ログ／トラップで個別復旧まで必要か → 複数＋タグ一致クローズ
- 再通知だけが目的か → モードは変えず、アクションのエスカレーションを確認
まとめ
Zabbix 7.0の障害イベント生成モードは、トリガーが Problem と評価されたときのイベント生成方針です。
単一は初めて Problem になったときに1件、複数は Problem 評価のたびに1件、というのが公式の定義です。
しきい値監視は単一、ログやトラップのように発生単位で残す監視は複数、が公式の典型用途です。
複数で個別クローズが必要なときは、OKイベントがクローズのタグ一致とトリガータグをセットで設計してください。
再通知は複数モードではなくアクションのエスカレーションで行います。
画面名と英語パラメータ名（PROBLEM event generation mode）を対応づけて覚えると、公式マニュアルとの突き合わせがしやすくなります。
コメント