Sidebar

Zabbix Summit 2022
View presentations

3 エスカレーション

概要

エスカレーションを使用すると、通知の送信またはリモートコマンドの実行のためにカスタムシナリオを作成します。

具体的には、以下のことができます。

  • 新しい障害について迅速に通知を受けることができます。
  • 通知は、障害が解決するまで繰り返すことができます。
  • 通知の送信は遅らせることができます。
  • 通知は、別の「上位の」ユーザーグループにエスカレーションできます。
  • リモートコマンドを、迅速に、または長期間障害が解決されない場合に実行できます。
  • リカバリメッセージを送信できます。

アクションは、エスカレーションステップに従って、エスカレーションされます。各ステップには期間があります。

各ステップのデフォルトの期間とカスタム期間を定義できます。エスカレーションステップの1つの最小期間は、60秒です。

どのステップからも、通知の送信やコマンドの実行などのアクションを開始できます。ステップ1は、迅速なアクションです。アクションを遅らせる場合は、後続のステップに割り当てることができます。各ステップに対して、複数のアクションを定義できます。

エスカレーションのステップの数に制限はありません。

実行するアクションの設定時にエスカレーションを定義します。

エスカレーション動作のさまざまな側面

アクションが複数のエスカレーションステップを含む場合に、異なる状況で、何が起こるかを考慮します。

状況 動
最初の障害通知の送信後、障害が発生している可能性のあるホストがメンテナンスされます。 残りのすべてのエスカレーションステップが実行されます。メンテナンスは、操作には影響 与えませんが、アクションを開始する/開始しないかには、影響をします。
期間アクションの実行条件で定義された期間は、最初の通知を送信後、終了します。 残りのすべてのエスカレーションステップが実行されます。期間条件は、操作には 響を与えませんが、アクションを開始する/開始しないかには、影響をします。
メンテナンス中に障害が発生し、メンテナンス終了後も継続します(障害が解決されません)。 すべてのエスカレーションステップは、メンテナンスが終了した時点から開始されます。
データなしメンテナンス中に障害が発生し、メンテナンス終了後も継続します(障害が解決されません)。 すべてのエスカレーションステップを実行する前に、トリガーが起動するのを待ちます。
異なるエスカレーションが僅差で実行され、重複します。 新規のエスカレーションは前のエスカレーションに取っ 代わって実行されますが、前のエスカレーションにおいて、最初のエスカレーションステップは常に実行されます。この動作は、トリガーのすべての障害評価で作成されるイベント時のアクションに関係します。
メッセージの送信中など、エスカレーションが進行中の場合に、アクションが無効化されます。 進行中のメッセージが送信され、エスカレーションにおいて、もう一つのメッセージが送信さ ます。フォローアップメッセージは、メッセージ本文の初めに、以下のテキストが記載されているものとします。注:エスカレーションがキャンセルされました。アクション<アクション名>無効化。このように、送信先は、エスカレーションがキャンセルされ、ステップが実行されないという通知を受けます。

エスカレーションの例

例 1

「MySQL管理者」グループに対して、30分に1回(合計で5回)、通知を繰り返して送信します。設定するには:

  • [アクションの実行内容]タブで、[デフォルトのアクション実行ステップの間隔]を「1800」秒(30分)に設定します。
  • エスカレーションステップを、「1」から「5」に設定します。
  • メッセージの送信先として「MySQL管理者」グループを選択します。

通知は、(障害が解決するまで)障害発生後、0時間、30分、1時間、1時間30分、2時間後に送信されます。

障害が解決され、リカバリメッセージが設定されている場合、このエスカレーションシナリオにおいて、通知は少なくとも1つの障害メッセージを受信した管理者に対して送信されます。

アクティブエスカレーションを生成したトリガーが無効化された場合、すでに障害通知を受信したすべてのユーザーに無効化の通知を送信します。

例 2

長く続いている障害についての遅延通知を送信します。設定するには:

  • [アクションの実行内容]タブで、[デフォルトのアクション実行ステップの間隔]を「36000」秒(10時間)に設定します。
  • エスカレーションステップを、「2」から「2」に設定します。

通知は、エスカレーションのステップ2または障害発生時から10時間後に送信されます。

メッセージ本文を「障害は10時間以上発生しています。」などにカスタマイズできます。

例 3

障害を上司にエスカレーションします。

最初の例では、MySQL管理者に定期的にメッセージを送信するように設定されていました。この場合、データベースマネージャーに障害がエスカレーションされる前に、管理者は4件のメッセージを受信します。障害が対応されておらず、誰も障害に取り組んでいない場合にのみ、データベースマネージャーはメッセージを受信します。

メッセージ内における{ESC.HISTORY}マクロの使用に注意してください。マクロは、このエスカレーションで以前に実行した、すべてのステップに関する情報を含みます。例えば、送信した通知や実行したコマンドについての情報です。

例 4

より複雑なシナリオです。複数のメッセージがMySQL管理者に送信され、データベースマネージャーへのエスカレーションが行われた場合、ZabbixはMySQLデータベースの再起動を試行します。再起動は、障害が2時間30分継続し、その障害が対応されていない場合に実行されます。

障害が依然として存在する場合、30分後に、Zabbixはすべてのゲストユーザーにメッセージを送信します。

メッセージの送信によっても障害が解決されない場合、ZabbixはIPMIコマンドを使用して、MySQLデータベースを再起動します(二番目のリモートコマンド)。

例 5

1つのステップに複数のアクションが定義されており、カスタムの間隔が使用されるエスカレーションです。[デフォルトのアクション実行ステップの間隔]は30分です。

通知は以下のように送信されます。

  • 障害発生後、0時間、30分、1時間、1時間30分後に、通知がMySQL管理者に送信されます。
  • 障害発生後、2時間と2時間10分後に、データベースマネージャーに通知が送信されます(3時間後には通知は送信されません。ステップ5とステップ6が重複しているため、次の操作の、600秒の短いカスタムステップ間隔が、ここで設定しようとしている3600秒の長いカスタムステップ間隔を上書きします)。
  • 障害発生後、2時間、2時間10分、2時間20分後に、Zabbix管理者に通知が送信されます(600秒のカスタムステップ間隔が動作します)。
  • 障害発生後、4時間後に、ゲストユーザーに通知が送信されます(ステップ8とステップ11の間に戻るため、デフォルトのアクション実行ステップの間隔は30分です)。

本ページは2014/08/05時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は、英語版のZabbix2.2マニュアルを参照してください。