「分散監視」の版間の差分

提供: Nagios 3翻訳プロジェクト Wiki
移動: 案内、 検索
 
(同じ利用者による、間の1版が非表示)
23行目: 23行目:
  
 
パッシブチェック結果のリモートホストへの服従を容易にするために、私はnsca addonに書きました。 addonは2つの断片から成ります。 1番目は、リモートホストから動かされて、サービスチェック結果を別のサーバに送るのに使用されるクライアントプログラム(_nscaを送る)です。 2番目の断片は、スタンドアロンデーモンかinetdの下を動いて、クライアントプログラムから接続を聞こうとするnscaデーモン(nsca)です。クライアントからサービスチェック情報を受け取ると、デーモンはPROCESS_SVC_CHECK_RESULTを挿入するのによるNagios(セントラルサーバーの)へのチェック情報がチェック結果に伴う外部のコマンドファイルの中に命令するsumbitがそうするでしょう。外部のコマンドのための次の時間Nagiosチェック、それは受け身のサービスが、分散サーバから送られたチェック情報であることがわかって、それを処理するでしょう。
 
パッシブチェック結果のリモートホストへの服従を容易にするために、私はnsca addonに書きました。 addonは2つの断片から成ります。 1番目は、リモートホストから動かされて、サービスチェック結果を別のサーバに送るのに使用されるクライアントプログラム(_nscaを送る)です。 2番目の断片は、スタンドアロンデーモンかinetdの下を動いて、クライアントプログラムから接続を聞こうとするnscaデーモン(nsca)です。クライアントからサービスチェック情報を受け取ると、デーモンはPROCESS_SVC_CHECK_RESULTを挿入するのによるNagios(セントラルサーバーの)へのチェック情報がチェック結果に伴う外部のコマンドファイルの中に命令するsumbitがそうするでしょう。外部のコマンドのための次の時間Nagiosチェック、それは受け身のサービスが、分散サーバから送られたチェック情報であることがわかって、それを処理するでしょう。
 +
 +
 +
== 分散サーバ構成  Distributed Server Configuration  ==
 +
非常に、Nagiosは分散サーバでいったいどうやって構成されますか? 基本的に、それはただ要点インストールです。あなたは、ウェブインタフェースをインストールするか、またはサーバから通知を出させる必要はありません、これがセントラルサーバーによってすべて扱われるとときです。
 +
 +
主要な構成変更:
 +
*直接分散サーバによってモニターされているそれらのサービスとホストだけが、オブジェクト構成ファイルで定義されます。
 +
*分散サーバが持っている、それ、通知指示が0に設定する_を有効にしてください。 これは、どんな通知もサーバによって出されるのを防ぐでしょう。
 +
*分散サーバは、サービスに取りつくために構成されます。
 +
*分散サーバはコマンドが定義したocspを持っています(以下で説明されるように)。
 +
 +
 +
すべてを集まって、適切に働かせるように、私たちは、分散サーバに、すべてのサービスの結果がNagiosにチェックすると報告して欲しいと思います。私たちは、サービスの状態の変化を報告するのにイベントハンドラを使用できましたが、それはただそれを切りません。可能にされて、分散サーバにすべてのサービスチェック結果を報告させるように報告しなければならない、_主な構成ファイルにおけるサービスオプションに_ に取りついてください、そして、あらゆるサービスチェックの後に実行されるべきocsp_コマンドを提供してください。私たちがサービスがセントラルサーバー、作成使用にチェックするすべての結果を送るocspコマンドを使用するつもりである、_nscaクライアントと nscaデーモン(上で説明されるように)を送って、tranmissionを扱ってください。
 +
 +
これを達成するために、あなたは、このようなocspコマンドを定義する必要があるでしょう:
 +
 +
ocsp_command=submit_check_result
 +
 +
定義を命令する、_コマンドがこのように見えるチェック_結果を提出してください:
 +
 +
<pre>define command{
 +
 +
command_name submit_check_result
 +
 +
command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
 +
 +
}
 +
 +
</pre>
 +
 +
このようなチェック結果シェルスクリプトを作成してください。(主要なサーバをセントラルサーバーのIPアドレスに取り替えてください):
 +
 +
<pre>
 +
#!/bin/sh
 +
 +
 +
 +
# Arguments:
 +
 +
#  $1 = host_name (Short name of host that the service is
 +
 +
#      associated with)
 +
 +
#  $2 = svc_description (Description of the service)
 +
 +
#  $3 = state_string (A string representing the status of
 +
 +
#      the given service - "OK", "WARNING", "CRITICAL"
 +
 +
#      or "UNKNOWN")
 +
 +
#  $4 = plugin_output (A text string that should be used
 +
 +
#      as the plugin output for the service checks)
 +
 +
#
 +
 +
 +
 +
# Convert the state string to the corresponding return code
 +
 +
return_code=-1
 +
 +
 +
 +
case "$3" in
 +
 +
        OK)
 +
 +
                return_code=0
 +
 +
                ;;
 +
 +
        WARNING)
 +
 +
                return_code=1
 +
 +
                ;;
 +
 +
        CRITICAL)
 +
 +
                return_code=2
 +
 +
                ;;
 +
 +
        UNKNOWN)
 +
 +
                return_code=-1
 +
 +
                ;;
 +
 +
esac
 +
 +
 +
 +
# pipe the service check info into the send_nsca program, which
 +
 +
# in turn transmits the data to the nsca daemon on the central
 +
 +
# monitoring server
 +
 +
 +
 +
/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/local/nagios/bin/send_nsca -H central_server -c /usr/local/nagios/etc/send_nsca.cfg
 +
 +
</pre>
 +
 +
上のスクリプトが、/usr/local/nagios/bin/と/usr/local/nagios/etc/ directoriesにそれぞれ位置する構成ファイル(nsca.cfgを送る)をnscaプログラムとそれに送ってください。
 +
 +
それはそれです! 私たちはsucessfullyに分散監視サーバとして機能するようにNagiosを実行するリモートホストを構成しました。まさに分散サーバとそれがどうサービスチェック結果をNagiosに送るかで起こることを調べましょう(以下に概説されたステップは、上の参照図による数に対応しています):
 +
 +
#分散サーバが、サービスチェックを実行し終えた後に、それは、あなたがocsp_コマンド変数で定義したコマンドを実行します。私たちの例では、これは/usr/local/nagios/libexec/eventhandlers/submit_チェック_結果スクリプトです。 それに注意してください、定義、_4つの情報がスクリプトに通過されたチェック_結果コマンドを提出してください: サービスが関連しているホストの名前、サービス記述、サービスチェックからの復帰コード、およびサービスからのプラグイン出力はチェックします。
 +
#スクリプトがサービスチェック情報(ホスト名、記述、復帰コード、および出力)を運ぶチェック結果を提出してください、_nscaクライアントプログラムを送ってください。
 +
#中央のモニターサーバのnscaデーモンへのサービスチェック情報をnscaプログラムが伝える_に送ってください。
 +
# セントラルサーバーのnscaデーモンは、Nagiosでサービスチェック情報を取って、後のピックアップのための外部のコマンドファイルにそれを書きます。
 +
#セントラルサーバーのNagiosプロセスは、外部のコマンドファイルを読んで、分散監視サーバから発した受け身のサービスチェック情報を処理します。
 +
 +
== セントラルサーバー構成  Central Server Configuration ==
 +
私たちは、分散監視サーバがそのようにどう構成されているべきであるかがセントラルサーバーに変わろうというのを見ました。 すべての徹底的な目的のために、通常、あなたがスタンドアロンサーバを構成するように、中央は構成されます。 それは以下のセットアップです:
 +
*セントラルサーバーで、ウェブインタフェースをインストールします
 +
*セントラルサーバーが持っている、それ、通知指示が1に設定する_を有効にしてください。 これは通知を可能にする。
 +
*セントラルサーバーでデフォルトチェックを無効にする。
 +
*セントラルサーバーで、外部のコマンドチェックを可能にします
 +
*セントラルサーバーで、パッシブのサービスチェックを可能にします
 +
 +
あなたがセントラルサーバーを構成するとき、覚えておく必要がある他の3つの非常に重要なことがあります:
 +
*セントラルサーバーには、すべての分散サーバによってモニターされているすべてのサービスのためのサービス定義がなければなりません。 定義されたサービスに対応していないと、Nagiosは受け身のチェック結果を無視するでしょう。
 +
*結果が分配されたホストによって提供されるサービスを処理するのにセントラルサーバーを使用しているだけであるなら、設定のそばですべての活発なサービスがプログラム全体のベースのチェックであると単に無効にすることができる、_0への指示のサービス_チェックを実行してください。活発にいくつかのサービスをモニターするセントラルサーバーを使用するのがそれ自身である、(分散サーバを使わずに)分散サーバによってモニターされるのが0に設定されるべきであるサービスのために_チェックがゆだねるdefintionsのアクティブな_を有効にしてください。これは、Nagiosが活発にそれらのサービスをチェックするのを防ぐでしょう。
 +
 +
 +
すべてのサービスが広さのプログラムベースのチェックであると無効にするか、または無効にするのが、重要である、_チェックが分散サーバによってモニターされる各サービスのための定義でゆだねるアクティブな_を有効にしてください。これは、現役チェックが決して通常の状況下で実行されないのを確実にするでしょう。サービスがしかし、彼らの正常なチェック間隔(3分、5分など)で、時期変更させ続ける、実際に実行されないでしょう。この時期変更輪はずっとただNagiosを続けるでしょう。稼働しています。 私は、なぜこれで少しするかを説明するつもりです…
 +
 +
== パッシブチェックに関する問題 Problems With Passive Checks ==
 +
すべての徹底的な目的のために、私たちは、セントラルサーバーがモニターのための唯一パッシブチェックに依存していると言うことができます。モニターのためのパッシブチェックに完全に依存することに関する主な障害は、Nagiosがモニターしているデータを提供する他の何かを当てにしなければならないという事実です。 パッシブチェック結果を送るリモートホストが、落ちるか、または手が届かなくなると、どうなるでしょうか? Nagiosがホストの上で活発にサービスをチェックしていないと、それは、問題がどのようにあるのを知るでしょうか?
 +
 +
 +
== フレッシュネスチェック　Freshness Checking ==
 +
Nagiosはサービスチェックの結果について検査して、「新しさ」をする特徴をサポートします。ここで、より多くの情報新しさの照合を見つけることができます。この特徴はリモートホストが受け身のサービスチェックを中央のモニターサーバに送るのを止めるかもしれないところに状況に対する何らかの保護を与えます。「新しさ」の照合の目的は、必要性が起こるなら、サービスチェックが分散サーバによって定期的に受け身に提供されるか、またはセントラルサーバーによって活発に実行されているのを保証することです。分散サーバによって提供されたサービスチェック結果が、「聞き古したである」得られるなら、主要な監視ホストから活発なサービスのチェックを強制するためにNagiosを構成できます。
 +
 +
それで、あなたはどのようにこれをしますか? あなたが以下の分散サーバで…をモニターしているサービスを構成するために必要とする中央のモニターサーバに関して
 +
*サービス定義におけるチェック_新しさオプションは1に設定されるべきです。 これは、サービスのためにチェックしながら、「新しさ」を可能にします。
 +
*サービス定義における新しさ_敷居オプションはサービス(分散サーバで、提供される)のための結果がどのように「新鮮であるべきであるか」を反映する値(秒の)に設定されるべきです。
 +
*サービス定義におけるチェック_コマンドオプションは中央のモニターサーバからサービスを活発にチェックするのに使用できる有効なコマンドを反映するべきです。
 +
 +
Nagiosは新しさの照合を可能にするすべてのサービスのために定期的に結果の「新しさ」をチェックします。それぞれのサービス定義における新しさ_敷居オプションは、各サービスのための結果がどのように「新鮮であるべきであるか」を決定するのに使用されます。例えば、あなたがあなたのサービスの1つのためにこの値を300に設定すると、それらが5分(300秒)より古いなら、Nagiosは、サービス結果が「聞き古したである」考えるでしょう。あなたが新しさ_敷居オプションに値を指定しないと、正常な_チェック_間隔か再試行_のどちらかが_間隔オプション(中でサービスが状態のどんなタイプであるかに頼って)をチェックするのを見ることによって、Nagiosは自動的に「新しさ」敷居について計算するでしょう。サービス結果が「聞き古したである」わかっていると、Nagiosはサービス定義におけるチェック_コマンドオプションで指定されたサービスチェック命令を走らせるでしょう、その結果、活発に、サービスをチェックします。
 +
 +
あなたは忘れずに中央のモニターサーバからサービスの状態を活発にチェックするのに使用できるサービス定義におけるチェック_コマンドオプションを指定しなければならなくなってください。通常の状況下で、このチェックコマンドは決して実行されません(活発なチェックがプログラム全体のベースか特定のサービスのために無効にされたので)。新しさの照合が可能にされるとき、活発なチェックがプログラム全体の、または、サービス特有のベースで無効にされても、Nagiosは活発にサービスの状態をチェックするこのコマンドを実行するでしょう。
 +
 +
主要な監視ホストからサービスを活発にチェックするコマンドを定義できないなら(大きな悩みの種であろうとしている回転であれば)、あなたはオプションがきわどい状態を返すダミーのスクリプトを実行するように設定したチェック_コマンドで単にすべてのサービスを定義するかもしれません。ここに、例があります… あなたが'サービスは聞き古したです'と呼ばれるコマンドを定義して、あなたのサービスのチェック_コマンドオプションにそのコマンド名を使用すると仮定しましょう。 ここに、定義が似ているものがあります…
 +
 +
<pre>
 +
define command{
 +
 +
command_name service-is-stale
 +
 +
command_line /usr/local/nagios/libexec/check_dummy 2 "CRITICAL: Service results are stale"
 +
 +
}
 +
</pre>
 +
Nagiosが検出するとき、サービスが古くさくなることであることが命令する走行であり、チェック_ダミープラグインがサービス結果が聞き古したである、実行されていてサービスであることは、きわどい状態に入るでしょう。これでおそらく通知を出すでしょうから、あなたは、問題があるのを知るでしょう。
 +
 +
 +
== ホストチェックの実行 Performing Host Checks ==
 +
ここに、あなたは、分散サーバからサービスチェック結果をpassivlyに得る方法を知っています。これは、セントラルサーバーがそれ自身のところで活発にサービスをチェックしていないことを意味します。 しかし、ホストチェックはどうですか? あなたが、まだそれらをする必要があるので、どのようにですか?
 +
 +
パッシブのホストチェックは利用可能です([[パッシブチェック|ここで読んでください]])、したがって、あなたはあなたの分散監視セットアップでそれらを使用できるでしょうが、それらはいくつかの問題が欠点です。最も大きい問題は、それらが処理されるとき、Nagiosが受け身のホスト検査問題州(DOWNとUNREACHABLE)を翻訳しないということです。これは、あなたのモニターサーバに異なった親/子供ホスト構造があると(望んでいて、モニターサーバがあなたであれば別の場所にあります)、中央のモニターサーバにはホスト州の不正確な視点があることを意味します。
 +
 +
分散監視セットアップで受け身のホストチェックをセントラルサーバーに送りたいなら、確実にしてください:
 +
*セントラルサーバーで、受け身のホストチェックを可能にします(必要です)。
 +
*分散サーバは、ホストに取りつくために構成されます。
 +
*分散サーバはコマンドが定義したochpを持っています。
 +
 +
ochpコマンド(処理ホストチェック結果に使用される)はocspコマンドへのsimiliar方法で働いています(ドキュメンテーションが上であることを見てください)。(それは、整理業務チェック結果に使用されます)。受け身のホストチェック結果が確実に最新になるようにするために、あなたはホスト(サービスのために上で説明されることへのsimiliar)がないかどうかチェックする新しさを可能にしたくなるでしょう。

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

導入 Introduction

ネットワーク・サービスとリソースの分散監視をサポートするためにNagiosを構成できます。 私は簡潔にどうこれを達成できるかを外計画しようとするでしょう…

目標 Goals

私が説明するつもりである分散監視環境における目標は、「中央」のサーバから1つ以上の「分配された」サーバにサービスチェックを実行するオーバーヘッド (CPU用法など)を積み下ろすことです。最も小さく、媒体に、大きさで分けられた店はそのような環境をセットアップする本当の必要性を持たないでしょう。しかしながら、あなたが、Nagiosを使用することで数百か何千人ものホスト(そして、何度かそんなに多くのサービス)をモニターし始めたいと、これはかなり重要になります。


参照図 Reference Diagram

以下のダイヤグラムは、分散監視がNagiosと共にどう働くかに関する概念をあなたに与えるのを助けるはずです。 私は私がことについて説明するので、ダイヤグラムで見せられた項目を示すでしょう…

サムネイルの作成エラー: サムネイルを保存先に保存できません


セントラルサーバー対分散サーバ Central Server vs. Distributed Servers

Nagiosと共に分散監視環境をセットアップするとき、中央の、そして、分配されたサーバが構成される方法の違いがあります。私は、両方のタイプのサーバを構成して、説明するために、行われる変更に作用することが、総合的にどのようにモニターを持っているかをあなたに示すつもりです。 手初めに、異なったタイプのサーバの…目的を説明させます。

分散サーバの機能は活発に働くのがあなたがホストの「クラスタ」のために定義するすべてのサービスをチェックするということです。私は緩く「クラスタ」という用語を使用します--それはあなたのネットワークで基本的にただホストの任意のグループを意味します。あなたのネットワークレイアウトによって、あなたが1つの物理的な位置に数個のclutersを持つことができますか、または各クラスタはWAN、それ自身のファイアウォールなどによって切り離されるかもしれません。ホスト(しかしながら、あなたはそれを定義します)の各クラスタのためにそれについてよろしくと伝言する重要なもの、クラスタでホストの上でNagios を実行して、サービスをモニターする1つの分散サーバがあります。 通常、分散サーバはNagiosの要点インストールです。それで、あなたが、それにそうして欲しくないなら、インタフェースがインストールするか、通知を出すか、イベントハンドラスクリプトを実行するか、または何でもするウェブはサービスチェックを実行する必要はありません。 分散サーバを構成することの、より詳細な情報は後で来ます…


セントラルサーバーの目的は、1つ以上の分散サーバからサービスチェック結果の単に聞こうとすることです。活発なチェックをサービスはセントラルサーバーからoccassionallyに活発にチェックされますが、恐ろしい事情で実行されるだけであり、したがって、させます。セントラルサーバーが当分受け身のチェックを受け入れるだけであるとただ言ってください。セントラルサーバーが1つ以上の分散サーバから受け身のサービスチェック結果を得ているので、それはすべてのモニターしている論理のための焦点として機能します(すなわち、それに通知を出して、イベントハンドラスクリプトを実行して、ホスト州を決定して、ウェブインタフェースをインストールさせますなど)。

分配されたモニターからサービスチェック情報を得ます。 Obtaining Service Check Information From Distributed Monitors

私たちがサービスを送る方法を知るのに必要な構成の詳細までジャンプしに行く前に、間違いなく、分散サーバからセントラルサーバーまで結果をチェックしてください。既にNagiosが走っている同じホストからNagiosに受け身のチェック結果を提出する方法について議論しましたが(パッシブチェックに関するドキュメンテーションで説明されるように)、私は他のホストから受け身のチェック結果をどう提出するかの少しの情報も教えていません。

パッシブチェック結果のリモートホストへの服従を容易にするために、私はnsca addonに書きました。 addonは2つの断片から成ります。 1番目は、リモートホストから動かされて、サービスチェック結果を別のサーバに送るのに使用されるクライアントプログラム(_nscaを送る)です。 2番目の断片は、スタンドアロンデーモンかinetdの下を動いて、クライアントプログラムから接続を聞こうとするnscaデーモン(nsca)です。クライアントからサービスチェック情報を受け取ると、デーモンはPROCESS_SVC_CHECK_RESULTを挿入するのによるNagios(セントラルサーバーの)へのチェック情報がチェック結果に伴う外部のコマンドファイルの中に命令するsumbitがそうするでしょう。外部のコマンドのための次の時間Nagiosチェック、それは受け身のサービスが、分散サーバから送られたチェック情報であることがわかって、それを処理するでしょう。


分散サーバ構成 Distributed Server Configuration

非常に、Nagiosは分散サーバでいったいどうやって構成されますか? 基本的に、それはただ要点インストールです。あなたは、ウェブインタフェースをインストールするか、またはサーバから通知を出させる必要はありません、これがセントラルサーバーによってすべて扱われるとときです。

主要な構成変更:

  • 直接分散サーバによってモニターされているそれらのサービスとホストだけが、オブジェクト構成ファイルで定義されます。
  • 分散サーバが持っている、それ、通知指示が0に設定する_を有効にしてください。 これは、どんな通知もサーバによって出されるのを防ぐでしょう。
  • 分散サーバは、サービスに取りつくために構成されます。
  • 分散サーバはコマンドが定義したocspを持っています(以下で説明されるように)。


すべてを集まって、適切に働かせるように、私たちは、分散サーバに、すべてのサービスの結果がNagiosにチェックすると報告して欲しいと思います。私たちは、サービスの状態の変化を報告するのにイベントハンドラを使用できましたが、それはただそれを切りません。可能にされて、分散サーバにすべてのサービスチェック結果を報告させるように報告しなければならない、_主な構成ファイルにおけるサービスオプションに_ に取りついてください、そして、あらゆるサービスチェックの後に実行されるべきocsp_コマンドを提供してください。私たちがサービスがセントラルサーバー、作成使用にチェックするすべての結果を送るocspコマンドを使用するつもりである、_nscaクライアントと nscaデーモン(上で説明されるように)を送って、tranmissionを扱ってください。

これを達成するために、あなたは、このようなocspコマンドを定義する必要があるでしょう:

ocsp_command=submit_check_result

定義を命令する、_コマンドがこのように見えるチェック_結果を提出してください: 

define command{

	command_name	submit_check_result

	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'

	}

このようなチェック結果シェルスクリプトを作成してください。(主要なサーバをセントラルサーバーのIPアドレスに取り替えてください): 

	#!/bin/sh



	# Arguments:

	#  $1 = host_name (Short name of host that the service is

	#       associated with)

	#  $2 = svc_description (Description of the service)

	#  $3 = state_string (A string representing the status of

	#       the given service - "OK", "WARNING", "CRITICAL"

	#       or "UNKNOWN")

	#  $4 = plugin_output (A text string that should be used

	#       as the plugin output for the service checks)

	#



	# Convert the state string to the corresponding return code

	return_code=-1



	case "$3" in

    	    OK)

        	        return_code=0

            	    ;;

	        WARNING)

    	            return_code=1

        	        ;;

	        CRITICAL)

    	            return_code=2

        	        ;;

	        UNKNOWN)

    	            return_code=-1

        	        ;;

	esac



	# pipe the service check info into the send_nsca program, which

	# in turn transmits the data to the nsca daemon on the central

	# monitoring server



	/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/local/nagios/bin/send_nsca -H central_server -c /usr/local/nagios/etc/send_nsca.cfg

上のスクリプトが、/usr/local/nagios/bin/と/usr/local/nagios/etc/ directoriesにそれぞれ位置する構成ファイル(nsca.cfgを送る)をnscaプログラムとそれに送ってください。

それはそれです! 私たちはsucessfullyに分散監視サーバとして機能するようにNagiosを実行するリモートホストを構成しました。まさに分散サーバとそれがどうサービスチェック結果をNagiosに送るかで起こることを調べましょう(以下に概説されたステップは、上の参照図による数に対応しています):

  1. 分散サーバが、サービスチェックを実行し終えた後に、それは、あなたがocsp_コマンド変数で定義したコマンドを実行します。私たちの例では、これは/usr/local/nagios/libexec/eventhandlers/submit_チェック_結果スクリプトです。 それに注意してください、定義、_4つの情報がスクリプトに通過されたチェック_結果コマンドを提出してください: サービスが関連しているホストの名前、サービス記述、サービスチェックからの復帰コード、およびサービスからのプラグイン出力はチェックします。
  2. スクリプトがサービスチェック情報(ホスト名、記述、復帰コード、および出力)を運ぶチェック結果を提出してください、_nscaクライアントプログラムを送ってください。
  3. 中央のモニターサーバのnscaデーモンへのサービスチェック情報をnscaプログラムが伝える_に送ってください。
  4. セントラルサーバーのnscaデーモンは、Nagiosでサービスチェック情報を取って、後のピックアップのための外部のコマンドファイルにそれを書きます。
  5. セントラルサーバーのNagiosプロセスは、外部のコマンドファイルを読んで、分散監視サーバから発した受け身のサービスチェック情報を処理します。

セントラルサーバー構成 Central Server Configuration

私たちは、分散監視サーバがそのようにどう構成されているべきであるかがセントラルサーバーに変わろうというのを見ました。 すべての徹底的な目的のために、通常、あなたがスタンドアロンサーバを構成するように、中央は構成されます。 それは以下のセットアップです:

  • セントラルサーバーで、ウェブインタフェースをインストールします
  • セントラルサーバーが持っている、それ、通知指示が1に設定する_を有効にしてください。 これは通知を可能にする。
  • セントラルサーバーでデフォルトチェックを無効にする。
  • セントラルサーバーで、外部のコマンドチェックを可能にします
  • セントラルサーバーで、パッシブのサービスチェックを可能にします

あなたがセントラルサーバーを構成するとき、覚えておく必要がある他の3つの非常に重要なことがあります:

  • セントラルサーバーには、すべての分散サーバによってモニターされているすべてのサービスのためのサービス定義がなければなりません。 定義されたサービスに対応していないと、Nagiosは受け身のチェック結果を無視するでしょう。
  • 結果が分配されたホストによって提供されるサービスを処理するのにセントラルサーバーを使用しているだけであるなら、設定のそばですべての活発なサービスがプログラム全体のベースのチェックであると単に無効にすることができる、_0への指示のサービス_チェックを実行してください。活発にいくつかのサービスをモニターするセントラルサーバーを使用するのがそれ自身である、(分散サーバを使わずに)分散サーバによってモニターされるのが0に設定されるべきであるサービスのために_チェックがゆだねるdefintionsのアクティブな_を有効にしてください。これは、Nagiosが活発にそれらのサービスをチェックするのを防ぐでしょう。


すべてのサービスが広さのプログラムベースのチェックであると無効にするか、または無効にするのが、重要である、_チェックが分散サーバによってモニターされる各サービスのための定義でゆだねるアクティブな_を有効にしてください。これは、現役チェックが決して通常の状況下で実行されないのを確実にするでしょう。サービスがしかし、彼らの正常なチェック間隔(3分、5分など)で、時期変更させ続ける、実際に実行されないでしょう。この時期変更輪はずっとただNagiosを続けるでしょう。稼働しています。 私は、なぜこれで少しするかを説明するつもりです…

パッシブチェックに関する問題 Problems With Passive Checks

すべての徹底的な目的のために、私たちは、セントラルサーバーがモニターのための唯一パッシブチェックに依存していると言うことができます。モニターのためのパッシブチェックに完全に依存することに関する主な障害は、Nagiosがモニターしているデータを提供する他の何かを当てにしなければならないという事実です。 パッシブチェック結果を送るリモートホストが、落ちるか、または手が届かなくなると、どうなるでしょうか? Nagiosがホストの上で活発にサービスをチェックしていないと、それは、問題がどのようにあるのを知るでしょうか?


フレッシュネスチェック　Freshness Checking

Nagiosはサービスチェックの結果について検査して、「新しさ」をする特徴をサポートします。ここで、より多くの情報新しさの照合を見つけることができます。この特徴はリモートホストが受け身のサービスチェックを中央のモニターサーバに送るのを止めるかもしれないところに状況に対する何らかの保護を与えます。「新しさ」の照合の目的は、必要性が起こるなら、サービスチェックが分散サーバによって定期的に受け身に提供されるか、またはセントラルサーバーによって活発に実行されているのを保証することです。分散サーバによって提供されたサービスチェック結果が、「聞き古したである」得られるなら、主要な監視ホストから活発なサービスのチェックを強制するためにNagiosを構成できます。

それで、あなたはどのようにこれをしますか? あなたが以下の分散サーバで…をモニターしているサービスを構成するために必要とする中央のモニターサーバに関して

  • サービス定義におけるチェック_新しさオプションは1に設定されるべきです。 これは、サービスのためにチェックしながら、「新しさ」を可能にします。
  • サービス定義における新しさ_敷居オプションはサービス(分散サーバで、提供される)のための結果がどのように「新鮮であるべきであるか」を反映する値(秒の)に設定されるべきです。
  • サービス定義におけるチェック_コマンドオプションは中央のモニターサーバからサービスを活発にチェックするのに使用できる有効なコマンドを反映するべきです。

Nagiosは新しさの照合を可能にするすべてのサービスのために定期的に結果の「新しさ」をチェックします。それぞれのサービス定義における新しさ_敷居オプションは、各サービスのための結果がどのように「新鮮であるべきであるか」を決定するのに使用されます。例えば、あなたがあなたのサービスの1つのためにこの値を300に設定すると、それらが5分(300秒)より古いなら、Nagiosは、サービス結果が「聞き古したである」考えるでしょう。あなたが新しさ_敷居オプションに値を指定しないと、正常な_チェック_間隔か再試行_のどちらかが_間隔オプション(中でサービスが状態のどんなタイプであるかに頼って)をチェックするのを見ることによって、Nagiosは自動的に「新しさ」敷居について計算するでしょう。サービス結果が「聞き古したである」わかっていると、Nagiosはサービス定義におけるチェック_コマンドオプションで指定されたサービスチェック命令を走らせるでしょう、その結果、活発に、サービスをチェックします。

あなたは忘れずに中央のモニターサーバからサービスの状態を活発にチェックするのに使用できるサービス定義におけるチェック_コマンドオプションを指定しなければならなくなってください。通常の状況下で、このチェックコマンドは決して実行されません(活発なチェックがプログラム全体のベースか特定のサービスのために無効にされたので)。新しさの照合が可能にされるとき、活発なチェックがプログラム全体の、または、サービス特有のベースで無効にされても、Nagiosは活発にサービスの状態をチェックするこのコマンドを実行するでしょう。

主要な監視ホストからサービスを活発にチェックするコマンドを定義できないなら(大きな悩みの種であろうとしている回転であれば)、あなたはオプションがきわどい状態を返すダミーのスクリプトを実行するように設定したチェック_コマンドで単にすべてのサービスを定義するかもしれません。ここに、例があります… あなたが'サービスは聞き古したです'と呼ばれるコマンドを定義して、あなたのサービスのチェック_コマンドオプションにそのコマンド名を使用すると仮定しましょう。 ここに、定義が似ているものがあります… 

define command{

	command_name	service-is-stale

	command_line	/usr/local/nagios/libexec/check_dummy 2 "CRITICAL: Service results are stale"

	}

Nagiosが検出するとき、サービスが古くさくなることであることが命令する走行であり、チェック_ダミープラグインがサービス結果が聞き古したである、実行されていてサービスであることは、きわどい状態に入るでしょう。これでおそらく通知を出すでしょうから、あなたは、問題があるのを知るでしょう。


ホストチェックの実行 Performing Host Checks

ここに、あなたは、分散サーバからサービスチェック結果をpassivlyに得る方法を知っています。これは、セントラルサーバーがそれ自身のところで活発にサービスをチェックしていないことを意味します。 しかし、ホストチェックはどうですか? あなたが、まだそれらをする必要があるので、どのようにですか?

パッシブのホストチェックは利用可能です(ここで読んでください)、したがって、あなたはあなたの分散監視セットアップでそれらを使用できるでしょうが、それらはいくつかの問題が欠点です。最も大きい問題は、それらが処理されるとき、Nagiosが受け身のホスト検査問題州(DOWNとUNREACHABLE)を翻訳しないということです。これは、あなたのモニターサーバに異なった親/子供ホスト構造があると(望んでいて、モニターサーバがあなたであれば別の場所にあります)、中央のモニターサーバにはホスト州の不正確な視点があることを意味します。

分散監視セットアップで受け身のホストチェックをセントラルサーバーに送りたいなら、確実にしてください:

  • セントラルサーバーで、受け身のホストチェックを可能にします(必要です)。
  • 分散サーバは、ホストに取りつくために構成されます。
  • 分散サーバはコマンドが定義したochpを持っています。

ochpコマンド(処理ホストチェック結果に使用される)はocspコマンドへのsimiliar方法で働いています(ドキュメンテーションが上であることを見てください)。(それは、整理業務チェック結果に使用されます)。受け身のホストチェック結果が確実に最新になるようにするために、あなたはホスト(サービスのために上で説明されることへのsimiliar)がないかどうかチェックする新しさを可能にしたくなるでしょう。

「https://nagios.x-trans.jp/nagios/index.php?title=分散監視&oldid=178」から取得