「状態の追跡」の版間の差分

提供: Nagios 3翻訳プロジェクト Wiki
移動: 案内検索
(ページの作成: == 導入 Introduction == 状態"追跡(stalking)"はほとんどのユーザであまり使われないと思う機能です。もし有効にした場合、ホストやサー…)
 
 
71行目: 71行目:
 
     <td>-</td>
 
     <td>-</td>
 
     <td>-</td></tr></table>
 
     <td>-</td></tr></table>
 +
 +
 +
このチェックシークエンスが与えられると、このcatasropheに対して通常は2つのログエントリしか残しません。最初はサービスチェックx+2のWARNINGステートからOKステートに変わったということ。もう1はサービスチェックx+3のサービスがWARNINGステートからCRITICALステートに変わったときです。
 +
 +
なんらかの理由で、ログファイル内のこのcatasropheの完全なヒストリがほしいと思うかも知れません。もしかしたらあなたの上司に、状況がどうやって制御不能になったのか素早く説明する助けになるかもしれないし、居酒屋で酒をあおりながら笑うネタにしたいと思うかも知れないし…
 +
 +
さて、CRITICALステートのこのサービスの追跡を有効にした場合 x+2とx+3の追加イベントとして、x+4とx+5イベントがログに記録されているでしょう。なぜかというと、状態追跡が有効になっていると Nagiosは以前のチェックと比べて異なるかどうかを検証しているからです。もし2チェック間のステートが変化しないが、その出力は異なっている場合、新しいサービスチェックの方の結果はログに記録されます。
 +
 +
 +
追跡の似たような例としてウェブサーバを挙げてみます。 check_httpプラグインによる最初のチェックが404エラーのWARNINGステートで、後のチェックが特定のパターンが見つからないというエラーでのWARNINGステートの場合、この後の特定のパターンを知りたいと思うでしょう。もしこのサービスのWARNINGステートの状態追跡を有効にしていなかったら、最初のWARNINGステートイベント(404エラー)が記録されるだけで、(アーカイブされたログを見ても) 404エラーが引き起こした後のウェブページが返したパターンが見つからないというエラーに関してはお手上げになってしまいます。
 +
 +
 +
== 追跡を有効にした方が良い?  Should I Enable Stalking? ==
 +
まず初めに、アーカイブされたログを問題解決のために解析する必要があるか決めなくてはなりません。もしいくつかのサービスやホストでこの機能が必要だがすべてに必要というわけではないと判断するでしょう。さらに、それら状態のすべてではなく、いくつかのホストまたはサービスの状態のための追跡を可能にする必要が単に必要だと気づくでしょう。たとえば、あるサービスのWARNINGとCRITICALについて追跡したいが、OKとUNKNOWN状態は必要がないなどです。
 +
 +
ある特定のホストやサービスの状態追跡を有効にすることを決める事はそのホストやサービスをチェックするプラグインにも依存しています。もしある特定の状態をプラグインが常に同じテキストで返して来たら、それはその状態を追跡しても意味がありません。
 +
 +
== どうやって追跡を有効にする?  How Do I Enable Stalking? ==
 +
[http://nagios.sourceforge.net/docs/3_0/configobject.html ホストやサービス定義] においては、stalking_optionsディレクティブを使うことによって、ホストとサービスの状態追跡を有効に出来ます。
 +
 +
== 追跡はVolatileサービスとどう違いますか? How Does Stalking Differ From Volatile Services? ==
 +
[http://nagios.sourceforge.net/docs/3_0/volatileservices.html Volatileサービス]は似ています。しかし通知とイベントハンドラの実行をもたらします。追跡は純粋にログの目的のためのものです。
 +
 +
== 警告 Caveats ==
 +
追跡を有効にすることで潜在的な落とし穴があることを認識してください。追跡オプションを有効にすると、様々な[http://nagios.sourceforge.net/docs/3_0/cgis.html CGI]のすべての報告機能(ヒストグラムや警告サマリなど)に影響が出ます。なぜなら、状態追跡はログに追加の警告のエントリを書き込むのでレポートには警告数がふくれあがって表示されるます。
 +
 +
概して、私はあなたが考え無しに、ホストやサービスに状態追跡を有効にしないことをお勧めします。 まだ必要で実行したいのなら、この章を見てみて下さい。

2010年8月8日 (日) 19:30時点における最新版

導入 Introduction

状態"追跡(stalking)"はほとんどのユーザであまり使われないと思う機能です。もし有効にした場合、ホストやサービスチェックのステートが変化していなくても変化をログに出力できます。特定のホストやサービスの追跡が有効にすると、Nagiosは非常に注意して監視をし何が起こっているのかどんな変化もログに書き込みます。これは、後でログファイルを分析するのに役立ちます。

どのように動作する? How Does It Work?

通常の設定では、ホストやサービスチェックの結果はホストやサービスのステートが最後のチェックから変化したときのみログに書き込まれます。 There are a few exceptions to this, but for the most part, that's the rule. これにはいくつかの例外はありますが、大部分はそれはルールです。

特定のホストやサービスの1つもしくはそれ以上追跡を有効にすると、 Nagiosは以前のチェックと今回のチェックの結果が異なるとログに書き込みます。以下にあるサービスの連続した8つのチェック結果の例を挙げます:

Service Check #: Service State: Service Check Output: Logged Normally Logged With Stalking
x OK RAID array optimal - -
x+1 OK RAID array optimal - -
x+2 WARNING RAID array degraded (1 drive bad, 1 hot spare rebuilding) Checkmark.png Checkmark.png
x+3 CRITICAL RAID array degraded (2 drives bad, 1 host spare online, 1 hot spare rebuilding) Checkmark.png Checkmark.png
x+4 CRITICAL RAID array degraded (3 drives bad, 2 hot spares online) - Checkmark.png
x+5 CRITICAL RAID array failed - Checkmark.png
x+6 CRITICAL RAID array failed - -
x+7 CRITICAL RAID array failed - -


このチェックシークエンスが与えられると、このcatasropheに対して通常は2つのログエントリしか残しません。最初はサービスチェックx+2のWARNINGステートからOKステートに変わったということ。もう1はサービスチェックx+3のサービスがWARNINGステートからCRITICALステートに変わったときです。

なんらかの理由で、ログファイル内のこのcatasropheの完全なヒストリがほしいと思うかも知れません。もしかしたらあなたの上司に、状況がどうやって制御不能になったのか素早く説明する助けになるかもしれないし、居酒屋で酒をあおりながら笑うネタにしたいと思うかも知れないし…

さて、CRITICALステートのこのサービスの追跡を有効にした場合 x+2とx+3の追加イベントとして、x+4とx+5イベントがログに記録されているでしょう。なぜかというと、状態追跡が有効になっていると Nagiosは以前のチェックと比べて異なるかどうかを検証しているからです。もし2チェック間のステートが変化しないが、その出力は異なっている場合、新しいサービスチェックの方の結果はログに記録されます。


追跡の似たような例としてウェブサーバを挙げてみます。 check_httpプラグインによる最初のチェックが404エラーのWARNINGステートで、後のチェックが特定のパターンが見つからないというエラーでのWARNINGステートの場合、この後の特定のパターンを知りたいと思うでしょう。もしこのサービスのWARNINGステートの状態追跡を有効にしていなかったら、最初のWARNINGステートイベント(404エラー)が記録されるだけで、(アーカイブされたログを見ても) 404エラーが引き起こした後のウェブページが返したパターンが見つからないというエラーに関してはお手上げになってしまいます。


追跡を有効にした方が良い? Should I Enable Stalking?

まず初めに、アーカイブされたログを問題解決のために解析する必要があるか決めなくてはなりません。もしいくつかのサービスやホストでこの機能が必要だがすべてに必要というわけではないと判断するでしょう。さらに、それら状態のすべてではなく、いくつかのホストまたはサービスの状態のための追跡を可能にする必要が単に必要だと気づくでしょう。たとえば、あるサービスのWARNINGとCRITICALについて追跡したいが、OKとUNKNOWN状態は必要がないなどです。

ある特定のホストやサービスの状態追跡を有効にすることを決める事はそのホストやサービスをチェックするプラグインにも依存しています。もしある特定の状態をプラグインが常に同じテキストで返して来たら、それはその状態を追跡しても意味がありません。

どうやって追跡を有効にする? How Do I Enable Stalking?

ホストやサービス定義 においては、stalking_optionsディレクティブを使うことによって、ホストとサービスの状態追跡を有効に出来ます。

追跡はVolatileサービスとどう違いますか? How Does Stalking Differ From Volatile Services?

Volatileサービスは似ています。しかし通知とイベントハンドラの実行をもたらします。追跡は純粋にログの目的のためのものです。

警告 Caveats

追跡を有効にすることで潜在的な落とし穴があることを認識してください。追跡オプションを有効にすると、様々なCGIのすべての報告機能(ヒストグラムや警告サマリなど)に影響が出ます。なぜなら、状態追跡はログに追加の警告のエントリを書き込むのでレポートには警告数がふくれあがって表示されるます。

概して、私はあなたが考え無しに、ホストやサービスに状態追跡を有効にしないことをお勧めします。 まだ必要で実行したいのなら、この章を見てみて下さい。