5 エスカレーション
概要
エスカレーションを使用すると、通知の送信やリモートコマンドの実行のためのカスタムシナリオを作成できます。
実際には、次のことを意味します。
- ユーザーに新しい障害をすぐに通知できます。
- 障害が解決されるまで通知を繰り返すことができます。
- 通知の送信を遅延できます。
- 通知を別の「上位」ユーザーグループにエスカレーションできます。
- リモートコマンドをすぐに実行することも、障害が長時間解決されない場合に実行することもできます。
アクションは エスカレーションステップ に基づいてエスカレーションされます。各ステップには時間の継続時間があります。
デフォルトの継続時間と、個々のステップのカスタム継続時間の両方を定義できます。1つのエスカレーションステップの最小継続時間は60秒です。
通知の送信やコマンドの実行などのアクションは、どのステップからでも開始できます。ステップ1は即時アクション用です。アクションを遅延させたい場合は、後のステップに割り当てます。各ステップには、複数のアクションを定義できます。
エスカレーションステップの数に制限はありません。
エスカレーションは、オペレーションを設定する際に定義します。エスカレーションは障害オペレーションでのみサポートされ、復旧ではサポートされません。
エスカレーション動作のその他の側面
アクションに複数のエスカレーションステップが含まれている場合、さまざまな状況で何が起こるかを見てみましょう。
| 状況 | 動作 |
|---|---|
| 対象のホストが、最初の障害通知の送信後にメンテナンスに入る | アクション設定の Pause operations for suppressed problems 設定に応じて、残りのすべてのエスカレーションステップは、メンテナンス期間による遅延ありで実行されるか、遅延なしで実行されます。メンテナンス期間によって操作がキャンセルされることはありません。 |
| Time period アクション条件で定義された期間が、最初の通知の送信後に終了する | 残りのすべてのエスカレーションステップが実行されます。Time period 条件は操作を停止できません。これは、操作ではなく、アクションが開始されるかどうかのタイミングにのみ影響します。 |
| 障害がメンテナンス中に発生し、メンテナンス終了後も継続する（解決されない） | アクション設定の Pause operations for suppressed problems 設定に応じて、すべてのエスカレーションステップは、メンテナンス終了時点から、または即時に実行されます。 |
| 障害が no-data メンテナンス中に発生し、メンテナンス終了後も継続する（解決されない） | すべてのエスカレーションステップが実行される前に、トリガーが発火するのを待つ必要があります。 |
| 異なるエスカレーションが短い間隔で続き、重なり合う | 各新しいエスカレーションの実行は前のエスカレーションを上書きしますが、少なくとも1つのエスカレーションステップは常に前のエスカレーションで実行されます。この動作は、トリガーの EVERY problem evaluation によって作成されるイベントに対するアクションで重要です。 |
| 進行中のエスカレーション中（メッセージ送信中など）、任意の種類のイベントに基づいて: - アクションが無効化される トリガーイベントに基づいて: - トリガーが無効化される - ホストまたはアイテムが無効化される トリガーに関する内部イベントに基づいて: - トリガーが無効化される アイテム/low-level discovery ルールに関する内部イベントに基づいて: - アイテムが無効化される - ホストが無効化される |
進行中のメッセージは送信され、その後、エスカレーション上でさらに1通のメッセージが送信されます。後続のメッセージでは、メッセージ本文の先頭にキャンセル文言（NOTE: Escalation canceled）が入り、理由が示されます（例: NOTE: Escalation canceled: action '<Action name>' disabled）。これにより、受信者はエスカレーションがキャンセルされ、これ以上ステップが実行されないことを把握できます。このメッセージは、通知を以前に受け取ったすべての人に送信されます。キャンセル理由はサーバーログファイルにも記録されます（Debug Level 3=Warning から）。 なお、Escalation canceled メッセージは、操作が完了していても、復旧操作が設定されており、まだ実行されていない場合にも送信されます。 |
| 進行中のエスカレーション中（メッセージ送信中など）にアクションが削除される | それ以上メッセージは送信されません。情報はサーバーログファイルに記録されます（Debug Level 3=Warning から）。例: escalation canceled: action id:334 deleted |
エスカレーション例
例1
30分ごとに1回、繰り返し通知を送信する（合計5回） 設定で、「MySQL Administrators」グループに送信します。設定方法は次のとおりです。
- 実行内容タブで、デフォルトの実行ステップの間隔 を「30m」（30分）に設定します。
- エスカレーションの ステップ を「1」から「5」に設定します。
- メッセージの送信先として「MySQL Administrators」グループを選択します。
通知は、障害の発生後 0:00、0:30、1:00、1:30、2:00 の時点で送信されます （もちろん、障害がそれより前に復旧した場合を除きます）。
障害が復旧し、復旧メッセージが設定されている場合、そのメッセージは このエスカレーションシナリオ内で少なくとも1回障害メッセージを受信したユーザーに送信されます。
アクティブなエスカレーションを生成したトリガーが 無効化された場合、Zabbix はすでに通知を受信しているすべてのユーザーに対して その旨を知らせる情報メッセージを送信します。
例2
長時間継続している障害について、遅延通知を送信します。設定方法:
- 実行内容タブで、デフォルトの実行ステップの期間 を「10h」（10時間）に設定します。
- エスカレーションの ステップ を「2」から「2」に設定します。
通知は、エスカレーションシナリオのステップ2、つまり障害の発生から10時間後にのみ送信されます。
メッセージ本文は、「この障害は10時間以上継続しています」のようにカスタマイズできます。
例3
問題を上司にエスカレーションします。
上記の最初の例では、MySQL管理者に対してメッセージを定期的に送信するよう設定しました。この場合、問題がデータベースマネージャーにエスカレーションされるまでに、管理者は4通のメッセージを受け取ります。マネージャーがメッセージを受け取るのは、問題がまだ承認されておらず、つまり誰もまだ対応していないと考えられる場合のみであることに注意してください。
操作2の詳細:
カスタマイズしたメッセージで {ESC.HISTORY} マクロが使用されている点に注意してください。このマクロには、このエスカレーションで以前に実行されたすべてのステップに関する情報、たとえば送信された通知や実行されたコマンドが含まれます。
例 4
より複雑なシナリオ。 MySQL 管理者への複数のメッセージとマネージャーへのエスカレーションの後、Zabbix は MySQL データベースの再起動を試みます。 障害が 2:30 時間存在し、確認されていない場合に発生します。
それでも障害が解決しない場合は、さらに 30 分後に Zabbix がすべてのゲスト ユーザーにメッセージを送信します。
これで障害が解決しない場合は、さらに 1 時間後に、Zabbix は IPMI コマンドを使用して MySQL データベース (2 番目のリモート コマンド) でサーバーを再起動します。
例5
複数のオペレーションが重複するステップ範囲とカスタム間隔を持つエスカレーションの例です。デフォルトのオペレーションステップの期間は30分です。
通知は次のように送信されます。
- 問題の発生開始から0:00、0:30、1:00、1:30後に、MySQL管理者へ送信されます。
- 問題の発生開始から2:00および2:10後に、データベースマネージャーへ送信されます（後続のオペレーションで定義された10分というより短いカスタムステップ期間が、ここで設定された1時間というより長いステップ期間を上書きします。これは、ステップが重複する場合のステップの期間について、オペレーションの詳細で説明されているとおりです）。
- 問題の発生開始から2:00、2:10、2:20後に、Zabbix管理者へ送信されます（10分のカスタムステップ期間が適用されます）。
- 問題の発生開始から4:00後に、guestユーザーへ送信されます（ステップ8から11の間では、デフォルトの30分のステップ期間が有効になります）。