Table of Contents
5 エスカレーション
概要
エスカレーションを使用すると、通知を送信したり、リモート コマンドを実行したりするためのカスタム シナリオを作成できます。
具体的には、次のようなことです。
- ユーザーは新しい問題をすぐに通知できます
- 問題が解決するまで通知を繰り返すことができます
- 通知の送信を遅らせることができます
- 通知は、別の"より権限が上の"ユーザー グループにエスカレートできます
- リモートコマンドは、障害発生時すぐに、または障害が長期間解決されない場合に実行できます
アクションは、エスカレーション ステップに基づいてエスカレートされます。 各ステップには期間があります。
個々のステップのデフォルト期間とカスタム期間の両方を定義できます。 1 つのエスカレーション ステップの最小所要時間は 60 秒です。
通知の送信やコマンドの実行などのアクションは、どのステップからでも開始できます。 ステップ 1 は即時のアクションです。 アクションを遅らせたい場合は、後のステップに割り当てることができます。 ステップごとに、いくつかのアクションを定義できます。
エスカレーションのステップ数に制限はありません。
エスカレーションは、オペレーションの設定時に定義されます。 エスカレーションは障害のある操作に対してのみサポートされており、復旧はサポートされていません。
エスカレーション動作その他の例
アクションに複数のエスカレーション手順が含まれている場合、さまざまな状況で何が起こるかを考えてみましょう。
| 状況 | 動作 |
|---|---|
| 障害が発生したホストは、最初の障害通知が送信された後にメンテナンスに入る場合 | アクション設定 の メンテナンス中の場合に実行を保留 の設定に応じて、残りのエスカレーション手順はすべて、メンテナンス期間中遅延するか、遅延なしで即時実行されます。 メンテナンス期間によって操作がキャンセルされることはありません。 |
| * 期間アクション条件で定義された期間は、最初の通知が送信された後、即時終了する場合* | 残りのすべてのエスカレーション手順が実行されます。 期間条件では操作を停止できません。 操作ではなく、アクションが開始されるかされないかに関して効果があります。 |
| メンテナンス中に不具合が発生し、メンテナンス終了後も継続する（解消されない）場合 | アクション 設定 の メンテナンス中の場合に実行を保留 の設定に応じて、すべてのエスカレーション手順は、メンテナンスが終了した瞬間、または即時実行されます。 |
| データなしのメンテナンス中に障害が発生し、メンテナンス終了後も継続する (解決されない)場合 | すべてのエスカレーション手順が実行される前に、トリガーが起動するのを待つ必要があります。 |
| さまざまなエスカレーションが連続して続き、重なる場合 | 新しい各エスカレーションの実行は前のエスカレーションに取って代わりますが、前のエスカレーションで常に実行されるエスカレーション手順が少なくとも 1 つ必要です。 この動作は、トリガーのすべての障害評価で作成されたイベントに対するアクションに関連しています。 |
| 進行中のエスカレーション中 (メッセージの送信など)、あらゆるタイプのイベントに基づいて: - アクションは無効 トリガー イベントに基づいて: - トリガーは無効 - ホストまたはアイテムは無効 トリガーに関する内部イベントに基づいて: - トリガーは無効 アイテム/ローレベルディスカバリルールに関する内部イベントに基づいて: - アイテムは無効 - ホストは無効 |
進行中のメッセージが送信され、エスカレーションに関するメッセージがもう 1 つ送信されます。 フォローアップ メッセージには、メッセージ本文の先頭にキャンセル テキスト (注: エスカレーションがキャンセルされました) があり、理由が示されます (例: 注: エスカレーションがキャンセルされました: アクション '<アクション名>' が無効化されました)。 このように、エスカレーションがキャンセルされ、それ以上の手順が実行されないことが受信者に通知されます。 このメッセージは、以前に通知を受け取ったすべての人に送信されます。 キャンセルの理由は、サーバーのログ ファイルにも記録されます (デバッグ レベル 3=Warning以上)。 エスカレーションがキャンセルされました メッセージも オペレーションが終了したが、リカバリ オペレーションが設定されていて、まだ実行されていない場合に送信されます。 |
| エスカレーションの進行中 (メッセージの送信など) にアクションが削除される | これ以上メッセージは送信されません。 情報はサーバー ログ ファイルに記録されます (デバッグ レベル 3=警告 以上) |
エスカレーション例
例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
1つのステップに複数のオペレーションが割り当てられ、カスタム間隔が使用されているエスカレーション。デフォルトのオペレーションステップの期間は30分です。
通知は以下のように送信されます:
- 問題発生後、0:00、0:30、1:00、1:30にMySQL管理者へ。
- 2:00と2:10にデータベースマネージャーへ。 (3:00には送信されません。ステップ5と6が次のオペレーションと重複しているため、次のオペレーションで10分の短いカスタムステップ期間が、ここで設定しようとした1時間の長いステップ期間を上書きします)。
- 問題発生後、2:00、2:10、2:20にZabbix管理者へ(10分のカスタムステップ期間が有効)。
- 問題発生後、4:00にゲストユーザーへ(ステップ8と11の間でデフォルトの30分のステップ期間が再び適用される)。