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