5 エスカレーション
概要
エスカレーションを使用すると、通知の送信やリモートコマンドの実行のための カスタムシナリオを作成できます。
実際には、これは次のことを意味します。
- ユーザーは新しい障害について即座に通知を受けることができます。
- 障害が解決されるまで通知を繰り返すことができます。
- 通知の送信を遅らせることができます。
- 通知を別の「より上位の」ユーザーグループにエスカレーションできます。
- リモートコマンドは、即座に実行することも、障害が長時間解決されない場合に実行することもできます。
アクションは、エスカレーションステップ に基づいてエスカレーションされます。各ステップには 継続時間があります。
デフォルトの継続時間と、個々のステップのカスタム継続時間の両方を 定義できます。1つのエスカレーションステップの最小継続時間は60秒です。
通知の送信やコマンドの実行などのアクションは、任意のステップから開始できます。 ステップ1は即時アクション用です。アクションを遅らせたい場合は、 後のステップに割り当てることができます。各ステップに対して、 複数のアクションを定義できます。
エスカレーションステップの数に制限はありません。
エスカレーションは、実行内容の設定時に定義します。エスカレーションは 障害時の実行内容でのみサポートされ、復旧時にはサポートされません。
エスカレーション動作のその他の側面
アクションに複数のエスカレーションステップが含まれている場合、状況によって何が起こるかを見てみましょう。
| 状況 | 動作 |
|---|---|
| 最初の障害通知が送信された後、対象のホストがメンテナンス状態に入る | アクション設定の 抑止された障害に対する実行を一時停止 設定に応じて、残りのすべてのエスカレーションステップは、メンテナンス期間による遅延あり、または遅延なしで実行されます。メンテナンス期間によって実行が取り消されることはありません。 |
| 期間 アクション条件で定義された時間帯が、最初の通知送信後に終了する | 残りのすべてのエスカレーションステップが実行されます。期間 条件で実行を停止することはできません。これは、アクションを開始するかどうかにのみ影響し、実行自体には影響しません。 |
| 障害がメンテナンス中に発生し、メンテナンス終了後も継続する（未解決のままである） | アクション設定の 抑止された障害に対する実行を一時停止 設定に応じて、すべてのエスカレーションステップは、メンテナンス終了時点から、または即座に実行されます。 |
| 障害がデータなしメンテナンス中に発生し、メンテナンス終了後も継続する（未解決のままである） | すべてのエスカレーションステップが実行される前に、トリガーが発生するのを待つ必要があります。 |
| 異なるエスカレーションが短い間隔で連続して発生し、重複する | 新しい各エスカレーションの実行は前のエスカレーションに優先しますが、前のエスカレーションでも少なくとも1つのエスカレーションステップは必ず実行されます。この動作は、トリガーの問題評価が行われるたびに作成されるイベントに対するアクションで関係します。 |
| 進行中のエスカレーション中（メッセージ送信中など）に、任意の種類のイベントに基づいて: - アクションが無効化される トリガーイベントに基づいて: - トリガーが無効化される - ホストまたはアイテムが無効化される トリガーに関する内部イベントに基づいて: - トリガーが無効化される アイテム/ローレベルディスカバリルールに関する内部イベントに基づいて: - アイテムが無効化される - ホストが無効化される |
進行中のメッセージは送信され、その後エスカレーションでさらに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分ごとに繰り返し通知を送信する（合計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分です。
通知は以下のように送信されます。
- 問題発生後、MySQL管理者には0:00、0:30、1:00、1:30に通知されます。
- データベースマネージャーには2:00と2:10に通知されます（後続のオペレーションで定義された短いカスタムステップ継続時間10分が、ここで設定された長いステップ継続時間1時間を上書きします。これは、オペレーションの詳細のステップ継続時間で、ステップが重複する場合の動作として説明されています）。
- Zabbix管理者には、問題発生後2:00、2:10、2:20に通知されます（カスタムステップ継続時間10分が適用されます）。
- ゲストユーザーには、問題発生後4:00に通知されます（ステップ8と11の間はデフォルトのステップ継続時間30分が有効になります）。