状態のタイプ

提供: Nagios 3翻訳プロジェクト Wiki
2010年6月14日 (月) 06:23時点におけるWikiadmin (トーク | 投稿記録)による版

(差分) ←前の版 | 最新版 (差分) | 次の版→ (差分)
移動: 案内検索

導入 Introduction

監視しているサービスやホストの現在の現在の状態は2つ要素によって決まります:

  • サービスやホストの状態 (すなわち OK, WARNING, UP, DOWN, など)
  • サービスやホストがいる状態のタイ タイプ


Nagiosには2つの状態のタイプ - ソフト状態とハード状態 があります。それらの状態のタイプはいつイベントハンドラ が実行されるのかや、いつ通知が最初に送られるのかを決めるのに用いられるモニタリングロジックの重要な部分です。

このドキュメントではどうやって起きるのか、起きた時に何が発生するのかのソフトとハード状態の違いを記載します。


サービスとホストチェックの再試行 Service and Host Check Retries

誤報の一時的な問題を防止するために、Nagiosは"本当の"問題とみなす前にサービスやホストが何回(再)チェックするのかを決めることを許容します。これは、ホストやサービス定義のmax_check_attemptsオプションで制御されます。本当に問題が存在したということを決定するために、どのようにしてホストやサービスが(再)チェックされるかについて理解することが、状態のタイプがどのように動作するか理解するのに重要です。


ソフト状態 Soft States

ソフト状態は以下の状況で起こります。。。

  • サービスやホストチェックの結果が非OKまたは非UP状態で、サービスチェックがサービスやホスト定義の max_check_attemptsで指定された(再)チェックの回数にまだなっていなかったとき。これはソフトエラーと呼ばれます。
  • サービスやホストがソフトエラーから復旧するとき。これはソフトリカバリとみなします。

ホストやサービスがソフト状態へ変化するとき以下のことが起きます:

  • ソフト状態が記録されます。
  • イベントハンドラがソフト状態と扱われて実行されます。

メインコンフィグファイルの中のlog_service_retrieslog_host_retriesオプションを有効にした場合、ソフト状態は記録だけされます。

ソフト状態の間に本当に起こる唯一重要なことは、イベントハンドラの実行です。それがHARD状態に変わる前に試したり、積極的に問題を解決したりしたいならイベントハンドラを使用することは特に役に立ちます。 $HOSTSTATETYPE$$SERVICESTATETYPE$ マクロはイベントハンドラが実行されるとき"ソフト"の値を保持します、そして、そして、イベントハンドラスクリプトが矯正動作を起こさなければいけない時を知ることを許可します。イベントハンドラについての詳細な情報は、ここにあります。


ハード状態 Hard States

ホストやサービスがハード状態へ変化するとき以下のことが起きます:

  • サービスやホストチェックの結果が非OKまたは非UP状態で、サービスチェックがサービスやホスト定義の max_check_attemptsで指定された(再)チェックの回数になったとき。これはハードエラー状態です。
  • ホストやサービスが、あるハードエラーから別のハードエラー状態へ移行する時 (たとえば、CRITICALからWARNING)。
  • サービスチェックの結果が非OK状態で、その対応するホストがDOWNかUNREACHABLE状態であるとき。
  • ホストやサービスがハードエラー状態から復旧した時。これはハードリカバリとみなします。
  • パッシブホストチェックが受信された時。 passive_host_checks_are_soft オプションが有効でない限り、パッシブホストチェックはHARDとみなされます。


ホストまたはサービスがHARD状態に変化したとき以下のことが起こります:

  • ハード状態が記録されます。
  • イベントハンドラがHARD状態と扱われて実行されます。
  • コンタクトはホストやサービスの問題もしくは復旧の通知がされます。

$HOSTSTATETYPE$$SERVICESTATETYPE$ マクロは、イベントハンドラが実行される時、"HARD"の値を保持します、そしてイベントハンドラスクリプトが矯正動作を起こさなければいけない時を知ることを許可します。イベントハンドラについての詳細な情報は、 ここにあります。


例 Example

状態の変化が起きる時、イベントハンドラと通知が送られる時に状態のタイプがどのように決められるのかの例はここにあります。下の表は時間ごとの連続したチェックを表しています。サービスはmax_check_attemptsの値を3に保持しています。

時間チェック #状態状態のタイプ 状態の変化補足
01OKHARDNoサービスの初期状態
11CRITICALSOFTYes非OK状態の最初の検知。イベントハンドラが実行。
22WARNINGSOFTYesサービスは非OK状態が続きます。 イベントハンドラが実行。
33CRITICALHARDYes

チェックの最大回数に達したので、サービスはHARD状態に移行します。 イベントハンドラが実行され、障害通知が送られます。 これが起こった直後に、チェック #が1にリセットされます。

41WARNINGHARDYes

サービスはHARD WARNING状態に変わります。イベントハンドラが実行され、障害の通知が送られます。

51WARNINGHARDNo

サービスはHARD障害状態で安定します。サービスの通知間隔に依存して、他の通知が送られるかもしれません。

61OKHARDYes

サービスはハードリカバリになります。イベントハンドラが実行され、リカバリ通知が送られます。

71OKHARDNo

サービスは依然OKのままです。

81UNKNOWNSOFTYes

サービスがソフト非OK状態に変わったことを検知します。イベントハンドラが実行。

92OKSOFTYes

サービスはSOFTリカバリになります。これは"本当の"問題ではなかったので、イベントハンドラは実行されますが 通知は送られません。これが起こった直後に、状態のタイプはHARDにセットされ、チェック #は1にリセットされます。

101OKHARDNo

サービスはOK状態で安定します。