9 メンテナンス

概要

メンテナンスは、事前に定義された期間中に障害を抑制するために使用されます。

Zabbix では、ホストおよびホストグループに対してメンテナンス期間を定義できます。

さらに、トリガータグを指定することで、単一のトリガー(またはトリガーのサブセット)のみに対してメンテナンスを定義することも可能です。 この場合、メンテナンスはそれらのトリガーに対してのみ有効になり、ホストまたはホストグループ内のその他すべてのトリガーはメンテナンス中にはなりません。

メンテナンスタイプは 2 種類あります: データ収集ありデータ収集なし です。

データ収集あり メンテナンス中は、トリガーは通常どおり処理され、必要に応じてイベントが作成されます。 ただし、アクション設定Pause operations for suppressed problems オプションがチェックされている場合、メンテナンス中のホスト/トリガーに対する障害のエスカレーションは一時停止されます。 この場合、通知の送信やリモートコマンドの実行を含む可能性のあるエスカレーションステップは、メンテナンス期間が終了するまで無視されます。 障害の復旧および更新操作はメンテナンス中でも抑制されず、抑制されるのはエスカレーションのみであることに注意してください。 障害がメンテナンス中に開始した場合、復旧通知は送信されません。

たとえば、障害の発生から 0 分後、30 分後、60 分後にエスカレーションステップが予定されており、実際の障害発生から 10 分後から 40 分後までの 30 分間のメンテナンスがある場合、ステップ 2 と 3 は 30 分遅れて、つまり 60 分後と 90 分後に実行されます(障害がまだ継続している場合)。 同様に、障害がメンテナンス中に発生した場合、エスカレーションはメンテナンス終了後に開始されます。

メンテナンス中も通常どおり(遅延なく)障害通知を受け取るには、アクション設定で Pause operations for suppressed problems オプションのチェックを外す必要があります。

少なくとも 1 つのホスト(トリガー式で使用されるホスト)がメンテナンスモードでない場合、Zabbix は障害通知を送信します。

メンテナンス中は Zabbix サーバーが稼働している必要があります。 メンテナンスは毎分再計算されるか、メンテナンス期間に変更がある場合は設定キャッシュの再読み込み直後に再計算されます。

タイマープロセスは、毎分 0 秒時点でホストの状態をメンテナンスへ/から変更する必要があるかどうかを確認します。 さらに、設定更新後に[メンテナンス期間]に変更があるかどうかに基づいて、開始/停止すべきメンテナンスがあるかをタイマープロセスが毎秒確認します。 したがって、メンテナンス期間の開始/停止の速度は、設定の更新間隔(デフォルトでは 10 秒)に依存します。 メンテナンス期間の変更には、Active since/Active till 設定は含まれないことに注意してください。 また、既存の有効なメンテナンス期間にホスト/ホストグループが追加された場合、その変更は次の分の開始時にのみタイマープロセスによって有効化されます。

ホストがメンテナンスに入ると、Zabbix サーバーのタイマープロセスは、抑制が必要かどうかを確認するために、すべての未解決の障害を読み取ることに注意してください。 未解決の障害が多数ある場合、これはパフォーマンスに影響を与える可能性があります。 また、Zabbix サーバーは起動時にも、たとえその時点でメンテナンスが設定されていなくても、すべての未解決の障害を読み取ります。

Zabbix サーバー(またはプロキシ)は、メンテナンスタイプに関係なく(データ収集なし メンテナンスを含む)、常にデータを収集することに注意してください。 データ収集なし が設定されている場合、そのデータは後でサーバーによって無視されます。

データ収集なし メンテナンスが終了すると、nodata() 関数を使用するトリガーは、監視対象期間内の次回チェックまでは発火しません。

ホストがメンテナンス中にログアイテムが追加され、その後メンテナンスが終了した場合、メンテナンス終了以降の新しいログファイルエントリのみが収集されます。

データ収集なし メンテナンス中のホストにタイムスタンプ付きの値が送信された場合(たとえば Zabbix sender を使用した場合)、その値は破棄されます。ただし、期限切れのメンテナンス期間に対してタイムスタンプ付きの値を送信することは可能であり、その場合は受け入れられます。

メンテナンス期間、ホスト、グループ、またはタグがユーザーによって変更された場合、その変更は設定キャッシュの同期後にのみ有効になります。

設定

メンテナンス期間を設定するには、以下の手順に従います。

  1. データ収集 > メンテナンス に移動します。
  2. メンテナンス期間の作成 をクリックします(または既存のメンテナンス期間名をクリックします)。
  3. フォームにメンテナンスパラメータを入力します。

必須入力フィールドには、赤いアスタリスクが付いています。

Parameter Description
Name メンテナンス期間の名前。
Maintenance type 2種類のメンテナンスタイプを設定できます。
データ収集あり - メンテナンス中もサーバーによってデータが収集され、トリガーが処理されます。
データ収集なし - データは引き続き収集される場合がありますが、メンテナンス中はデータベースに保存されず、トリガー(nodata() 関数を含む)は発生しません。
各タイプが可用性レポートに与える影響については、メンテナンス期間の影響を参照してください。
Active since メンテナンス期間の実行が有効になる日時。
注: この時刻を設定しただけではメンテナンス期間は有効になりません。メンテナンス期間は Periods で設定する必要があります(以下を参照)。
Active till メンテナンス期間の実行が有効でなくなる日時。
Periods このブロックでは、メンテナンスを実施する正確な曜日と時間を定義できます。 をクリックすると、柔軟にメンテナンススケジュールを定義できる Maintenance period フォームを含むポップアップウィンドウが開きます。詳細は メンテナンス期間 を参照してください。
Host groups メンテナンスを有効にするホストグループを選択します。指定したホストグループのすべてのホストに対してメンテナンスが有効になります。このフィールドはオートコンプリート対応のため、入力を開始すると利用可能なすべてのホストグループのドロップダウンが表示されます。
親ホストグループを指定すると、ネストされたすべてのホストグループも暗黙的に選択されます。そのため、ネストされたグループ内のホストでもメンテナンスが有効になります。
Hosts メンテナンスを有効にするホストを選択します。このフィールドはオートコンプリート対応のため、入力を開始すると利用可能なすべてのホストのドロップダウンが表示されます。
Tags メンテナンス中のホストで、一致するタグを持つ障害を抑制するためのタグを指定します。
複数の条件を設定できます。タグ名の一致では常に大文字と小文字が区別されます。

各条件では、次の2つの演算子を使用できます。
Contains - タグ値に入力した文字列が含まれる指定のタグ名を含めます(部分一致、大文字と小文字を区別)。
Equals - 指定したタグ名と値を含めます(大文字と小文字を区別)。

条件には2つの計算タイプがあります。
And/Or - すべての条件を満たす必要があります。同じタグ名を持つ条件は Or 条件でグループ化されます。
Or - いずれか1つの条件を満たせば十分です。

タグは、データ収集あり のメンテナンスタイプが選択されている場合にのみ指定できます。
Description メンテナンス期間の説明。
メンテナンス期間

メンテナンス期間ウィンドウは、定期的または一度限りのメンテナンスのスケジュールを設定するためのものです。 フォームは動的で、選択した期間タイプに応じて利用可能なフィールドが変化します。

期間タイプ 説明
一度限り 一度限りのメンテナンス期間を設定します:
日付 - メンテナンス期間の日付と時刻;
メンテナンス期間の長さ - メンテナンスが有効である期間。
毎日 毎日のメンテナンス期間を設定します:
毎日 - メンテナンスの頻度(1 - (デフォルト) 毎日、2 - 2日ごと、など);
時刻(時:分) - メンテナンスが開始される時刻;
メンテナンス期間の長さ - メンテナンスが有効である期間。

毎日パラメータが「1」より大きい場合、開始日は有効期間開始の時刻が属する日となります。例:
- 有効期間開始が「2021-01-01 12:00」、毎日が「2」、時刻(時:分)が「23:00」の場合、最初のメンテナンス期間は1月1日23:00に開始され、2回目のメンテナンス期間は1月3日23:00に開始されます;
- 有効期間開始が「2021-01-01 12:00」、毎日が「2」、時刻(時:分)が「01:00」の場合、最初のメンテナンス期間は1月3日01:00に開始され、2回目のメンテナンス期間は1月5日01:00に開始されます。
毎週 毎週のメンテナンス期間を設定します:
毎週 - メンテナンスの頻度(1 - (デフォルト) 毎週、2 - 2週間ごと、など);
曜日 - メンテナンスを実施する曜日;
時刻(時:分) - メンテナンスが開始される時刻;
メンテナンス期間の長さ - メンテナンスが有効である期間。

毎週パラメータが「1」より大きい場合、開始週は有効期間開始の時刻が属する週となります。例については、上記の毎日パラメータの説明を参照してください。
毎月 毎月のメンテナンス期間を設定します:
- 定期メンテナンスを実施するすべての月を選択;
日付: 月の日 - 毎月同じ日にメンテナンスを実施する場合はこのオプションを選択し、表示される月の日フィールドで必要な日を選択;
日付: 曜日 - 特定の曜日にのみメンテナンスを実施する場合はこのオプションを選択し、(ドロップダウンで)月の必要な週(第1週、第2週、第3週、第4週、または最終週)を選択し、メンテナンス日をチェックボックスで指定;
時刻(時:分) - メンテナンスが開始される時刻;
メンテナンス期間の長さ - メンテナンスが有効である期間。

メンテナンス期間を作成する際には、作成者のタイムゾーンが使用されます。 ただし、定期的なメンテナンス期間(日次週次月次)がスケジュールされている場合は、Zabbixサーバーのタイムゾーンが使用されます。 定期的なメンテナンス期間の予測可能な動作を保証するために、Zabbixのすべての部分で共通のタイムゾーンを使用する必要があります。

完了したら、追加を押してメンテナンス期間を期間ブロックに追加します。

サマータイム(DST)の変更は、メンテナンスの期間には影響しません。 例えば、通常01:00に開始し03:00に終了する2時間のメンテナンスが設定されているとします。

  • 1時間のメンテナンス後(02:00)にDSTの変更が発生し、現在時刻が02:00から03:00に変わった場合、メンテナンスはさらに1時間(04:00まで)続きます。
  • 2時間のメンテナンス後(03:00)にDSTの変更が発生し、現在時刻が03:00から02:00に変わった場合、2時間が経過しているためメンテナンスは終了します。
  • メンテナンス期間がDSTの変更によってスキップされる1時間の間に開始される場合、メンテナンスは開始されません。

メンテナンス期間が「1日」(Zabbixは日数を時間で計算するため、実際の期間は24時間)に設定され、00:00に開始し翌日の00:00に終了する場合:

  • 現在時刻が1時間進むと、メンテナンスは翌日の01:00に終了します。
  • 現在時刻が1時間戻ると、メンテナンスはその日の23:00に終了します。

表示

メンテナンス中のホストの表示

ホスト名の横にオレンジ色のレンチアイコン が表示されている場合、そのホストは以下の画面でメンテナンス中であることを示します:

  • ダッシュボード
  • 監視 > 障害
  • インベントリ > ホスト > ホストインベントリ詳細
  • データ収集 > ホスト(「ステータス」列を参照)

アイコンの上にマウスポインタを置くと、メンテナンスの詳細が表示されます。

さらに、監視 > マップ では、メンテナンス中のホストはオレンジ色の背景で表示されます。

抑制された障害の表示

通常、メンテナンス中のホストの障害は抑制され、フロントエンドには表示されません。 ただし、以下の場所で抑制された障害を表示オプションを選択することで、抑制された障害を表示するように設定することもできます。

  • ダッシュボード障害ホスト障害深刻度別障害トリガー概要ウィジェットの設定)
  • 監視 > 障害(フィルタ内)
  • 監視 > マップ(マップ設定内)
  • グローバル 通知 (ユーザープロファイル設定内)

抑制された障害が表示される場合、次のアイコンが表示されます: 。 アイコンにマウスを重ねると、詳細が表示されます。

メンテナンス中のキューの計算

ZabbixのWebインターフェース(Administration > Queue)に表示されるキューは、Zabbixサーバーによって計算されます。
これには、データ収集なし のメンテナンス中のアイテムは含まれず、値の取得が遅延している場合でも、これらのアイテムのキュー長は常にゼロです。
データ収集あり のメンテナンス中にある遅延アイテムは、引き続きキューにカウントされます。

Zabbixプロキシは、Zabbixサーバーとプロキシの間でメンテナンス設定が同期されないため、メンテナンス期間を認識しません。
Zabbixプロキシ上で計算される内部チェック(たとえば、zabbix[queue,,]zabbix[stats,,,queue,,])は、Zabbixサーバー上のメンテナンス状態に関係なく、遅延アイテムを報告します。

その結果、データ収集なし のメンテナンス中にある同じアイテムについて、ZabbixのWebインターフェースとZabbixプロキシ上の内部チェックとで、異なるキュー長が報告される場合があります。