Nagios 3翻訳プロジェクト Wiki - 新しいページ [ja]

Nagios設定ファイル

2011-07-25T17:44:42Z

Wikiadmin:

== 7/22 第1回 Nagiosセミナー資料 ==
7/22に福岡にて第1回Nagiosセミナーを実施致しました。セミナー資料やNagiosの設定ファイルをアップ致しましたので
ご参考頂ければと存じます。

[[Media:20110722fukuoka_seminar.zip|2011年7月第1回Nagiosセミナー資料]]

第1回X-TRANS & M5 ジョイントセミナー「オープンソースを利用してWindows サーバを監視してみよう！」

2011-07-04T06:15:22Z

Wikiadmin: ページの作成: Nagios 3翻訳プロジェクトを運営しております株式会社エクストランス（以下、エクストランス）は、 メディアファイブ株式会社と…

Nagios 3翻訳プロジェクトを運営しております株式会社エクストランス（以下、エクストランス）は、 
メディアファイブ株式会社とNagiosをテーマとしたジョイントセミナーを行うことになりました。 
 
第1回のテーマは、「オープンソースを利用してWindows サーバを監視してみよう！」です。 
こちらはハンズオンセミナーとなり、Windowsサーバのリソース（CPUやメモリ）監視を 
Nagiosでどのように行うか、その一例を紹介し、実際に体験していただけます。 
 
特に、サーバ運用監視に携わられているシステム管理者や、 
Nagiosの導入や簡単な監視設定を行うことが出来る中級者の皆様にも有用なハンズオンセミナーです。 
この機会に、是非ご出席ください。 
 
また、第2回はテーマを変更し、来月東京で行う予定です。 
決まりましたら改めてお知らせいたします。お楽しみに！ 
 
■セミナータイトル 
第1回X-TRANS & M5ジョイントセミナー 
「オープンソースを利用してWindowsサーバを監視してみよう！」 
 
■セミナー開催日時 
平成23年7月22日（金）　18：30～20：00（18:00から受付開始） 
 
■場所 
メディアファイブ株式会社　福岡本社内薬院教室 
福岡県福岡市中央区薬院一丁目1番1号　薬院ビジネスガーデン6階 
 
■セミナー参加申込み方法 
1)メールによるお申込み 
宛先 
　　[mailto:bakoon@media5.co.jp bakoon@media5.co.jp] 
件名 
　　第1回X-TRANS & M5ジョイントセミナー申込み 
本文 
　　次の情報を明記ください。 
　　氏名（漢字）： 
　　氏名（ふりがな）： 
　　会社名： 
　　電話番号： 
　　参加人数： 
 
2) 電話によるお申込み 
電話番号：0120-262-242 
Bakoon!!（バクーン）サービス担当へご連絡いただき、 
「第1回X-TRANS & M5ジョイントセミナー」参加の旨をお伝えください。

■お問い合わせ先
メディアファイブ株式会社　Bakoon!!（バクーン）サービス担当 
TEL　　　：0120-262-242 
E-mail　：[mailto:bakoon@media5.co.jp bakoon@media5.co.jp] 
URL　　　：[http://www.m5it.jp/bakoon/ http://www.m5it.jp/bakoon/]

グラフを使ったパフォーマンスデータ

2010-09-06T12:17:38Z

Wikiadmin: /* グラフの例 Example Graphs */

==導入 Introduction==
nagiostatsユーティリティーを使えば、 [http://oss.oetiker.ch/mrtg/ MRTG]を使って、グラフや、Nagiosの性能統計などを時間と共に見ることが出来ます。これは、役に立つので重要な項目です。
*Nagiosが効率的に動作しているかを見ることが出来ます。
*監視しているプロセスで問題が起きた箇所を見つけることが出来ます。
*Nagiosの構成の変更によるパフォーマンスに対する影響を見張ることが出来ます。

==サンプルMRTG設定 Sample MRTG Configuration==
配布されたNagiosの sample-config/ のサブディレクトリにある mrtg.cfg ファイルの中で、様々なNagios性能統計をグラフで描写する、サンプルMRTG設定ファイルの断片を見つけることができます。もし作るのが好きであるなら、他の性能情報のグラフを作成することもできます。サンプルはある程度の良い出発点を提供してくれます。

一度、MRTG設定ファイル(/etc/mrtg/mrtg.cfg)に、これらのサンプル・エントリーをコピーすると、 MRTGが動いた次の時から、いくつかの新しいグラフを得ることが出来ます。

==グラフの例 Example Graphs==
幾つかのサンプルのMRTGグラフが何を意味するのか、そして、それらは何に利用できるのかを説明します・・・

[[ファイル:Mrtg-activehostchecks.png|bottom|right]]アクティブホストチェック - このグラフは、時間と共に、アクティブホストチェック(スケジューリングされたチェックやオンデマンド・ホストチェック)が行われた回数を示します。理解に役立つ項目:
*[[ホストチェック]]
*[[予測依存チェック]]
*[[キャッシュされたチェック|キャッシュによるチェック]]

[[ファイル:Mrtg-activeservicechecks.png|right]]アクティブサービスチェック - このグラフは、時間と共にアクティブ・ホストチェック(スケジューリングされたチェックやオンデマンド・ホストチェック)が行われた回数を示します。理解に役立つ項目:
*[[ホストチェック]]
*[[予測依存チェック]]
*[[キャッシュされたチェック|キャッシュによるチェック]]

[[ファイル:Mrtg-cachedchecks.png|right|bottom]]キャッシュされたホストチェック - このグラフは、時間と共にホストとサービスがキャッシュされ、そのチェックの回数を示しています。理解に役立つ項目:
*[[予測依存チェック]]
*[[キャッシュされたチェック|キャッシュによるチェック]]

[[ファイル:Mrtg-passivechecks.png|right|bottom]]パッシブホストサービス - このグラフは、時間と共にホストとサービスのパッシブ(受け渡し)が行われた回数を示しています。理解に役立つ項目:
*[[パッシブチェック]]

[[ファイル:Mrtg-activelychecked.png|right|bottom]]ホスト/サービスアクティブチェック- このグラフは、時間と共にホストとサービスのアクティブチェックがどれだけの回数(総数)、行われたのかを示します。理解に役立つ項目:
*[[アクティブチェック]]

[[ファイル:Mrtg-passivelychecked.png|right|bottom]]ホスト/サービスパッシブチェック - このグラフは時間と共に、パッシブチェックされたホストとサービス（総数）を示します。理解に役立つ項目:
*[[パッシブチェック]]

[[ファイル:Mrtg-serviceperfstats.png|right|bottom]]平均した、サービスチェックの待ち時間と実行時間 - このグラフは、時間と共にサービスチェックの待ち時間と実行時間の平均を示します。理解に役立つ項目:
*[[サービスチェック]]
*[[Nagiosのパフォーマンスを最適化する]]
一貫して、長い待ち時間を要する場合、以下の１つ以上の変数を微調整する必要性を指し示しています。
*[http://nagios.sourceforge.net/docs/3_0/configmain.html#max_concurrent_checks max_concurrent_checks]
*[http://nagios.sourceforge.net/docs/3_0/configmain.html#check_result_reaper_frequency check_result_reaper_frequency]
*[http://nagios.sourceforge.net/docs/3_0/configmain.html#max_check_result_reaper_time max_check_result_reaper_time]

[[ファイル:Mrtg-servicestatechange.png|right|bottom]]平均したサービスのステータス変化 - このグラフは、時間と共に、サービスのアクティブまたはパッシブチェックで検知した故障などのように、サービスが状態変化(不安定さの基準)した平均の割合を示します。理解に役立つ項目:
*[[フラッピングの検知]]

[[ファイル:Mrtg-hostperfstats.png|right|bottom]]平均したホストチェックの待ち時間と実行時間 - このグラフは、時間と共に、平均したホストチェックの待ち時間と実行時間を示しています。理解に役立つ項目:
*[[ホストチェック]]
*[[Nagiosのパフォーマンスを最適化する]]
一貫して、長い待ち時間を要する場合、以下の１つ以上の変数を微調整する必要性を指し示しています。
* max_concurrent_checks
* check_result_reaper_frequency
* max_check_result_reaper_time

[[ファイル:Mrtg-hoststatechange.png|right|bottom]]ホストの状態の変化の平均 - このグラフは、時間と共に、サービスのアクティブまたはパッシブチェックで検知した故障などのように、ホストの平均の状態変化(不安定さの基準)を%で示しています。理解に役立つ項目:
*[[フラッピングの検知]]

[[ファイル:Mrtg-externalcommands.png|right|bottom]]外部のコマンド - このグラフは、時間と共にNagiosのデーモンによって実行された外部コマンドの数を示しています。多くの外部のコマンドを処理していない場合(分散型の監視セットアップのような場合)、このグラフはほとんど空っぽに見えるかもしれません。外部コマンドを監視することは、外部コマンドがもたらす影響を理解するのに役に立つ場合があります。
*[[パッシブチェック]]
*[[分散監視]]
*[[冗長系とフェールオーバーのネットワーク監視]]

[[ファイル:Mrtg-commandbuffers.png|right|bottom]]外部コマンドバッファ - このグラフは、時間と共に使われた、外部コマンドのバッファのスロット数を示しています。バッファの数が、利用可能なバッファの総数の近くまで行くのならば、利用可能な[http://nagios.sourceforge.net/docs/3_0/configmain.html#external_command_buffer_slots external command buffer slots](外部コマンドのバッファのスロット)を増やす必要ある。それぞれのバッファスロットは、1つの外部コマンドで保持することができます。バッファは、一時的に外部コマンドを保存するために利用されます。その期間は、[http://nagios.sourceforge.net/docs/3_0/configmain.html#command_file external command file](外部コマンドファイル)から読まれて、Nagiosのデーモンで処理される期間です。

キャッシュされたチェック

2010-09-04T13:05:46Z

Wikiadmin: ページの作成: == はじめに　Introduction == Nagiosの監視ロジックの性能は、キャッシュされたチェックを使用することで、とても向上させることができ…

== はじめに　Introduction ==
Nagiosの監視ロジックの性能は、キャッシュされたチェックを使用することで、とても向上させることができます。キャッシュされたチェックで、比較的最近行ったチェックが代わりに用いることができるのならば、 Nagiosは、ホストチェックやサービスチェックの実行を無視することが出来ます。

== オンデマンドチェクのためだけに For On-Demand Checks Only==
定期的にスケジュールされているホストチェックとサービスチェックは、キャッシュされたチェックを使っても、性能の改善はされません。キャッシュされたチェックは、ホストチェックとサービスチェックの、オンデマンド性能を向上させるのだけに役に立ちます。定期的なチェックは、定期的に行われるホストステータスとサービスステータスの更新の確認を手助けします。その結果、将来それらの結果が、キャッシュされたチェックに利用できる大きな可能性を持っているかもしれません。

参考として、オンデマンドホストチェックが実行されます・・・
*ホストに関連したサービスが状態を変えた時
*host reachability(ホストへの到達性) ロジックの一部として必要
*predictive host dependency checks(予測ホスト依存チェック) に必要

そして、オンデマンドサービスチェックが実行されます・・・
*predictive service dependency checks(予測サービス依存チェック) に必要な時

[[ファイル:Hint.gif]]サービスの依存を利用しなければ、Nagiosはサービスチェックの性能を向上させるのにキャッシュされたチェックの結果を使用できません。ご心配はいりません。これが普通なのです。キャッシュされたホストチェックには、大幅な性能改善があるので、皆がこの利益に目を向けるべきなのです。

== キャッシュはどう動くのか How Caching Works ==
Nagiosが、オンデマンドのホストチェックかサービスチェックを実行する必要があるとき、キャッシュされたチェックの結果を使用するか、プラグインの実行による実際のチェック結果を使用するかを判断をします。それは、最後のホストチェックやサービスチェックが直前までのX分間に発生したかどうかを調べる為に行われます。尚、Xはキャッシュされたサービスチェックの保持限界時間を指します。

キャッシュされたチェックの限界変数によって指定された時間枠の中で最後のチェックが行われたならば、 Nagiosは最後のホストチェックやサービスチェックの結果を利用して、新しいチェックは実行しません。ホストやサービスがまだチェックされていない、または最後のキャッシュされたチェックの結果がチェック限界時間枠外になると、 Nagiosは、プラグインを実行して、新しいホストチェックやサービスチェックを実行します。

==これの本当の意味とは What This Really Means==
時間内で、 at that exact moment(正確なその瞬間での) のホストやサービスのステータス(状態)を知る必要があるため、Nagiosはオンデマンドチェックを実行します。キャッシュされたチェックを利用する事は、 Nagiosが、現在のホストの状態を決める為には最新のチェック結果だけで"十分"だと認め、ホストやサービスのステータス(状態)の再チェックも必要でないことを認めることです。

キャッシュされたチェックの限界は、ホストやサービスの現在の状態を反映する為に、チェック結果がどのくらい最近でないといけないかをNagiosに伝えます。例えば、キャッシュされたチェックの限界時間を30秒とする事は、あなたはNagiosにホストのステータスが30秒以内にチェックされたものならば、そのチェック結果はまだ、現在の結果とみなせと指示する事です。

Nagiosは実行されなければいけないオンデマンドチェックの回数に対して、キャッシュされたチェックの結果の回数がキャッシュされたチェックの"hit(ヒット)"率と考えます。ホストの一定間隔のチェックと等しいようにキャッシュされたチェックの限界を増やすことによって、理論上、100%のキャッシュヒット率を達成することが出来るでしょう。その場合、全てのオンデマンドチェックでは、キャッシュされたチェックの結果を使うでしょう。驚くような性能の向上ですね！しかし本当にそうなのでしょうかね？多分違うのですよ。

キャッシュされたチェック結果の情報の信頼性は、時間がたつにつれ減少していきます。より高いキャッシュヒット率を実現するには、前回行ったキャッシュチェックの結果が、より長い時間の間、"有効である"ことを示す必要があります。どのようなネットワークでもその状態は急速に変化していきます。そして、30秒前まで機能していたサーバーが、今現在も障害が発生していないという保証はどこにもありません。信頼性とスピードは、トレードオフ（等価交換）な関係なのです。キャッシュされたチェックの有効限界時間を長くするならば、監視ロジックで使用されるチェックの結果が信頼できないものであるというリスクを冒すことになるのです。

Nagiosは、最終的に全てのホストとサービスの状態を決定するので、キャッシュされたチェックの結果が、本当に信頼できないものだとしても Nagiosは短期間、不適格な情報で動作するのです。短期間の当てにならないステータスの情報でさえ、管理者にとっては厄介なものとなります。それらのせいで、既に存在しない障害の通知を受け取るかもしれないからです。

全てのNagiosユーザが受け入れられるような、標準のキャッシュのチェック時間やキャッシュヒット率はありません。ある人は、短い限界時間枠と低いキャッシュヒット率を求め、他の人は、より大きな限界時間枠と、より大きなキャッシュヒット率（低い信頼性率を持っている）を求めます。ユーザの中には、100%の信頼性のレートを得るために、全体で行われたキャッシュされたチェックを無効にしたがる人すらいます。異なった限界時間枠でテストし、ステータス情報の信頼性へそれらが与える効果を、それぞれのユーザが、自らの環境で試して、「適正」な値を見つける必要があります。これに関する詳しい話は、以下で議論されています。

==設定変数 Configuration Variables==
以下の変数は、前もってホストやサービスのチェック結果がキャッシュされたホストやキャッシュされたサービスの結果として使用できる時間枠を決定します。
*cached_host_check_horizon（キャッシュされたホストの限界時間）変数は、キャッシュされたホストのチェックを制御します。
*cached_service_check_horizon（キャッシュされたサービスの限界時間）変数は、キャッシュされたサービスのチェックを制御します。

==キャッシュの有効性を最適化する Optimizing Cache Effectiveness==
キャッシュされたチェックを、最も効果的に利用するためにするべき事とは・・・:
*ホストの定期的なチェックを計画します。
*1]オンデマンドチェック 2]キャッシュチェックのためMRTGのグラフ統計を使います。
*あなたのニーズに合うように、キャッシュされたチェックの限界変数を調整します。

host definitions（ホスト定義）の check_interval オプションの値を、0以上を指定することで、ホストの定期的なチェックを計画できます。もしこれを行うなら、 max_check_attempts（最大チェック試行数）オプションを、1以上に設定した事を確認します。もし設定しなければ、大きなパーフォーマンスヒットを起こします。この潜在的パフォーマンスヒットは、 [http://nagios.sourceforge.net/docs/3_0/hostchecks.html ここ]で、詳しく述べられています。

キャッシュされたチェックの限界オプションの最適値を決定するための近道は、 Nagiosが実際にオンデマンドチェックを実行した数と、キャッシュされた値を使う回数を比較することです。 nagiostats（ナギオスタッツ）ユーティリティは、キャッシュされたチェックの情報を作り出すことができます。それは、 graphed with MRTGのグラフを作る事で可能になります。右に示すように、MRTGのグラフはキャッシュに対し、実際のオンデマンドチェックを対比して示しています。

上記のグラフを作り出す監視ソフトをインストールしましょう:
*合計44個のホスト全てが、一定の間隔でチェックされました。
*5分の平均した(定期的にスケジュールされている)ホストチェック間隔
*15秒の、 cached_host_check_horizon（キャッシュされたホストの限界時間）

最初のMRTGグラフは、どのくらい多くのキャッシュされたホストチェックが、通常のホストチェックに比べてスケジュールされたかを示しています。この例では、平均53のホストチェックが5分毎に起こります。これら内、9個(17%)はオンデマンドチェックです。

2番目のMRTGのグラフは、どれだけのキャッシュされたホストのチェックが時間内に起こったのかを示しています。この例では、キャッシュされたホストのチェックは5分毎に平均2回起こるということになります。

キャッシュされたチェックは、オンデマンドチェックだけで利用可能だという事を覚えておいてください。 5分間の平均に基づいたグラフから、 Nagiosがオンデマンドのチェックの9回中2回をキャッシュされたホストチェックの結果を使用しているという事がわかります。それはあまり実感できないものかもしれませんが、これらのグラフは小さな監視環境でのグラフです。 9個中の2個が22%であり、もしこれが、大規模な環境ならば、ホストチェック性能を大幅に向上させる事がいかに大切なのかが分かります。キャッシュされたホストチェックの限界変数の値が増加したらパーセントは高くなります。しかし、キャッシュされたホストのステータスの情報の信頼性は低くなります。

何時間か何日かの有用なMRTGグラフが出来あがると、どれだけの数のホストとサービスのチェックがどれだけの数のプラグインを使用して行われ、それに対しキャッシュされた結果がどれだけ使われたのかがわかります。その情報を用いれば、あなたの状況に適切なキャッシュされたチェックの限界変数の値に調整することができます。 MRTGグラフをずっと監視し続けていると、どのように限界変数の変更がキャッシュされたチェックの統計に影響を与えるかが分かります。これらは、必要に応じて更新を繰り返します。

フラッピングの検知

2010-09-04T12:58:32Z

Wikiadmin: ページの作成: == 導入 Introduction == Nagiosはオプションで、ホストとサービスの"flapping（バタつき）"を検知する機能があります。バタつきは、ホスト…

== 導入 Introduction ==
Nagiosはオプションで、ホストとサービスの"flapping（バタつき）"を検知する機能があります。バタつきは、ホストやサービスの状態が頻繁に変化し、障害と復旧の通知が大量に発生した時に発生します。バタつきは、設定の問題(閾値が低すぎる等)もしくは、実際のネットワーク障害を示すことができます

== バタつきの検知はどのようにして動いているのか How Flap Detection Works==
この説明に移る前に・・・バタつきの検知機能を実装するのは困難だったと言わざるを得ません。特定のホストやサービスの状態変化に関しては、どのようにして状態の変化が "too frequently（あまりに頻繁である）" と決めればいいのだろうか。バタツキ検知の最初に実装を始める際に、どのようにしてバタツキを検知できるか、検知すべきかについてのいくつかの情報を見つけようとしました。私は、他の人が使っていたものに関する情報（そこで何をしていたか等）は、全く見つけることができませんでした。だから、理にかなった解決であるようだった。ということで落ちつくことに決めました・・・

Nagiosがホストやサービスの状態をチェックする場合は常に、バタつきを始めたか止めたかどうかチェックするでしょう。その為には以下でこれを行います。

*ホストまたはサービスの21回のチェックの結果を格納します
*過去のチェック結果を分析して、状態変化・変遷がどこに発生するかを決定します。
*ホストやサービスのために、状態変化率(変化の測定)を測定するのために状態遷移を使用します。
*バタつきの閾値の、上限下限に状態変化率の値を、パーセントで比較します。

状態変化率が最初に高い方のバタつき閾値を上回るとき、ホストやサービスがバタつきをはじめたと決定します。

バタつきが状態変化率の閾値を下回る場合は(以前からばたついていた場合も想定する)、ホストやサービスのバタつきが止まったと判断します

== 例 Example==
では、サービスのバタつき検知がどのようにして働いているかを詳細に説明していきましょう・・・

下記の画像は、一番新しい21のサービスチェックからの、時系列順のサービス状態の履歴を示します。 OKステートは緑、WARNINGステートは黄色、CRITICALステートは赤で、UNKNOWNステートはオレンジになります。

[[ファイル:Statetransitions.png]]

ホストチェック

2010-09-04T12:53:53Z

Wikiadmin: ページの作成: == 導入 Introduction== ホストチェックの基本的な働きをここでは記述していきます。 == いつホストチェックは行われるの？ When Are Host …

== 導入 Introduction==
ホストチェックの基本的な働きをここでは記述していきます。

== いつホストチェックは行われるの？ When Are Host Checks Performed?==
ホストは、Nagiosのデーモンによってチェックされます。
*通常のチェック間隔は、あなた自身のホスト定義に記載できるオプションであるcheckアクションの実行を繰り返す時間間隔と接続を再試行する時間間隔によって定義されています
*利用者の需要に応じて、ホストの状態の変化とサービスを結び付けて見張ります。
*利用者は、ホストへの到達可能性を見張る役割も必要とされています。
*利用者は、ホストへの依存から予測するチェックを必要としています。

通常のホストチェックのスケジュールは任意で決めることが出来ます。もしあなたが、check_interval(checkアクションの実行を繰り返す時間間隔)を設定でゼロに設定したならば、 Nagiosは基本的なホストチェックすら出来なくなるでしょう。しかしながら、利用者はホストに対する自らの望みに沿ったチェックを、監視ロジックの一部としてと必要とします。

オンデマンド・チェックはホストの状態の変化とサービスを関連付けて考えます。なぜなら、Nagiosはホストの状態が変化しているかどうかを知る為のソフトだからです。状態がよく変化するものには、ホストの状態が変化しているかどうかだけを見る指標を用いたサービスチェックもあります。例えば、もしNagiosがホストのHTTPサービスがCRITICAL(クリティカル状態・重大な異常を示す)からOK(正常状態)へと変化したことを検知したならば、恐らくそのホストがリブートから復旧したことやバックアップシステムが動き出したことを指し示すでしょう。

ホストのオンデマンド・チェックはホストへの到達可能性を調べる方法を利用して作られています。 Nagiosは、ネットワークの供給停止を出来るだけ素早く検知するように設計されています。そして、ホストの状態が、DOWN(ホストダウン)なのかUNREACHABLE(ホストまでpingが届いていない)状態のいずれかを識別します。それら2つはとても異なる状態なので、識別できることによって、ネットワーク管理者がネットワークの供給停止の原因を素早く突き止める手助けとなるのです。

オンデマンド・チェックは、predictive host dependency check(ホストへの依存から予測するチェック)の仕組みを利用して行われています。それらのチェックは、出来るだけ的確で依存性のある仕組みによって確実なものへと裏付けられています。

==キャッシュされたホストチェック Cached Host Checks==
オンデマンド・ホストチェックの実行はキャッシュされたチェックを手助けに利用すれば、著しく向上させることが出来ます。 Nagiosにホストチェックの実行を無視することを許し、もし関係性のあるチェックの結果の代わりになるものを決めればさらに向上させることも出来まする。キャッシュを利用したチェックについてより知りたければ、[http://nagios.sourceforge.net/docs/3_0/cachedchecks.html ここ]のページを見てください。

==依存性とチェック Dependencies and Checks==
host execution dependencies(ホスト毎の実行に関する依存)を定義することが出来ます。それによって、Nagiosが、一つ、あるいは他の複数のホストの状態に依存したホストの状態(ステータス)のチェックするのを妨げることになります。依存性に関してより深く知りたい場合は、ここを見ると良いです。

==ホストチェックの並列処理 Parallelization of Host Checks==
定期的なホストチェックは並列処理されます。 Nagiosがスケジューリングされたホストチェックを実行する際は、スケジュールされたホストチェックを始め、その後、一旦手を止めていた他の作業(実行中のサービスチェックなど)に戻ります。ホストチェックは、Nagiosのデーモンから分岐した子プロセスとして実施されます。ホストチェックが完了したら、子プロセスはNagiosの親プロセスにチェックの結果を伝えます。 Nagiosの主な処理は、チェック結果に対し適切な処理を下し解決を行うことです。(イベントハンドラの実行や障害の通知など)

オンデマンド・ホストチェックも必要があるのならば、並列処理を行うことも出来ます。先述したように、Nagiosは比較的新しいホストチェックからのキャッシュされた結果として利用されるなら、オンデマンド・ホストチェックの実際の実行をとめることも出来ます。

Nagiosが、スケジュールされたホストチェックや、オンデマンド・ホストチェックを実行する際に、他のホストのチェックも始めるかもしれないです。それらのチェックは、predictive dependency checks(依存性から予測したチェック)や、ホストが使う、network reachability(ネットワークの利用の可能性) の仕組みに対する決定に影響を与えるような、以上の2つの要因によって始められます。 2番目のチェックは、たいていは並列処理で実行されます。しかし、予期せぬ大きな例外事項が起きた際には、それによってパフォーマンスに悪い影響を与えられることもあるのです。

Note ホストの max_check_attempts(サービスチェックがOK以外の状態を返した時に何度Nagiosが再試行するかの回数) 数を 1 に設定したら、パフォーマンスには深刻な影響が出ます。その理由は何だって？もしNagiosが network reachability(ネットワークの到達可能性)の仕組み(DOWNやUNREACHABLE等の状態が見える状態)を利用して真の値を決定する必要があるのならば、親プロセスに近いすべてのホストの serial(連続番号) を調べる必要があるのです。だからこそ、常に max_check_attempts(サービスチェックがOK以外の状態を返した時に何度Nagiosが再試行するかの回数) を1より大きな値にすれば、並列処理の時よりも高いパフォーマンスを得ることが出来るのです。

==ホストの状態 Host States==
チェックされるホストは3つの異なった状態の一つに分類される：
*正常
*ホストダウン
*ホストまで未到達

==ホストの状態の決定 Host State Determination==
ホストチェックは、 [http://nagios.sourceforge.net/docs/3_0/plugins.html plugins(プラグイン)]によって実行されます。プラグインは、OK、WARNING、UNKNOWN、またはCRITICALの状態を返すことが可能です。では、どのようにしてNagiosは、プラグインの返す値をUPやDOWNやUNREACHABLEといったホストの状態へと変換するのでしょうか。それはですね・・・

下記の表は、プラグインが返す値と一つ前のホストの状態がどのようなものなのかを示す表です。いくつかの後処理(後に述べる)がなされると、ホストの最終的な状態が変化するものもあります。

<table border=1>
<tr><th>プラグインによる結果</th><th>ホストのひとつ前の状態</th></tr>
<tr><td>OK</td><td>UP</td></tr>
<tr><td>WARNING</td><td>UP or DOWN*</td></tr>
<tr><td>UNKNOWN</td><td>DOWN</td></tr>
<tr><td>CRITICAL</td><td>DOWN</td></tr>
</table>

[[ファイル:Note.gif|bottom]]WARNING は大抵はホストがUP状態であることを意味します。しかし、use_aggressive_host_checking(アグレッシブホストチェック→このオプションを無効にするとNagiosは、チェックをより早く行おうとする。有効にした場合、ホストチェックに多く時間を使うが、確実性は少し上昇する。Nagiosホストの復旧をあまり検知しない問題がある場合を除いて、このオプションは無効にすることをお勧めします。) のオプションを有効にしているのならば、 WARNING という結果がホストの DOWN を意味することもあります。

もし一つ前のホストの状態が DOWN ならば、Nagiosは本当にホストが DOWN しているのかや UNREACHABLE なのかを確認しようと試みます。ホストの、DOWN と UNREACHABLE の間の状態の区別は、管理者がネットワークの供給停止の原因の根本を素早く確定するための手助けになるので重要です。下記の表は、Nagiosの親ホストの最終状態の決定がどのようにして決められるのかを示しています。

<table border=1>
<tr><th>一つ前のホストの状態</th><th>親ホストの状態</th><th>ホストの最終状態</th></tr>
<tr><td>DOWN</td><td>少なくとも一つの親ホストは UP である</td><td>DOWN</td></tr>
<tr><td>DOWN</td><td>すべての親ホストが、 DOWN か UNREACHABLE のいづれかである</td><td>UNREACHABLE</td></tr>
</table>

== ホストの状態変化 Host State Changes ==
恐らくお分かりでしょうが、ホストはずっと同じ状態では留まってはいません。物理的な故障、パッチの適用、必要不可欠なサーバのリブートなどがあるのです。 Nagiosはホストの状態をチェックする時、 UP と DOWN と UNREACHABLE の状態の間のホストの変化を検出し、適切な処理をすることができるのです。これらの状態変化の結果は、異なった state types(状態の種類)（HARDやSOFT）があり、これを引き金として、 event handlers(イベントハンドラ) の実行、 notifications(通知) を行います。状態の変化を検出し、対応することは、Nagiosの行っていることの全てです。

ホストがあまりに頻繁に状態を変化させることを、"flapping(バタバタしている状態、バタツキ)"であると考えられます。 flapping しているホストの良い例の一つに、「OSが読み込まれた際すぐに、自発的にリブートし続けようとするサーバーのようなものである」というものがあります。この例は、詳細を語る上でよく使われる面白い例です。 Nagiosはサービスがいつ flapping (バタツキ)を始めたかを検出できます。そして、バタツキが止まって、サービスの状態が安定するまで、通知を止めることができます。もし詳しくバタツキを検出する仕組みが知りたいならば、 [http://nagios.sourceforge.net/docs/3_0/flapping.html ここ]を見ると良いです。

Nagiosの標準マクロ

2010-09-04T12:21:10Z

Wikiadmin: /* マクロ有効性チャート Macro Availability Chart */

Nagiosで利用できる標準のマクロはここに記載されています。

カスタムメイドのためのオンデマンド・マクロとマクロについては[http://oss.aspect-sys.co.jp/nagios_jp/macros.html ここ]で記述されます。

==マクロの有効性 Macro Validity==
マクロは全てのコマンド定義で使うことができますが、全てのマクロが特別な種類のコマンドで常に有効なわけではありません。

例えば、いくつかのマクロはサービス通知コマンドの間だけ有効ですが、他はホストチェックコマンドの間だけ有効なのかもしれません。

Nagiosが異なると認識して扱う10種類のコマンドがあります。

それらは以下の通りです:

#サービスチェック
#サービス通知
#ホストチェック
#ホスト通知
#サービスイベントハンドラ、そして/または、グローバルサービスイベントハンドラ
#ホストイベントハンドラ、そして/または、グローバルなホストイベントハンドラ
#OCSPコマンド
#OCHPコマンド
#サービスパーフォマンスデータコマンド
#ホストパーフォーマンスデータコマンド

以下のテーブルは現在Nagiosで利用可能な全マクロの簡単な説明とそれらが有効なコマンドの種類の一覧です。

もしマクロが正しくないコマンドの種類で使われるたとき、それは "" 文字で置き換えられます。

マクロがすべて大文字のキャラクタから出来ていて、$キャラクタで囲まれる事に注意する必要があります。

==マクロ有効性チャート Macro Availability Chart==
説明
{|class="Default" border="1" cellpadding="5" cellspacing="0"
|-
!! class="MacroNo" | No 
! マクロは利用できません。 

|-
!! class="MacroYes" | Yes 
!マクロは利用できます
|}

{| border="1" cellpadding="5" cellspacing="0"
|- class="Macros"
!! class="Macros" | マクロ名
!! class="Macros" | サービスチェック 
!! class="Macros" | サービス通知 
!! class="Macros" | ホストチェック 
!! class="Macros" | ホスト通知 
!! class="Macros" | サービスイベントハンドラと[http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ocsp_command OCSP]
!! class="Macros" | イベントハンドラと [http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ochp_command OCHP]
!! class="Macros" | サービスパーフォーマンスデータ
!! class="Macros" | ホストパーフォマンスデータ
|-
| colspan="9" class="MacroType" | ホストマクロ:[[#note3 | 3 ]]

|-
!! class="MacroName" | [[#hostname | $HOSTNAME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostdisplayname | $HOSTDISPLAYNAME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostalias | $HOSTALIAS$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostaddress | $HOSTADDRESS$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hoststate | $HOSTSTATE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hoststateid | $HOSTSTATEID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthoststate | $LASTHOSTSTATE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthoststateid | $LASTHOSTSTATEID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hoststatetype | $HOSTSTATETYPE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostattempt | $HOSTATTEMPT$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#maxhostattempts | $MAXHOSTATTEMPTS$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hosteventid | $HOSTEVENTID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthosteventid | $LASTHOSTEVENTID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostproblemid | $HOSTPROBLEMID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthostproblemid | $LASTHOSTPROBLEMID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostlatency | $HOSTLATENCY$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostexecutiontime | $HOSTEXECUTIONTIME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostduration | $HOSTDURATION$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostdurationsec | $HOSTDURATIONSEC$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostdowntime | $HOSTDOWNTIME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostpercentchange | $HOSTPERCENTCHANGE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupname | $HOSTGROUPNAME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupnames | $HOSTGROUPNAMES$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthostcheck | $LASTHOSTCHECK$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthoststatechange | $LASTHOSTSTATECHANGE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthostup | $LASTHOSTUP$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthostdown | $LASTHOSTDOWN$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#lasthostunreachable | $LASTHOSTUNREACHABLE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostoutput | $HOSTOUTPUT$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#longhostoutput | $LONGHOSTOUTPUT$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostperfdata | $HOSTPERFDATA$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes [[#note1 | 1]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostcheckcommand | $HOSTCHECKCOMMAND$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostackauthor | $HOSTACKAUTHOR$]] [[#note8 | 8]] 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class="MacroYes" | Yes 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 

|-
!! class="MacroName" | [[#hostackauthorname | $HOSTACKAUTHORNAME$]] [[#note8 | 8]] 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class="MacroYes" | Yes 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 

|-
!! class="MacroName" | [[#hostackauthoralias | $HOSTACKAUTHORALIAS$]] [[#note8 | 8]] 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class="MacroYes" | Yes 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 

|-
!! class="MacroName" | [[#hostackcomment | $HOSTACKCOMMENT$]] [[#note8 | 8]] 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class="MacroYes" | Yes 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 
!! class=MacroNo" | No 

|-
!! class="MacroName" | [[#hostactionurl | $HOSTACTIONURL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostnotesurl | $HOSTNOTESURL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostnotes | $HOSTNOTES$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#totalhostservices | $TOTALHOSTSERVICES$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#totalhostservicesok | $TOTALHOSTSERVICESOK$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#totalhostserviceswarning | $TOTALHOSTSERVICESWARNING$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#totalhostservicesunknown | $TOTALHOSTSERVICESUNKNOWN$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#totalhostservicescritical | $TOTALHOSTSERVICESCRITICAL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
|

|- class="Macros"
!! class="Macros" | マクロ名
!! class="Macros" | サービスチェック 
!! class="Macros" | サービス通知 
!! class="Macros" | ホストチェック 
!! class="Macros" | ホスト通知 
!! class="Macros" | サービスイベントハンドラと[http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ocsp_command OCSP]
!! class="Macros" | イベントハンドラと [http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ochp_command OCHP]
!! class="Macros" | サービスパーフォーマンスデータ
!! class="Macros" | ホストパーフォマンスデータ
|-
| colspan="9" class="MacroType" | ホストグループマクロ:

|-
!! class="MacroName" | [[#hostgroupalias | $HOSTGROUPALIAS$]] [[#note5 | 5]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupmembers | $HOSTGROUPMEMBERS$]] [[#note5 | 5]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupnotes | $HOSTGROUPNOTES$]] [[#note5 | 5]] 
!! class="MacroYes" | Yes 

!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupnotesurl | $HOSTGROUPNOTESURL$]] [[#note5 | 5]] 

!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 

|-
!! class="MacroName" | [[#hostgroupactionurl | $HOSTGROUPACTIONURL$]] [[#note5 | 5]] 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes

|-
|

|- class="Macros"
!! class="Macros" | マクロ名
!! class="Macros" | サービスチェック 
!! class="Macros" | サービス通知 
!! class="Macros" | ホストチェック 
!! class="Macros" | ホスト通知 
!! class="Macros" | サービスイベントハンドラと[http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ocsp_command OCSP]
!! class="Macros" | イベントハンドラと [http://oss.aspect-sys.co.jp/nagios_jp/configmain.html#ochp_command OCHP]
!! class="Macros" | サービスパーフォーマンスデータ
!! class="Macros" | ホストパーフォマンスデータ
|-
| colspan="9" class="MacroType" | サービスマクロ:

|-
!! class="MacroName" | [[#servicedesc | $SERVICEDESC$]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicedisplayname | $SERVICEDISPLAYNAME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicestate | $SERVICESTATE$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicestateid | $SERVICESTATEID$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicestate | $LASTSERVICESTATE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicestateid | $LASTSERVICESTATEID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicestatetype | $SERVICESTATETYPE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceattempt | $SERVICEATTEMPT$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#maxserviceattempts | $MAXSERVICEATTEMPTS$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceisvolatile | $SERVICEISVOLATILE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceeventid | $SERVICEEVENTID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastserviceeventid | $LASTSERVICEEVENTID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceproblemid | $SERVICEPROBLEMID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastserviceproblemid | $LASTSERVICEPROBLEMID$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicelatency | $SERVICELATENCY$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceexecutiontime | $SERVICEEXECUTIONTIME$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceduration | $SERVICEDURATION$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicedurationsec | $SERVICEDURATIONSEC$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicedowntime | $SERVICEDOWNTIME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicepercentchange | $SERVICEPERCENTCHANGE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicegroupname | $SERVICEGROUPNAME$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicegroupnames | $SERVICEGROUPNAMES$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicecheck | $LASTSERVICECHECK$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicestatechange | $LASTSERVICESTATECHANGE$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastserviceok | $LASTSERVICEOK$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicewarning | $LASTSERVICEWARNING$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastserviceunknown | $LASTSERVICEUNKNOWN$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#lastservicecritical | $LASTSERVICECRITICAL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceoutput | $SERVICEOUTPUT$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#longserviceoutput | $LONGSERVICEOUTPUT$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceperfdata | $SERVICEPERFDATA$ ]]
!! class="MacroYes" | Yes [[#note2 | 2]] 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicecheckcommand | $SERVICECHECKCOMMAND$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceackauthor | $SERVICEACKAUTHOR$]] [[#note8 | 8]] 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceackauthorname | $SERVICEACKAUTHORNAME$]] [[#note8 | 8]] 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceackauthoralias | $SERVICEACKAUTHORALIAS$]] [[#note8 | 8]] 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceackcomment | $SERVICEACKCOMMENT$]] [[#note8 | 8]] 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#serviceactionurl | $SERVICEACTIONURL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicenotesurl | $SERVICENOTESURL$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 

|-
!! class="MacroName" | [[#servicenotes | $SERVICENOTES$ ]]
!! class="MacroYes" | Yes 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No 
!! class="MacroYes" | Yes 
!! class="MacroNo" | No

Nagiosの起動と停止

2010-09-03T02:51:37Z

Wikiadmin: ページの作成: == Nagiosの起動 Starting Nagios== 1.Initスクリプトで行う: Nagiosのデーモンを簡単に起動する方法は、以下のようにinitスクリプトを使うこと…

== Nagiosの起動 Starting Nagios==
1.Initスクリプトで行う: Nagiosのデーモンを簡単に起動する方法は、以下のようにinitスクリプトを使うことです。:
<pre>
/etc/rc.d/init.d/nagios start
</pre>

2.手動で行う: Nagiosを -d オプションを付けて以下のように手動で起動することが出来ます。:
<pre>
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
</pre>

== Nagiosの再起動 Restarting Nagios==
設定ファイルを変更して、その変更を反映したい時は、再起動やリロードが必要です。

1.Initスクリプトで行う: Nagiosのデーモンを簡単に再起動する方法は、以下のようにinitスクリプトを使うことです。:
<pre>
/etc/rc.d/init.d/nagios reload
</pre>

2.ウェブインターフェースで行う: ウェブインタフェースを使って、 "Process Info（プロセス情報）"画面から"Restart the Nagios process（Nagiosプロセスの再起動）"を選ぶことでNagiosを再起動できます。:
<pre>
Restart the Nagios process
</pre>

3.手動で行う: Nagiosプロセスに、以下のようにSIGHUP信号を送ることで再起動することができます::
<pre>
kill -HUP <nagios_pid>
</pre>

==Nagiosの停止 Stopping Nagios==
1.Initスクリプトで行う: Nagiosのデーモンを簡単に再起動する方法は、以下のようにinitスクリプトを使うことです。:
<pre>
/etc/rc.d/init.d/nagios stop
</pre>

2.ウェブインターフェースで行う:ウェブインタフェースを使って、 "Process Info（プロセス情報）"画面から"Shutdown the Nagios process（Nagiosプロセスの停止）"を選ぶことでNagiosを停止できます。:
<pre>
Shutdown the Nagios process
</pre>

3.手動で行う: 以下のように、SIGTERM信号を送ることで、Nagiosプロセスを止めることができます:
<pre>
kill <nagios_pid>
</pre>

Nagiosのアップグレード

2010-09-03T02:44:17Z

Wikiadmin: ページの作成: ==前のNagios 3.xリリースからのアップグレード Upgrading From Previous Nagios 3.x Releases== Nagios 3.xの、新しいα版、ベータ版、あるいは安定し…

==前のNagios 3.xリリースからのアップグレード Upgrading From Previous Nagios 3.x Releases==
Nagios 3.xの、新しいα版、ベータ版、あるいは安定したリリースがリリースされた時は、できるだけ早いアップグレードを考慮するべきです。新しいリリースは、大抵重要なバグフィックス情報を含んでいるので、その情報を最新のものに保つことが重要となるのです。 [[導入ガイド]]クイックスタートガイド)で説明されているように、ソースコードからNagiosを既にインストールしていたとしたならば、簡単にNagios 3.xの、より新しいバージョンをインストールすることが出来ます。これを行うには、全ての過程でroot権限でアクセスすることすら必要ではなく、最初のインストールの間だけ、ルート権限で行えば全て出来るのです。ここに、アップグレードの過程が書いてあります・・・

まず、既存のNagiosのインストールと、構成ファイルの良好な状態のバックアップがあることを確認します。これがあれば、もし仮に何か予期せぬ事態が起きたり、動作しなくても、これらがあれば古いバージョンへ戻すことが出来ます。

まず、Nagiosユーザになります。 DebianやUbuntuのユーザは、sudo -s nagiosを使いましょう。

<pre>
su -l nagios
</pre>

次に挙げているような、webページのフォントを記した古いHTMLファイルを消します。それらは既に、PHPによって同等なものに置き換えられていますので。

<pre>
rm /usr/local/nagios/share/{main,side,index}.html
</pre>

Nagiosの最新版のソースコードのtarballをダウンロードします。 (こちらのリンク http://www.nagios.org/download/ より最新版をダウンロードします)。

<pre>
wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios-3.x(最新版のバージョン名).tar.gz　
</pre>

Nagiosのソースコードを解凍します。

<pre>
tar xzf nagios-3.x.tar.gz
cd nagios-3.x
</pre>

Nagiosのconfigureスクリプトを実行してください。引数には、外部コマンドを実行するのに必要なグループ名を付けて、以下のように行ってください：
<pre>
./configure --with-command-group=nagcmd
</pre>

Nagiosのソースコードをコンパイルします

<pre>
make all
</pre>

更新済みのバイナリ、ドキュメント、WebのWebインターフェイスをインストールします。既存の設定ファイルは、このステップでは上書きされません。

<pre>
make install
</pre>

Nagiosの設定ファイルを確認します。いくつかのエラーがここで出てきたならば、続けて述べる作業に進む前にそれらを修正して下さい。

<pre>
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
</pre>

Nagiosを再起動します。 DebianやUbuntuのユーザは、/etc/init.d/nagios restartを使いましょう。

<pre>
/sbin/service nagios restart
</pre>

これでおしまいです。

==Nagios 2.xからアップグレード Upgrading From Nagios 2.x==
Nagios 2.xから、Nagios3までアップグレードするのは、それほど難しくはありませんアップグレードは、最新の3.xリリースにアップグレードするため、先程上で説明したことと、本質的には同じことになります。しかし、それらがNagios 3系列で動作する為には、設定ファイルを少し変える必要があります:
*以前のメインの設定ファイル内にあった、service_reaper_frequency変数は、[http://nagios.sourceforge.net/docs/3_0/configmain.html#check_result_reaper_frequency check_result_reaper_frequency]に変更されています。
*以前の $NOTIFICATIONNUMBER$ マクロは、新しい [http://nagios.sourceforge.net/docs/3_0/macrolist.html#hostnotificationnumber $HOSTNOTIFICATIONNUMBER$] と [http://nagios.sourceforge.net/docs/3_0/macrolist.html#servicenotificationnumber $SERVICENOTIFICATIONNUMBER$] マクロに有利に働くので、非推奨とされています。
*すべてのサービスチェックが平行処理で動くので、サービス定義の古い parallelize(並列処理) は、使用されません。
*以前のバージョンでは存在した、 aggregate_status_updates オプションを削除しました。すべてのステータスファイルの更新は、最小間隔1秒で集計することが出来ます。
*拡張ホストと、拡張サービス定義は推奨しません。それらは、既にNagiosに読み込まれて処理されていますが、これらの定義で、それぞれのホスト定義やサービス定義への指示を動かすことを推奨しています。
*メイン設定ファイルの、古い downtime_file ファイルの変数はもうサポートされておらず、停止時間エントリのスケジュールが [http://nagios.sourceforge.net/docs/3_0/configmain.html#state_retention_file retention file]に保存されています。既存の停止時間エントリを保存して、Nagios 2.xを止め、以前の停止時間ファイルのコンテンツをretention file(リテンションファイル・保持ファイル )に追加します。
*以前の comment_file 変数はメインコンフィグファイルではもうサポートされておらず、最新版では、[http://nagios.sourceforge.net/docs/3_0/configmain.html#state_retention_file retention file](保持ファイル)にコメントとして保存されています。既存のコメントを保存して、Nagios 2.xを止め、以前の停止時間ファイルのコンテンツをretention file(リテンションファイル・保持ファイル )に追加します。

また、ドキュメントの"[http://nagios.sourceforge.net/docs/3_0/whatsnew.html What's New(新着情報)]"を必ず読んでください。そこでは、Nagios 2.xの最新安定版のリリース以降、Nagios3のコードに施された全ての変更について説明しています。 2から3では、かなり変更されていますので、しっかりと読んでください。

==RPMからインストールしアップグレードを行う Upgrading From an RPM Installation==
現在、RPMまたは、NagiosのDebianやUbuntuのAPTのパッケージベースのインストールをしてあって、公式のソースコードからNagiosをインストールしてバージョン3へと移行する為には、ここでの基本的なプロセスに従う必要があります:
#Nagiosを止めます。
#既存のNagiosインストールのバックアップをとります。
#*設定ファイル
#**メイン設定ファイル (通常は nagios.cfg です)
#**リソース設定ファイル (通常は resource.cfg です)
#**CGI設定ファイル (通常は cgi.cfg です)
#**全てのオブジェクト定義のファイル
#*保存ファイル (通常は retention.dat です)
#*現在のNagiosのログファイル (通常は nagios.log です)
#*Nagiosのログファイルのアーカイブ
#オリジナルのRPMかAPTパッケージをアンインストールします。
#ソースから、 [[導入ガイド]](クイックスタートガイド) に従うことでNagiosをインストールします
#元々のNagios設定ファイル、保存ファイル、およびログファイルを復旧します。
#設定について[[Nagiosの設定を検証する|Verify(確かめ)]]します、そして、Nagiosを start(起動) します。

RPMあるいはAPTのパッケージが、異なる方法、および異なる場所にNagiosをインストールするかもしれないことは注意して下さい。問題が生じた際に、元に戻せるように、オリジナルのRPMかAPTパッケージを削除する前に、すべての重要なNagiosファイルを必ずバックアップしておいてください。

冗長系とフェールオーバーのネットワーク監視

2010-09-03T01:27:18Z

Wikiadmin: /* シナリオ2 - 監視のフェイルオーバー化 (Scenario 2 - Failover Monitoring) */

== 導入 Introduction==
このセクションでは、様々なタイプのネットワークレイアウトで冗長化監視を実現するためのいくつかのシナリオについて述べます。冗長化ホストを使うことにより、Nagiosを実行する主要なホストがダウンしたりする場合や、ネットワークの一部に到達できなくなる場合に、あなたのネットワークを監視機能を維持することができます。

[[ファイル:Note.gif|bottom]]もし、Nagiosの使用方法を学んでいるところであれば私が示した前提条件になれるまでは、冗長化を試さないように提案します。冗長化は、理解するのに比較的複雑な問題であり、適切に実行させるのも難しいのです

==index==
[[冗長系とフェールオーバーのネットワーク監視#前提条件　(Prerequisites)|前提条件]]

[[冗長系とフェールオーバーのネットワーク監視#サンプルスクリプト　(Sample Scripts)|サンプルスクリプト ]]

[[冗長系とフェールオーバーのネットワーク監視#シナリオ 1 - 監視の冗長化　(Scenario 1 - Redundant Monitoring)|シナリオ 1 - 監視の冗長化]]

[[冗長系とフェールオーバーのネットワーク監視#シナリオ2 - 監視のフェイルオーバー化 (Scenario 2 - Failover Monitoring) |シナリオ 2 - 監視のフェイルオーバー化]]

==前提条件　(Prerequisites)==
冗長化の実装について考える前に、以下をよく知っている必要があります...
*ホストとサービスのための[[イベントハンドラ]]の実装
*Nagiosへシェルスクリプト経由での[[外部コマンド]]の発行
*[[Nagios アドオン#NRPE|nrpe アドオン]]または、他の方法を利用してリモートホスト・プラグインの実行
*check nagios プラグインを利用してNagiosのプロセスチェック

==サンプルスクリプト　(Sample Scripts)==
私がこのドキュメントの中で使用するサンプル・スクリプトは、Nagiosディストリビューションのサブディレクトリ内のeventhandlers/ですべて見つけることができます。ただ、あなたのシステム上で実行させる為には、修正が必要でしょうが･･･。

==シナリオ 1 - 監視の冗長化　(Scenario 1 - Redundant Monitoring)==
=== 導入 Introduction===
この方法は、あなたのネットワーク上で冗長化監視を実装する簡単(かつ素朴な)方法であり、限られたケースの障害にのみ有効です。異なるネットワークセグメントを超える等のより優れた冗長化、より堅牢な冗長化を提供するためには、より複雑なセットアップが必要です。

=== 目的 Goals===
ここでの冗長化の目的は単純です。「マスター」と「スレーブ」の両ホストは、ネットワーク上の同じホストとサービスを監視します。普通の状況の下では、「マスター」ホストだけが通知先に障害に関する"通知"を送るでしょう。私たちは「スレーブ」ホストが、次に挙げるような問題が発生した場合に通知先に通知する仕事を引き継いでNagiosを実行することを望みます。例えば、
#Nagiosを実行している"マスター"ホストがダウンしている･･･。または、･･･
#"マスター"上のNagiosプロセスが何かの理由でストップしている･･･、など

===ネットワークレイアウトダイアグラム Network Layout Diagram===
下記のダイアグラムは非常に単純なネットワークを示しています。このシナリオでは、ホストAおよびホストEがNagiosを実行しており図中のすべてのホストをモニターしている、ことを想定しています。ホストAは「マスター」ホスト、ホストEは「スレーブ」ホストと考えます。

[[ファイル:Redundancy.png|left]]

===初期プログラム設定 Initial Program Settings===
スレーブホスト(ホストE)は初期設定の[http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_notifications enable_notifications]ディレクティブが無効になっているためホストやサービスの通知は行われません。同様にスレーブホストは[http://nagios.sourceforge.net/docs/3_0/configmain.html#check_external_commands check_external_commands]ディレクティブを有効にしておきます。これらの設定は簡単でしょう・・・。

===初期設定 Initial Configuration===
次に、マスターとスレーブの[[オブジェクト設定概要]]の違いを見る必要があります・・・。

上のダイヤグラムの全ホストの監視をマスターホスト(ホストA)が行う設定と仮定します。スレーブホスト(ホストE)はマスターホストと同じ監視ホスト、サービスの設定を行う必要があり、それに加えて次の設定を行います・・・。

*TホストA(ホストEの設定ファイルホストAのホスト定義に、[[イベントハンドラ]]を設定する必要があります。このイベントハンドラの名前は handle-master-host-eventとします。
*ホストEの設定ファイルにホストAのNagiosプロセスを監視するためのサービス定義を記述します。これは check_nagiosプラグインをホストA上で動かすということと仮定します。これはこのFAQ通りにやればよいでしょう。(アップデートしてください!).
*ホストAのNagiosプロセスチェックのサービス定義に[[イベントハンドラ]]を設定します。このイベントハンドラの名前はhandle-master-proc-eventとしておきます。

重要な点としては、ホストA(マスターホスト)はホストE(スレーブホスト)の状態は知らなくても良いということです。このシナリオでは単純にその必要はありません。もちろん、ホストAからホストEの監視を行いたければやってもかまいませんが、冗長構成にはなんの影響も与えません…。

===イベントハンドラコマンド定義 Event Handler Command Definitions===
スレーブホスト上に次のようなイベントハンドラをコマンド定義に記述するためちょっと時間を割く必要があります。次に例を挙げます・・・。
<pre>
define command{

command_name handle-master-host-event

command_line /usr/local/nagios/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$

}

define command{

command_name handle-master-proc-event

command_line /usr/local/nagios/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$

}
</pre>

イベントハンドラスクリプトを/usr/local/nagios/libexec/eventhandlersディレクトリに置くという前提になっています。置き場所はどこでも好きなところで結構ですが、この例をちょっと修正する必要があります。

===イベントハンドラスクリプト Event Handler Scripts===
それでは、イベントハンドラスクリプトがどんなものか見ていきましょう・・・。

ホストイベントハンドラ (handle-master-host-event):

<pre>
#!/bin/sh

# Only take action on hard host states...

case "$2" in

HARD)

case "$1" in

DOWN)

# The master host has gone down!

# We should now become the master host and take

# over the responsibilities of monitoring the

# network, so enable notifications...

/usr/local/nagios/libexec/eventhandlers/enable_notifications

;;

UP)

# The master host has recovered!

# We should go back to being the slave host and

# let the master host do the monitoring, so

# disable notifications...

/usr/local/nagios/libexec/eventhandlers/disable_notifications

;;

esac

;;

esac

exit 0
</pre>

サービスイベントハンドラ (handle-master-proc-event):

<pre>
#!/bin/sh

# Only take action on hard service states...

case "$2" in

HARD)

case "$1" in

CRITICAL)

# The master Nagios process is not running!

# We should now become the master host and

# take over the responsibility of monitoring

# the network, so enable notifications...

/usr/local/nagios/libexec/eventhandlers/enable_notifications

;;

WARNING)

UNKNOWN)

# The master Nagios process may or may not

# be running.. We won't do anything here, but

# to be on the safe side you may decide you

# want the slave host to become the master in

# these situations...

;;

OK)

# The master Nagios process running again!

# We should go back to being the slave host,

# so disable notifications...

/usr/local/nagios/libexec/eventhandlers/disable_notifications

;;

esac

;;

esac

exit 0

</pre>

=== これらがもたらすもの What This Does For Us===
初期状態ではスレーブホスト(ホストE)の通知が無効であるため、マスターホスト(ホストA)のNagiosプロセスが有効である間はどんなホスト、サービス通知も発しません。

スレーブホスト(ホストE)のNagiosプロセスはマスターホストが次のようになったときに有効になります・・・

*マスターホスト(ホストA)がダウンしhandle-master-host-event が実行された時。
*マスターホスト(ホストA)のNagiosプロセスが停止し、handle-master-proc-eventサービスイベントハンドラが実行された時。

スレーブホスト(ホストE)のNagiosプロセスの通知が有効になるため、サービスやホストの障害・復旧時に通知が送られるようになります。この時点で、ホストEがホストやサービスの通知設定を引き継いだということになります!

ホストEのNagiosプロセスが再度スレーブホストに戻る時は次の時です・・・。
*ホストAが復旧し、handle-master-host-eventホストイベントハンドラが実行された時。
*ホストAのNagiosプロセスが復旧し、handle-master-host-event が実行された時。

ホストEのNagiosプロセスの通知が無効になるためサービスやホストの障害・復旧通知は送られなくなります。この段階で、ホストEはホストAに通知を送る権限を受け渡したと言うことになります。すべてが最初の状態に戻ったということになります。

=== タイムラグ Time Lags===
Nagiosの冗長化は決して完璧ではありません。その問題の１つに、マスターホストが停止してスレーブホストに移行するまでのタイムラグが挙げられます。このタイムラグは次の事柄の際に発生します・・・。

*マスターホストが停止し、スレーブホストが初めて問題を検出するまでの時間
*マスターホストで本当に障害発生したか検証するに必要な時間(スレーブホストがサービスやホストチェックを再試行している時間)
*イベントハンドラの実行と次のNagiosからの外部コマンドのチェックまでの間の時間

これらのタイムラグを最小限に抑えるには・・・
*ホストEのNagiosプロセス(再)チェックを1回にするか、もっと頻繁に行う設定にする。この設定はサービス定義のcheck_intervalとretry_intervalオプションで行います。
*ホストAのホスト障害検知を早くするために(ホストE)上でホストAのホストチェック回数を設定する。これはホスト定義のmax_check_attempts引数で設定します。
*ホストE上の外部コマンドチェックの頻度をあげる。これはメイン設定ファイルのcommand_check_intervalオプションで設定します。

ホストAのNagiosが復旧した時、つまり、ホストEがスレーブホストに戻る前に同様のラグが生じます。このラグは次に影響されます・・。
*ホストAの復旧とホストEのNagiosプロセスがホストAの復旧を検知するのにかかる時間。
*ホストBのイベントハンドラが実行され、ホストEのNagiosプロセスが次に外部コマンドをチェックする間の時間。

Nagiosが監視権限を移行する際の実際のタイムラグは定義したサービスの数に依存しています(サービスチェック間隔や偶然性など)。とにかく、まったく冗長が無いよりはましでしょう。

===特殊なケース Special Cases===
ここで一つ知っておくべき事を挙げます・・・。もしホストAがダウンした場合、ホストEは障害通知を有効にし、通知を送る責任を引き継ぎます。ホストAが復旧した時、ホストEは通知が無効になります。もし、- ホストAが復旧した時で - ホストAのNagiosプロセスが適切に起動しなかったら、どちらのホストも通知が有効にならない時間ができるでしょう！幸い、Nagiosのサービスチェックロジックはこの現象について解決できます。次に、ホストEのNagiosプロセスがホストAのNagiosプロセスをチェックする際にホストAのNagiosプロセスが稼働していないことを検知するでしょう。ホストEは再度通知を有効にし、通知先に通知を送るよう設定します。

どちらのホストもネットワークを監視していない正確な時間を測定するのは難しいです。監視していない時間を極力短くすることは(ホストE上で)ホストAの Nagiosプロセスを監視する頻度を増やすことで極力短くすることで可能であることは明白です。あと考えられるのは単純な偶然によるものですが、この" ブラックアウト"した合計時間をあまり気にしてはいけません。

== シナリオ2 - 監視のフェイルオーバー化 (Scenario 2 - Failover Monitoring) ==
===導入 Introduction===
監視のフェイルオーバー化も(上のシナリオ1)で述べた)監視の冗長化とよく似ていますが、わずかに異なります。

===目的 Goals===
監視のフェイルオーバー化の基本的な目的は、マスターホストのNagiosプロセスが稼働している際は、スレーブホストのNagiosプロセスはアイドル状態にしておく事にあります。マスターホストのプロセスが(ホストダウンなどで)停止した場合に、スレーブホストが監視を開始するようにするということです。

シナリオ1で述べた、マスター監視ホストがダウンした場合、通知設定を引き継ぐやり方にはいくつかの落とし穴があります。その最大の問題点は、マスターと同じ時間に同じホストやサービスをスレーブホストが監視していると言うことです！これはもし多数のサービスを定義していたら過度のトラフィックや負荷を引き起こす原因になる可能性があります。これからその問題をどのように回避するか説明します・・・。

=== 初期プログラム設定 Initial Program Settings===
スレーブホストの[http://nagios.sourceforge.net/docs/3_0/configmain.html#execute_service_checks execute_service_checks]と[http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_notifications enable_notifications]ディレクティブでアクティブチェックと通知を無効にします。これによりマスターホストが稼働しNagiosプロセスが実行されている間はスレーブホストから監視や通知を行わなくなります。スレーブホストでは [http://nagios.sourceforge.net/docs/3_0/configmain.html#check_external_commands check_external_commands]ディレクティブを有効にしているか確認するのを忘れないようにしてください。

=== マスタープロセスチェック Master Process Check===
スレーブホスト上でマスターホストのNagiosプロセスをチェックするスクリプトをcronジョブとしてもっとも頻繁に(1分毎)に設定します(マスターのNagiosプロセスの監視にはマスターホストで[[Nagios アドオン#NRPE|nrpeデーモン]]とcheck_nagiosを使いスレーブホストでcheck_nrpeプラグインを走らせます)。そのスクリプトはcheck_nrpeプラグインから帰ってくるリターンコードをチェックします。もしリターンコードがnon-OKステートなら、そのスクリプトが[http://nagios.sourceforge.net/docs/3_0/configmain.html#command_file 外部コマンドファイル]に通知とアクティブサービスチェックを有効にするように書き込みます。もしプラグインがOKステートを返したなら、そのスクリプトは外部コマンドファイルに通知とアクティブチェックを無効にするよう書き込みます。

このように行うことで、一度のサービス・ホスト監視に1つのプロセスだけがチェックすることになり、すべてを2回行うより遙かに効率的です。

同じく注意して欲しいのは、シナリオ1で述べたホストとサービスのハンドラを定義してはいけない事です。なぜならこれらは異なるやり方だからです。

===さらなる議論 Additional Issues===
ここでは、非常に基本的な監視のフェイルオーバー化を実装しました。しかしながら、事態をスムーズに行うために考慮すべき点が1つあります。

これまでの設定方法での最大の問題点は監視を引き継ぐ際に現在のホスト･サービスの状態は引き継がない点にあります。この問題を解決する1つの方法としてはマスターホストで[http://nagios.sourceforge.net/docs/3_0/configmain.html#ocsp_command ocspコマンド]を有効にし、[[Nagios アドオン#NSCA|nscaアドオン]]を使いスレーブホストへサービスチェックの結果を送る方法があります。これによりスレーブホストは常に最新の監視ステータスを持つことが可能になります。スレーブホスト上ではアクティブサービスチェックが無効になっているので、どんなサービスチェックも実行されません。しかし、必要ならホストチェックしましょう。これはマスターとスレーブのホストチェックが必要だという事を意味し、監視の大部分はサービスチェックなのでたいした影響はありません。

設定に関してはこれぐらいで十分でしょう。

予測依存チェック

2010-09-03T01:13:44Z

Wikiadmin: ページの作成: == 導入 Introduction== ホストとサービスの依存は、いつチェックされるか、いつ通知が出されるかを定めることができあなたにより大き…

== 導入 Introduction==
ホストとサービスの依存は、いつチェックされるか、いつ通知が出されるかを定めることができあなたにより大きな制御を可能としてくれます。
依存がモニタリングプロセスを制御するのにつかわれる際にできるだけ最新のステータス情報であることは重要です。

Nagiosはホストとサービスのための予測依存チェックが依存ロジックには通知を出すべきであるか、ホストかサービスのアクティブチェックを許可すべきかどうかについての決定をするとき、最新のステータス情報であることを保証してくれます。

== 予測チェックはどう動く? How Do Predictive Checks Work?==
下記の図はホストの親子関係と依存に加えて、Nagiosによってモニターされているホストの基本的な図を示します。

Switch2はこの例でちょうどOKからCRITICALに変わりました。NagiosはホストがDOWNかUNREACHABLEであるかどうかについて決定する必要があるのでそれはSwitch2に近い親ノード(Firewall1)と子ノード(Comp1, Comp2, and Switch3)の平行したチェックを開始します。これはホスト到達可能性ロジックの通常の機能です。

Switch2またはMonitor1とFile1の通知やチェックのどちらに依存しているか(どちらかはこの例では重要ではない)もチェックします。
依存がチェックする前兆となるホストが使用可能にされるならば、それがSwitch2の近い親ノードと子ノードのチェックを開始すると同時に、NagiosはMonitor1とFile1の平行したチェックを開始します
Nagiosは近い将来、（例えば通知の目的のために）依存ロジックをテストしなければならないことを知っているので、依存に参加するホストのために最も多くの現状情報があることを確認したい。

予測チェックがどう動くかということです。簡単でしょ？

予測サービス依存チェックはホストの代わりにサービスを扱う場合を除いて、上で説明されたのと同じように動きます。

[[ファイル:Predictive-dependency-checks.png]]

== 予測チェックを許可 Enabling Predictive Checks ==
前兆となる依存チェックはむしろオーバヘッドを含むので、許可にするように勧めます。
ほとんどの場合、依存ロジックのため正確な情報を持つメリットはこれらのチェックで使われるよけいなオーバーヘッドより価値があるのです。

予測依存チェックを許可するのは簡単です:
*予測ホスト依存チェックは、enable_predictive_host_dependency_check オプションで制御されます
*予測サービス依存チェックがenable_predictive_service_dependency_checks オプションで制御されます

==キャッシュしたチェック==
予測依存チェックはオンデマンドのチェックなので、キャッシュチェックの原則になりやすいです。
Nagiosを騙してホストやサービスのチェックを行う代わりに比較的最近のチェック結果を返すキャッシュ・チェックは性能の改善がはかれます。
[http://nagios.sourceforge.net/docs/3_0/cachedchecks.html ここで]キャッシュされたチェックに関する詳しい情報を見つけることができます。

カスタム CGI ヘッダおよびフッタ

2010-09-03T01:04:30Z

Wikiadmin: ページの作成: == 導入 Introduction== あなたが、クライアントのためにNagiosのカスタムインストールをするなら、あなたは[http://nagios.sourceforge.net/docs/3_0…

== 導入 Introduction==
あなたが、クライアントのためにNagiosのカスタムインストールをするなら、あなたは[http://nagios.sourceforge.net/docs/3_0/cgis.html CGIs]の出力でカスタムヘッダー、そして/またはフッターを表示して欲しいかも知れません。これは特にサポート問い合わせ先などをエンドユーザに表示するための役に立ちます。

それらが実行可能でない場合、それらを表示する前に、いかなる方法でもカスタムヘッダーとフッターファイルを前処理しないよう注意するのは、重要です。ファイルを含むヘッダー・フッターは、CGI出力において、簡単に中身を読んで、表示します。それは、ウェブブラウザが理解できる情報(HTML、JavaScriptなど)を含むことが出来るのみであることを意味します。

カスタムヘッダー・フッターファイルが実行可能であるなら、それらのファイルが実行されて、それらの出力がユーザに戻ったので、それらは有効なHTMLを出力するべきです。これを使用して、あなたは、nagiosディスプレイにデータを挿入するためにあなた自身のカスタム設計されたCGIを実行できます。これは、rrdtoolからddrawとコマンドメニューをnagiosディスプレイ枠に使用することでグラフを挿入するのに使用されました。実行可能な顧客ヘッダー・フッターファイルは主なnagios CGIと同じCGI環境と共に実行されます。それで、あなたのファイルは、適切な出力を産み出すためにクエリ情報、認証されたユーザー情報などを分析できます。

== それはどのように働きますか? How Does It Work?==
あなたは、CGIの出力でNagios HTMLディレクトリ(すなわち/usr/local/nagios/share/ssi) のssi/サブディレクトリでいくつかの適切に指定されたHTMLファイルを落とすことによって、カスタムヘッダーとフッターを含むことができます。

カスタムヘッダーは、CGI出力における<BODY>>タグの直後に入っており、カスタムフッターは、lt; /BODYとgt;タグの直前に入っている。

2つのタイプのカスタムヘッダーとフッターがあります:

*グローバルヘッダー/フッター。これらのファイルはそれぞれ common-header.ssi と common-footer.ssiと命名されます。これらのファイルがあると、全てのCGIの出力に含まれるでしょう。
*CGI特有のヘッダー/フッター。CGINAMEが.cgi拡張子のないCGIの物理的な名前である場所では、これらのファイルはCGINAME-header.ssiとCGINAME-footer.ssiフォーマットと命名されます。例えば[http://nagios.sourceforge.net/docs/3_0/cgis.html#summary_cgi alert summary CGI] (summary.cgi)のためのヘッダーとフッターファイルは summary-header.ssi と summary-footer.ssiと命名される。

あなたはどんなカスタムヘッダーやフッターも使用する必要はありません。あなたは言わばグローバルな、ヘッダーしか使用できません。あなたは言わば、CGI特有のヘッダーとグローバルなフッターだけを使用できます。あなたが欲しいことなら何でも。本当に。

Nagoistasユーティリティ

2010-09-03T00:02:23Z

Wikiadmin: /* 人間が読み込める出力 */

== 導入　Introduction==
nagiostatsと呼ばれるユーティリティは、Nagiosディストリビューションに含まれています。それは、主なNagiosデーモンと共にコンパイルされて、インストールされます。 nagiostatsユーティリティは、あなたに[[Nagiosのパフォーマンスを最適化する]] に非常に役立つ場合がある、実行しているNagiosプロセスの様々な情報を得させてくれます。あなたは人間が読み込める、またはMRTGと互換性のあるフォーマットで情報を得ることができます。

== 使用情報 ==
あなたは、使用情報を得る事が出来るnagiostatsユーティリティを--helpオプションと共に実行出来ます。

== 確認するためのコマンド ==
Nagiosプロセスの実行に関する人間が読み取れる情報を得ます、実行しているNagiosプロセスの性能に関する、人間が読み込める情報を得るには、あなたのメインの構成ファイルの場所を指定するために -cコマンドライン議論でnagiostatsユーティリティを実行して下さい。下記のように： Nagiosプロセスの実行に関する人間が読み取れる情報を得ます、実行しているNagiosプロセスの性能に関する、人間が読み込める情報を得るには、あなたのメインの構成ファイルの場所を指定するために -cコマンドライン議論でnagiostatsユーティリティを実行して下さい。下記のように：

<pre>
[nagios@lanman ~]# /usr/local/nagios/bin/nagiostats -c /usr/local/nagios/etc/nagios.cfg

Nagios Stats 3.0prealpha-05202006

Copyright (c) 2003-2007 Ethan Galstad (www.nagios.org)

Last Modified: 05-20-2006

License: GPL

CURRENT STATUS DATA

------------------------------------------------------

Status File: /usr/local/nagios/var/status.dat

Status File Age: 0d 0h 0m 9s

Status File Version: 3.0prealpha-05202006

Program Running Time: 0d 5h 20m 39s

Nagios PID: 10119

Used/High/Total Command Buffers: 0 / 0 / 64

Used/High/Total Check Result Buffers: 0 / 7 / 512

Total Services: 95

Services Checked: 94

Services Scheduled: 91

Services Actively Checked: 94

Services Passively Checked: 1

Total Service State Change: 0.000 / 78.950 / 1.026 %

Active Service Latency: 0.000 / 4.272 / 0.561 sec

Active Service Execution Time: 0.000 / 60.007 / 2.066 sec

Active Service State Change: 0.000 / 78.950 / 1.037 %

Active Services Last 1/5/15/60 min: 4 / 68 / 91 / 91

Passive Service State Change: 0.000 / 0.000 / 0.000 %

Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0

Services Ok/Warn/Unk/Crit: 58 / 16 / 0 / 21

Services Flapping: 1

Services In Downtime: 0

Total Hosts: 24

Hosts Checked: 24

Hosts Scheduled: 24

Hosts Actively Checked: 24

Host Passively Checked: 0

Total Host State Change: 0.000 / 9.210 / 0.384 %

Active Host Latency: 0.000 / 0.446 / 0.219 sec

Active Host Execution Time: 1.019 / 10.034 / 2.764 sec

Active Host State Change: 0.000 / 9.210 / 0.384 %

Active Hosts Last 1/5/15/60 min: 5 / 22 / 24 / 24

Passive Host State Change: 0.000 / 0.000 / 0.000 %

Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0

Hosts Up/Down/Unreach: 18 / 4 / 2

Hosts Flapping: 0

Hosts In Downtime: 0

Active Host Checks Last 1/5/15 min: 9 / 52 / 164

Scheduled: 4 / 23 / 75

On-demand: 3 / 23 / 69

Cached: 2 / 6 / 20

Passive Host Checks Last 1/5/15 min: 0 / 0 / 0

Active Service Checks Last 1/5/15 min: 9 / 80 / 244

Scheduled: 9 / 80 / 244

On-demand: 0 / 0 / 0

Cached: 0 / 0 / 0

Passive Service Checks Last 1/5/15 min: 0 / 0 / 0

External Commands Last 1/5/15 min: 0 / 0 / 0

[nagios@lanman ~]#

</pre>

お分かりのように、そのユーティリティはNagiosのプロセスに関係する多くの異なった測定基準を表わします。多様な値を持っている測定基準が、(別の方法で指定されない場合)その特定の測定基準のための最小限、最大限、そして平均の値になります。

== MRTG統合 ==
あなたは、MRTG(または、他の互換性のあるプログラム)を使用し、様々なNagios測定基準を表示するためにnagiostatsユーティリティを使用できます。そうするには、--mrtgと--data議論を使用し、nagiostatsユーティリティを実行してください。 --data議論は、どんな統計がグラフで表されるべきであるかを指定するのに使用されます。 --data議論のための可能な値は、--helpオプションと共にnagiostatsユーティリティを実行することによって見つけることが出来ます。

[[ファイル:Hint.gif|bottom]]注意: Nagiosのパフォーマンスの統計に関するMRTGグラフを発生させるのにnagiostatsユーティリティを使用することに関する情報は、[http://nagios.sourceforge.net/docs/3_0/mrtggraphs.html ここ]で見つけることができます。

Nagiosの設定を検証する

2010-09-02T23:50:07Z

Wikiadmin: ページの作成: == Nagiosの設定を検証する　Verifying your configuration== [http://nagios.sourceforge.net/docs/3_0/config.html 設定ファイル]を変更した際に、毎回設定フ…

== Nagiosの設定を検証する　Verifying your configuration==
[http://nagios.sourceforge.net/docs/3_0/config.html 設定ファイル]を変更した際に、毎回設定ファイルが正しいかチェックすることが望ましいです。設定にエラーが含まれているとNagiosが正しく起動しませんので、Nagiosを再起動させる前に設定をチェックすることが重要です。

Nagiosの設定が正しいか確認するためには、以下のように-vオプションを付けてNagiosを実行します。

<pre>
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
</pre>

幾つかの重要なデータを入力するのを忘れたり、設定ミスをすると、Nagiosは問題のある行数を特定するエラーメッセージや警告メッセージを出します。一般に、エラーメッセージは問題の元と思える設定ファイルの行番号を表示します。エラーが出る際、Nagiosはpre-flightチェックを行い、見つかった最初の1行のエラーだけを出してプロンプトに戻る事があります。これをすることで一つのエラーが雪崩の様に残りの設定ファイルの検査で多くのエラーを出さない様になります。もし、何かエラーメッセージが出たら、問題を修正するために設定ファイルを編集する必要があります。Warningのメッセージに関しては、それらが要件ではなく推奨にすぎないので、大抵の場合無視できます。

設定ファイルの確認後、全てのエラーを修正してから[http://nagios.sourceforge.net/docs/3_0/startstop.html Nagiosを(再)起動]すればよいでしょう。

導入ガイド

2010-09-02T23:44:42Z

Wikiadmin:

== Nagiosについて About Nagios==
Nagiosに関する特徴、能力、および技術仕様書を含む、より詳しい情報のために[http://www.nagios.org/about/ www.nagios.org/about/]を訪問してください。

== インストールの初めに　Installation Introduction==
これらのクイックスタートガイドは、ソース(コード)からNagiosをインストールして、20分以内でローカルマシンを監視を行う方法に関する簡単な指示をあなたに提供することを意図します。ここでどんな高度なインストールオプションについても議論しません - まさに始めたがっている95%のユーザのために働く基礎になります。

== 導入ガイド Installation Guides ==
導入ガイドは現在、以下のリナックスディストリビューションに利用可能です。:

*Fedora Quickstart
*openSUSE Quickstart
*Ubuntu Quickstart

また、あなたはNagiosウィキコミュニティ上に、追加の導入ガイドを見つけることができます。あなたの特定のOSに関して導入ガイドを見つけることができませんか? 1つを書いてください、そして、他の人のためにwikiにそれを書いてください!

上に記載されていないオペレーティングシステムまたはリナックスディストリビューションにNagiosをインストールしているなら、あなたがせねばならない事に関する概要のために[http://nagios.sourceforge.net/docs/3_0/quickstart-fedora.html　Fedora導入ガイド]を読んでください。コマンド名、パスなど、異なったOS/ディストリビューションにまたがって、ばらつきが大きいので、あなたは、おそらくあなたの特定のケースのために働くためにインストールドキュメントを少し引っ張る必要があるでしょう。

== ポストインストール変更 Post-Installation Modifications ==
あなたは一度、Nagiosをインストールさせ適切に動かすと、間違いなくローカルマシン以上の監視を始めたくなるでしょう。他のものを監視しながらどう動き回るかために、以下のドキュメントを調べてください…

* [[Windowsマシンの監視]]
* [[Linux/Unixマシンの監視]]
* [[Netware serverの監視]]
* [[ルータとスイッチの監視]]
* [[ネットワークプリンタの監視]]
* [[基本的なサービスの監視]] (HTTP,FTP,SSHなど)

== アドオンコミュニティとNagiosを充実させる Enhance Nagios With Community Addons==
何百ものコミュニティによって開発されたアドオンが、Nagiosのための追加GUIsとレポート、監視、および通知の機能を提供します。 [http://exchange.nagios.org/ exchange.nagios.org]でNagios Exchangeウェブサイトを見て、あなたのNagiosインストールを飾り立てるのに使用できるいくつかの本当に掛け値なしのものを見てください。

== Nagiosサポート・ポータル Nagios Support Portal==
追加のドキュメンテーション、FAQ、およびプロフェッショナルなNagiosサポートプランのために[http://support.nagios.com/ support.nagios.com]でNagiosサポート・ポータルを訪問してください。

<hr>
NagiosとNagiosのロゴは、[http://www.nagios.com/ Nagiosエンタープライズ]のトレードマーク、サービスマーク、登録されたサービスマークまたは登録されたトレードマークです。

クイックインストール

2010-09-02T23:43:48Z

Wikiadmin: ページの作成: == Nagiosについて About Nagios== Nagiosに関する特徴、能力、および技術仕様書を含む、より詳しい情報のために[http://www.nagios.org/about/ www.na…

オブジェクト定義の為の時間節約法

2010-09-02T16:29:46Z

Wikiadmin: /* 複数のホスト */

あるいは…「正気を保つ方法」

== 序論 ==

このドキュメンテーションは、どういった[[オブジェクト定義|テンプレートベースのオブジェクト定義]] があなたの正気を保つ手助けとなるのか、それらの隠された特徴をいくつか説明したいと思います。あなたはなにが手助けとなる思いますか? あなたはいくつかのオブジェクト定義において複数のホスト名、または、ホストグループ名を指定した時、あなたは複数のホストかサービスにオブジェクト定義をコピーをすることが出来ます。私はこれらによる様々なサポートが各タイプのオブジェクトをカバーすると思っています。手初めに、どのオブジェクトタイプが、表題のオブジェクト定義のための時間節約術をサポートするのかを以下に示します:

* [[#.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9.E5.AE.9A.E7.BE.A9|サービス]]
* [[#.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9.E3.82.A8.E3.82.B9.E3.82.AB.E3.83.AC.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3.E5.AE.9A.E7.BE.A9|サービスエスカレーション]]
* [[#.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9.E4.BE.9D.E5.AD.98.E5.AE.9A.E7.BE.A9|サービス依存]]
* [[#.E3.83.9B.E3.82.B9.E3.83.88.E3.82.A8.E3.82.B9.E3.82.AB.E3.83.AC.E3.83.BC.E3.82.B7.E3.83.A7.E3.83.B3.E5.AE.9A.E7.BE.A9|ホストエスカレーション]]
* [[#.E3.83.9B.E3.82.B9.E3.83.88.E4.BE.9D.E5.AD.98.E5.AE.9A.E7.BE.A9|ホスト依存]]
* [[#.E3.83.9B.E3.82.B9.E3.83.88.E3.82.B0.E3.83.AB.E3.83.BC.E3.83.97|ホストグループ]]

上に記載されていないオブジェクト・タイプ(すなわち、timeperiods、commandsなど)は私が説明しようとしている特徴をサポートしません。

== 正規表現マッチング ==
私が以下に出す例がオブジェクト名の"標準"マッチングです。そして、 [[use_regexp_matching]]を'''無効化'''してください。

言うなれば、[[use_regexp_matching]]コンフィグオプションを使用することによってオブジェクト名のために適切な正規表現をの使用が可能になります。デフォルトでの正規表現マッチングは*, ?, +, または\.を含むオブジェクト名に限られます。正規表現をすべてのオブジェクト名で使用したいなら、use_true_regexp_matchingコンフィグオプションを使用可能にしてください。例えば(ホスト名、ホストグループ名、サービス名、およびサービスグループ名)などでも正規表現を使用できます。

注意: 正規表現マッチングを使用可にするときには注意してください--あなたはコンフィグファイルを変更しなければならないかもしれません、正規表現としてあなたが解釈したくない指示まで含めてしまう可能性があります! あなたはいったん設定について確かめ、問題がないか確認するべきです。

== サービス定義 ==

=== 複数のホスト ===

複数のホストに同じ[[サービス定義|サービス]]を割り当てたいなら、あなたは「ホストネーム」という指示で複数のホストを指定できます。以下での定義はHOST1から HOSTNをSOMESERVICEと呼ばれるサービスに設定します。すべてSOMESERVICEサービスが設定されたインスタンスとなります。 (つまり、同じチェックコマンド、最大チェック設定、通知の待ち期間などが設定されます。)

define service{

host_name HOST1,HOST2,HOST3,...,HOSTN

service_description SOMESERVICE

''他のサービスディレクティブ ...''

}

=== 複数のホストグループのすべてのホスト ===

1ホストグループのすべてのホストに同じサービスを割り当てたいなら、あなたは、一つのサービス定義を作成すればよいのです。どのようにするかというと、 hostgroup_nameで、サービスを設定する為の1ホストグループの名前を指定できます。以下での定義はホストグループ HOSTGROUP1からHOSTGROUPNのメンバーであるすべてのホストにSOMESERVICEと呼ばれるサービスが設定されます。例ではすべてのホストグループにSOMESERVICEサービスが設定されています(つまり、同じチェックコマンド、最大チェック設定、通知の待ち期間などが設定されます。)

define service{

hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN

service_description SOMESERVICE

''他のサービスディレクティブ ...''

}

=== すべてのホスト ===

あなたの設定ファイルで定義されるすべてのホストへ同じサービスを割り当てたいなら、あなたはhost_nameでワイルドカードを使用すればよいのです。以下での定義によりあなたの設定ファイルで定義される'''すべてのホスト'''へSOMESERVICEと呼ばれるサービスを割り当てることが出来ます。すべてSOMESERVICEサービスが設定されたインスタンスとなります。 (つまり、同じチェックコマンド、最大チェック設定、通知の待ち期間などが設定されます。)

define service{

host_name *

service_description SOMESERVICE

''他のサービスディレクティブ ...''

}

=== ホストの除外 ===

あなたが多数のホストおよびホストグループに同じサービスを設定し、何人かのホストを定義に入れないようにしたいなら、「！」という文字を行頭へ入力します。

define service{

host_name HOST1,HOST2,!HOST3,!HOST4,...,HOSTN

hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN

service_description SOMESERVICE

''他のサービスディレクティブ ...''

}



== サービスエスカレーション定義 ==

=== 複数のホスト ===
複数のホストに割り当てられる同じ名前/記述のサービスのための[[サービスエスカレーション定義|サービスエスカレーション]] を作成したいなら、あなたはhost_name設定で複数のホストを指定できます。以下での定義はHOSTNを通してSOMESERVICEと呼ばれる、サービスのためのサービスエスカレーションをホストHOST1に作成するでしょう。サービスエスカレーションのすべての例が同じでしょう(すなわち、同じコンタクトグループ、通知間隔などを持つ)。

define serviceescalation{

host_name HOST1,HOST2,HOST3,...,HOSTN

service_description SOMESERVICE

''他のエスカレーションディレクティブ ...''

}

=== 複数のホストグループのすべてのホスト ===
もし、ひとつ以上のホストグループにおける全てのホストに割り当てられる同じ名前/説明のサービスのためのサービスエスカレーションを作成したいのなら、あなたはhostgroup_nameの設定を使用できます。以下での定義は、HOSTGROUPNを通してのhostgroups HOSTGROUP1のメンバーであるすべてのホストのSOMESERVICEと呼ばれているサービスのために、サービスエスカレーションをつくります。サービスエスカレーションのすべての例は、同一です（すなわち、同じコンタクトグループ、通知間隔などを持つ）。

define serviceescalation{

hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN

service_description SOMESERVICE

''他のエスカレーションディレクティブ ...''

}

=== 全てのホスト ===

あなたが、あなたの構成ファイルで定義されるすべてのホストに割り当てられる同じ名前/説明のサービスのために同一のサービスエスカレーションを作成したいのなら、あなたは、host_nameの設定で、ワイルドカードを使うことができます。以下での定義は、あなたの構成ファイルで定められる'''全てのホスト'''のSOMESERVICEと呼ばれているすべてのサービスのために、サービスエスカレーションを作成します。サービスエスカレーションのすべての例は、同一です（すなわち、同じコンタクトグループ、通知間隔などを持つ）。

define serviceescalation{

host_name *

service_description SOMESERVICE

''他のエスカレーションディレクティブ ...''

}

=== ホストの除外 ===
あなたが多数のホストまたはホストグループの上でサービスのために同一のサービスエスカレーションをつくるが、一部のホストを定義から除外したいならば、これは、ホストまたはホストグループに！シンボルが先行することによって果たされます。

define serviceescalation{

host_name HOST1,HOST2,!HOST3,!HOST4,...,HOSTN

hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN

service_description SOMESERVICE

''他のエスカレーションディレクティブ ...''

}

=== 同じホスト上の全てのサービス ===

特定のホストに割り当てられたすべてのサービスのための[[サービスエスカレーション定義|サービスエスカレーション]]を作成したいなら、あなたはservice_description設定ににワイルドカードを使用できます。以下での定義は、ホストHOST1にすべてのサービスのためのサービスエスカレーションを作成します。サービスエスカレーションのすべての例が同じでしょう(すなわち、同じ連絡グループ、通知間隔などを持ってください)。

特に冒険したい気がするなら、あなたはhost_nameとservice_descriptionの設定の両方で、ワイルドカードを指定できます。そうする事で、あなたが構成ファイルで定義したすべての'''サービス'''のためのサービスエスカレーションを作成出来ます。

define serviceescalation{

host_name HOST1

service_description *

''他のエスカレーションディレクティブ ...''

}

=== 複数のサービス上の同じホスト ===

特定のホストに割り当てられたすべての複数サービスのための[[サービスエスカレーション定義|サービスエスカレーション]] を作成したいなら、あなたは、service_description設定における1つ以上のサービス記述を指定する事が出来ます。以下での定義は、ホストHOST1の上でSERVICENを通してサービス SERVICE1のためにサービスエスカレーションを作成します。サービスエスカレーションのすべての例は、同一です（すなわち、同じコンタクトグループ、通知間隔などを持つ）。

define serviceescalation{

host_name HOST1

service_description SERVICE1,SERVICE2,...,SERVICEN

''他のエスカレーションディレクティブ ...''

}

=== 複数のサービスグループでの全てのサービス ===

あなたが一つ以上のサービスグループに属する全てのサービスのためのサービスエスカレーションを作成したいなら、 servicegroup_name設定を使用出来ます。以下での定義は、SERVICEGROUPNを通してサービスグループSERVICEGROUP1のメンバーであるすべてのサービスのためにサービスエスカレーションを作成します。サービスエスカレーションのすべての例は、同一です（すなわち、同じコンタクトグループ、通知間隔などを持つ）。

define serviceescalation{

servicegroup_name SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN

''他のエスカレーションディレクティブ ...''

}



== サービス依存定義 ==

=== 複数のホスト ===

もしも複数のホストに割り当てられる同じ名前/説明のサービスにサービス依存を作りたいならば、host_name and や dependent_host_name ディレクティブで複数のホストを指定することができます。下記の例では、ホストHOST3とHOST4上のサービスSERVICE2はホストHOST1とHOST2のSERVICE1に依存します。全てのサービス依存は、ホスト名を除いて同じです。

define servicedependency{

host_name HOST1,HOST2

service_description SERVICE1

dependent_host_name HOST3,HOST4

dependent_service_description SERVICE2

''他の依存ディレクティブ ...''

}

=== 複数のホストグループの全てのホスト ===

もし1つ以上のホストグループで全てのホストに割り当てられる同じ名前/説明のサービスにサービス依存を作りたいならば、hostgroup_name やdependent_hostgroup_name ディレクティブを使います。下記の例では、ホストグループHOSTGROUP3とHOSTGROUP4の全てのホスト上のサービスSERVICE2 は、ホストグループHOSTGROUP1とHOSTGROUP2の全てのホスト上のサービスSERVICE1に依存します。それぞれのホストグループに５つのホストがあるならば、この定義は100の一つのサービス依存定義をつくるのと等しいでしょう！サービス依存のすべての例は、ホスト名を除いて同じです（すなわち、同じ通知失敗基、他を持ちます）。

define servicedependency{

hostgroup_name HOSTGROUP1,HOSTGROUP2

service_description SERVICE1

dependent_hostgroup_name HOSTGROUP3,HOSTGROUP4

dependent_service_description SERVICE2

''他の依存ディレクティブ ...''

}

=== １つのホスト上のすべてのサービス ===

特定のホストに割り当てられるすべてのサービスのためにサービス依存をつくりたいならば、service_descriptionやdependent_service_description ディレクティブでワイルドカードを使うことができます。下記の例では、ホストHOST2の上のすべてのサービスは、ホストHOST1の上ですべてのサービスに依存しています。サービス依存のすべての例は同じです（すなわち、同じ通知失敗基準、他を持ちます）。

define servicedependency{

host_name HOST1

service_description *

dependent_host_name HOST2

dependent_service_description *

''他の依存ディレクティブ ...''

}

=== １つのホスト上の複数のサービス ===

特定のホストに割り当てられる複数のサービスのためにサービス依存を作りたいならば、以下の通りにservice_descriptionやdependent_service_description ディレクティブで複数のサービス説明を指定することができます：

define servicedependency{

host_name HOST1

service_description SERVICE1,SERVICE2,...,SERVICEN

dependent_host_name HOST2

dependent_service_description SERVICE1,SERVICE2,...,SERVICEN

''他の依存ディレクティブ ...''

}

=== 複数のサービスグループのすべてのサービス ===

一つ以上のサービスグループに入るすべてのサービスのためにサービス依存を作りたいならば、以下の通りにservicegroup_nameやdependent_servicegroup_nameディレクティブを使用することができます：

define servicedependency{

servicegroup_name SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN

dependent_servicegroup_name SERVICEGROUP3,SERVICEGROUP4,...SERVICEGROUPN

''他の依存ディレクティブ ...''

}

=== 同じホスト上での依存 ===

同じホストでサービスに依存している複数のサービスのためにサービス依存をつくりたいならば、dependent_host_nameと dependent_hostgroup_name ディレクティブを空のままにしてください。下記の例では、HOST1とHOST2は少なくともこれら４つのサービスがあります：SERVICE1, SERVICE2, SERVICE3, そして SERVICE4。この例では、HOST1上のSERVICE3とSERVICE4はHOST1上のSERVICE1とSERVICE2の両方に依存します。同じように、HOST2上のSERVICE3とSERVICE4はHOST2上のSERVICE1とSERVICE2の両方に依存します。

define servicedependency{

host_name HOST1,HOST2

service_description SERVICE1,SERVICE2

dependent_service_description SERVICE3,SERVICE4

''他の依存ディレクティブ ...''

}

== ホストエスカレーション定義 ==

=== 複数のホスト ===

複数のホストのためにホストエスカレーションをつくりたいならば、host_name指令で複数のホストを指定することができます。下記の定義は、HOSTNを通してホストHOST1のためのホストエスカレーションをつくります。ホストエスカレーションのすべての例は、同じです（すなわち、同じ接触グループ、通知間隔、他を持つ）。

define hostescalation{

host_name HOST1,HOST2,HOST3,...,HOSTN

''他のエスカレーションディレクティブ ...''

}

=== 複数のホストグループのすべてのホスト ===
一つ以上のホストグループで中ですべてのホストのためにホストエスカレーションをつくりたいならば、hostgroup_name ディレクティブを使用します。下記の定義は、HOSTGROUPNを通してのホストグループ HOSTGROUP1のメンバーであるすべてのホストで、ホストエスカレーションを作ります。ホストエスカレーションのすべての例は、同じです（すなわち、同じ接触グループ、通知間隔、他を持つ）。

define hostescalation{

hostgroup_name HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN

''他のエスカレーションディレクティブ ...''

}

=== 全てのホスト ===

コンフィグレーションファイルで定められるすべてのホストのために同一のホストエスカレーションをつくりたいならば、host_nameディレクティブでワイルドカードを使うことができます。下記の定義は、コンフィグレーションファイルで定められる'''すべてのホスト'''のために、ホストエスカレーションをつくります。ホストエスカレーションのすべての例は、同じです（すなわち、同じ接触グループ、通知間隔、他を持つ）。

define hostescalation{

host_name *

''他のエスカレーションディレクティブ ...''

}

=== 除外ホスト ===

多数のホストまたはホストグループ上で同じホストエスカレーションを作り、一部のホストを定義から除外したいのならば、これは !符号でホストまたはホストグループに先行することによって成し遂げることができます。

define hostescalation{

host_name HOST1,HOST2,!HOST3,!HOST4,...,HOSTN

hostgroup_name HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN

''他のエスカレーションディレクティブ ...''

}

== ホスト依存定義 ==

=== 複数のホスト ===
複数のホストのためにホスト依存を作りたいならば、host_nameやdependent_host_nameディレクティブで複数のホストを指定することができます。下記の定義は、6つの別々のホスト依存をつくることに等しいです。この例では、ホストHOST3、HOST4とHOST5は、HOST1とHOST2に依存しています。ホスト依存のすべての例は、ホスト名（すなわち、同じ通知失敗基準、他を持ちます）を除いて同じです。

define hostdependency{

host_name HOST1,HOST2

dependent_host_name HOST3,HOST4,HOST5

''他の依存ディレクティブ ...''

}

=== 複数のホストグループのすべてのホスト ===
一つ以上のホストグループの中ですべてのホストのためにホストエスカレーションを作りたいならば、hostgroup_nameやdependent_hostgroup_nameディレクティブを使用にすることができます。下記の例で、ホストグループHOSTGROUP3とHOSTGROUP4のすべてのホストは、hostgroups HOSTGROUP1とHOSTGROUP2ですべてのホストに依存しています。ホスト依存のすべての例は、ホスト名（すなわち、同じ通知失敗基準、他を持ちます）を除いて同じです。

define hostdependency{

hostgroup_name HOSTGROUP1,HOSTGROUP2

dependent_hostgroup_name HOSTGROUP3,HOSTGROUP4

''他の依存ディレクティブ ...''

}

== ホストグループ ==

=== 全てのホスト ===
コンフィグレーションファイルでメンバーと定義されるすべてのホストを持っているホストグループを作りたいならば、memberディレクティブでワイルドカードを使うことができます。下記の定義は、コンフィグレーションファイルでメンバーと定義される'''すべてのホスト'''を持っているHOSTGROUP1と呼ばれているホストグループを作ります。

define hostgroup{

hostgroup_name HOSTGROUP1

members *

''他のホストグループディレクティブ ...''

}

メイン設定ファイルのオプション

2010-08-31T05:26:10Z

Wikiadmin: /* 構成ファイル Configuration File Variables */

== 注釈 Notes==
設定ファイルの作成および修正時には以下のことを頭に入れておいてください：
#'#'で始まる行はコメントとして解釈され実際には処理されません。
#設定値は各行の先頭から始めてください - スペースが先頭に入ってはいけません。
#設定値は大文字小文字を区別します。

== サンプル設定ファイル Sample Configuration File ==
[[ファイル:Hint.gif]]サンプルファイルは quickstart installation guideを使用した場合は (/usr/local/nagios/etc/nagios.cfg)にあります。

== コンフィグファイルの場所 Config File Location==
メインの設定ファイルであるnagios.cfgは/usr/local/nagios/etc/ にインストールされています。

== 構成ファイル Configuration File Variables ==
これより下でNagiosを構成する主要なファイルオプションを説明します。

[[構成ファイルのパスの指定]]

[[Nagiosを実行するユーザの設定]]

[[基本監視機能の有効と無効の設定]]

[[外部コマンド機能に関する設定]]

[[自動アップデートのチェック機能に関する設定]]

[[状態自動保存機能に関する設定]]

[[ログ・ロギング機能に関する設定]]

[[イベントハンドラに関する設定]]

[[監視のスケジューリングに関する設定]]

[[高度な監視機能の設定]]

[[Nagiosデーモンのパフォーマンスに関する設定]]

[[フラップ検出機能の設定]]

[[各種タイムアウトの設定]]

[[オブセスオーバサービス機能に関する設定]]

[[パフォーマンスデータ機能に関する設定]]

[[フレッシュネスサービス機能の設定]]

[[その他の設定]]

[[禁止文字列・正規表現に関する設定]]

[[デバッグオプション]]

通知

2010-08-31T05:01:32Z

Wikiadmin: /* 通知タイプマクロ Notification Type Macro */

== 導入 Introduction==
[[ファイル:Objects-contacts.png|right]]
通知が正確に働く方法に関して、多くの質問がありました。ここでは、ホストとサービス通知がいつ、どのように出されるかと、それが受け取られる方法について、できる限り正確に説明します。

通知のエスカレーションについては[http://nagios.sourceforge.net/docs/3_0/escalations.html こちら]です。

== 通知はいつ発生する？ When Do Notifications Occur?==
通知を出すという決定は、サービスチェックとホストチェックロジックでなされます。ホストとサービス通知は、以下のような場合に発生します...
*ステータスがハード状態になった時。ステータスのタイプと状態についてのより詳しい情報は[http://nagios.sourceforge.net/docs/3_0/statetypes.html こちら]です。
*ホストまたはサービスが、最後に通知が出されてから指定された<通知間隔>が経過してもOK以外のステータスだった時(指定されたホストまたはサービスのみ)。

== 誰に通知される？ Who Gets Notified?==
各々のホストとサービス定義には、どの通知先グループがそのホストまたはサービスについての通知を受け取るかを指定する<contact_groups>オプションがあります。通知先グループは、1つ以上の個々のコンタクトを含むことができます。

Nagiosがホストまたはサービス通知を出す場合は、ホストまたはサービス定義の<contactgroups>オプションで指定されている全ての通知先グループの個々を宛先とします。Nagiosは、コンタクトは複数の通知先グループに属しているかもしれないと考え、通知の前に重複するコンタクト情報を除外します。

== 通知を送るために通らなければならないフィルタとは？ What Filters Must Be Passed In Order For Notifications To Be Sent?==
ホストまたはサービス通知を出す必要があるからといって、全ての通知が出されるわけではありません。通知を決定する前に、'潜在的'通知が通過するべきいくつかのフィルタが存在します。フィルタで通知が許可されなければ、ある種の通知はされないかもしれません。ではフィルタの詳細へ進みます…

== プログラム全体のフィルタ: Program-Wide Filter:==
通知がまず通過しなければならないフィルタは、プログラム全体で通知が有効かどうかです。これはメイン設定ファイルの[http://nagios.sourceforge.net/docs/3_0/configmain.html#enable_notifications enable_notifications]ディレクティブで指定されますが、実行中にWebインタフェイスから変更されるかもしれません。通知がプログラム全体で無効になっている場合は、ホストまたはサービス通知を出すことはできません。プログラム全体で通知が有効になっていれば、更に合格すべきテストがあります…

== サービスとホストのフィルタ: Service and Host Filters:==
ホスト又はサービス通知の最初のチェックは、予定された[http://nagios.sourceforge.net/docs/3_0/downtime.html ダウンタイム期間]かどうかです。もし予定されたダウンタイムの期間内なら、通知は行われません。ダウンタイム期間外なら、次のフィルタへ渡され更なるチェックを受けます。傍注:ダウンタイム期間中のホストに関連するサービス通知は抑制されます。

第2のフィルタは、ホスト又はサービスが[http://nagios.sourceforge.net/docs/3_0/flapping.html フラッピング状態]かどうか (フラップ検知を有効にしている場合)です。もしサービス又はホストがフラッピング状態なら、通知は行われません。そうでなければ、更に次のフィルタへ渡されます。

第3のフィルタは、ホスト又はサービス固有のオプションです。各々のサービス定義は、ワーニング状態、クリティカル状態とリカバリ状態に通知を出すかどうか決定できるオプションを持っています。同じように、各々のホスト定義は、ホストがダウンした時、到達不可能になった時、回復した時に、通知を出すかどうか決定できるオプションを持っています。ホスト又はサービス通知がこれらのオプションに当てはまれば、通知は行われません。もし当てはまらなければ、通知は次のフィルタに渡されます... 注: 固有の問題が原因で発生した通知は、ホスト又はサービスの回復時のみ送られます。検知していない問題に対する回復通知は意味をなしません。

4つめのフィルタは通知の発生した時間帯です。各ホスト又はサービス定義には、通知を受け取る時間帯を指定する<notification_period> オプションがあります。通知の発生が指定時間外なら、通知は行われません。指定時間内なら、通知は次のフィルタに渡されます... 注:このフィルタをパスしなかった(つまり通知が行われなかった)場合、Nagiosは次の指定時間帯にホスト又はサービス通知をスケジュールします(もしOK以外のステータスだった場合)。これにより、次の指定時間帯には指定された通知先へ速やかに障害通知が送られます。

最後のフィルタは次の2つからなります: (1)ホスト又はサービスについて、過去に何度か同じ問題で通知を出している。(2)このホスト又はサービスのステータスは、前回の通知時から変化していない。この2つの基準を満たした時、Nagiosは前回の通知から経過した時間がホスト又はサービス定義の<notification_interval>オプションの値を上回っているかチェックします。もし前回の通知からの経過時間が短かった場合には、通知は行われません。前回の通知から十分な時間が経つか、このフィルタの2つの基準を満たした場合に、通知が行われます。しかしこれが実際に通知先へ送られるかどうかは、もう1セットのフィルタ次第です...

== 通知フィルタ:Notification Methods ==
ここにきて、通知はプログラムモードフィルタと全てのホスト又はサービスに渡され、Nagiosは[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#contact 通知されるべき人々]に通知を始めます。各々の通知先は通知を受け取ることになるでしょうか？残念！各通知先にも、受け取られる前に通知が通るべき独自のフィルタセットがあります。注:通知フィルタは、各々の通知先に特有なので、他の通知先には影響を与えません。

通知先毎で通過すべき最初のフィルタは、通知オプションです。各々の通知先定義は、ワーニング状態、クリティカル状態とリカバリ状態にサービス通知を出すかどうか決定できるオプションを持っています。また、ホストがダウンした時、到達不可能になった時、回復した時に、ホスト通知を出すかどうか決定できるオプションも持っています。ホスト又はサービス通知がこれらのオプションに当てはまれば、通知は行われません。もし当てはまらなければ、通知は次のフィルタに渡されます... 注: 固有の問題が原因で発生した通知は、ホスト又はサービスの回復時のみ送られます。検知していない問題に対する回復通知は意味をなしません。

通知先毎で通過すべきの最後のフィルタは、通知時間帯です。各通知先定義には通知を受け取る時間帯を指定する<notification_period> オプションがあります。通知の発生が指定時間外なら、通知は行われません。指定時間内なら、通知が行われます！

== 通知方法 Notification Methods ==
きちんと指定すれば、問題と回復については大抵の方法で通知できます:ポケベル、携帯電話、Eメール、インスタントメッセージ、警告音、電気的振動など。通知方法は、[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#command オブジェクト定義ファイル]の[http://nagios.sourceforge.net/docs/3_0/config.html 通知コマンド]に依存します。

[[ファイル:Note.gif|bottom]]:もし[http://nagios.sourceforge.net/docs/3_0/quickstart.html クイックスタートガイド]に従ってNagiosをインストールしているなら、通知はEメールで送られるようにするべきです。以下のファイルでEメール通知コマンドを見ることができます: /usr/local/nagios/etc/objects/commands.cfg.

特定の通知方法(ページングなど)は、Nagiosに直接取り込まれません。Nagiosの"コア"は、オールインワンアプリケーションではないからです。サービスチェックがNagiosのコアに埋め込まれているなら、ユーザが新しいチェック方法を追加したり既存のチェック方法を修正することは非常に難しくなるでしょう。通知も似たようなものです。既に1000以上の通知方法があり、その多くはパッケージ化されているのに、わざわざ最初から作成しなおす必要があるでしょうか？それは外部実体(即ち単純なスクリプトまたは完全なメッセージシステム)をはるかに乱雑にしてしまうでしょう。ポケベルと携帯電話のための通知を扱えるパッケージは、リソースセクション以下にリストされます。

== 通知タイプマクロ Notification Type Macro==
通知コマンドを作成する場合には、発生している通知のタイプを考慮する必要があります。[http://nagios.sourceforge.net/docs/3_0/macrolist.html#notificationtype $NOTIFICATIONTYPE$]マクロはそれを正確に確認する行を含みます。以下のテーブルに、マクロに設定可能な値とそれらの説明をリストします:

<table border=1>
<tr><th>値</th><th>説明</th></tr>

<tr><td>PROBLEM</td><td>サービス又はホストに問題が発生しました(又は依然として問題が発生し続けています)。サービス通知の場合は、該当のサービスがWARNING・UNKNOWNまたはCRITICALのいずれかに当たることを示します。ホスト通知の場合は、該当のホストがDOWNまたはUNREACHABLEステータスであることを示します。</td></tr>

<tr><td>RECOVERY</td><td>サービス又はホストは、復旧しました。サービス通知の場合は、該当サービスがOKになったことを示し、ホスト通知の場合は該当ホストがUP状態に戻ったことを示します。</td></tr>

<tr><td>ACKNOWLEDGEMENT</td><td>この通知は、ホスト又はサービスの問題を承認するものです。webインタフェースから特定のホスト又はサービスへアクセスすることで開始されます。</td></tr>

<tr><td>FLAPPINGSTART</td><td>ホスト又はサービスは、[http://nagios.sourceforge.net/docs/3_0/flapping.html フラッピング]を開始しました。</td></tr>

<tr><td>FLAPPINGSTOP</td><td>ホスト又はサービスは、[http://nagios.sourceforge.net/docs/3_0/flapping.html フラッピング]を停止しました。</td></tr>

<tr><td>FLAPPINGDISABLED</td><td>ホスト又はサービスは、[http://nagios.sourceforge.net/docs/3_0/flapping.html フラッピング]が使用不可能になったためフラッピングを停止しました。</td></tr>

<tr><td>DOWNTIMESTART</td><td>ホスト又はサービスは、[http://nagios.sourceforge.net/docs/3_0/downtime.html 予定されたダウンタイム]へ入りました。今後の通知は抑止されます。</td></tr>

<tr><td>DOWNTIMESTOP</td><td>ホスト又はサービスは、[http://nagios.sourceforge.net/docs/3_0/downtime.html 予定されたダウンタイム]を抜けました。今後は通知が再開されます。</td></tr>

<tr><td>DOWNTIMECANCELLED</td><td>ホスト又はサービスの[http://nagios.sourceforge.net/docs/3_0/downtime.html 予定されたダウンタイム]は、キャンセルされました。今後も通知は行われます。</td></tr>

</table>

== 使用できるリソース Helpful Resources ==
Nagiosが通知を出すようにするには多くの方法があり、あなたはそのうちのどの方法を使用するか決定できます。通知方法を決定したら、必要なソフトウェアをインストールし、設定ファイルに通知コマンドを設定しなければなりません。2、3の考えられる方法は以下の通りです：

* Eメール
* ポケベル
* 電話(SMS)
* ポップアップウィンドウ
* Yahoo・ICQやMSNのインスタントメッセージ
* アラーム音
* など...

基本的に、コマンドラインから実行できるものは、通知コマンドに合わせて変更できます。

もし、ポケベルか携帯電話に通知を送るためにEメールに代わるものを探しているなら、以下のパッケージをチェックしてください。問題が発生した時に Nagiosと連動してメッセージを送ることが簡単です。あなたは通知を出すのにEメールに頼る必要はありません(しかしネットワークに問題があればうまく働かない可能性はあります)。私自身はこのパッケージを実際に試したわけではありませんが、他の人がこれらを利用してうまくいっていると報告をくれました...

* [http://www.gnokii.org/ Gnokii] (GSMネットワークを利用しノキアの電話へ連絡を入れるためのSMSソフト)
* [http://www.qpage.org/ QuickPage] (英数字ポケベルソフト)
* [http://www.sendpage.org/ Sendpage] (ページングソフト)
* [http://www.smsclient.org/ SMS Client] (ポケベルと携帯電話へメッセージを送るためのコマンドラインユーティリティ)

通知に伝統的"でない"方法を利用したい場合は、アラーム音について色々設定したくなるかも知れません。アラーム音を監視サーバから発したい場合は、[http://www.cstr.ed.ac.uk/projects/festival/ Festival]をチェックしてください。もし監視サーバ以外からアラーム音を発生させたい場合は、[http://radscan.com/nas.html Network Audio System (NAS)]と[http://rplay.doit.org/ rplayプロジェクト]をチェックしてください。

時間帯

2010-08-31T04:42:37Z

Wikiadmin: ページの作成: == 導入 Introduction == [http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#timeperiod 時間帯]定義で、あなたは、監視とアラートロジックの様…

== 導入 Introduction ==
[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#timeperiod 時間帯]定義で、あなたは、監視とアラートロジックの様々な面がいつ作動できるかを制御できます。例えば、あなたは下記を制限する事が出来ます。
[[ファイル:Objects-timeperiods.png|right]]
* 定期的に予定されているホストとサービスチェックをいつ実行出来るか
* 通知をいつ出すことが出来るか
* 通知増大をいつ使用出来るか
* いつ依存が有効であるか

== 時間帯の先行 Precedence in Time Periods==
時間帯[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#timeperiod 定義] は複数のタイプに関する平日、月の何日か、とカレンダ日付も含む設定を含むかも知れません。異なったタイプの設定は、異なった先行レベルを持って、あなたの時間帯定義における他の設定をくつがえすかも知れません。異なったタイプの設定のための先行の順序は(降順に)以下の通りです:

*カレンダーの日付 (2008-01-01)
*特定の月の期日 (January 1st)
*一般的な月の日付 (Day 15)
*特定の月の平日の差引計算 (2nd Tuesday in December)
*差引計算の平日 (3rd Monday)
*普通の平日(Tuesday)

異なった時間帯定義設定の例を[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#timeperiod ここ]で見つけることができます。

== ホスト・サービスチェックでの時間帯の働き方 How Time Periods Work With Host and Service Checks==
ホストとサービス定義には、あなたが定期的に予定された、ホストまたは、サービスのアクティブチェックを出来る時に限定するされるのが常な、時間帯を指定できる任意のcheck_period設定があります。

あなたが時間帯を指定するのにcheck_period設定を使用しないなら Nagiosは、必要である時いつでも、ホストまたはサービスのアクティブチェックのスケジュールを出来るでしょう。これは本質的には24×7の監視シナリオです。

check_period設定で時間帯を指定する事で、あなたは、Nagiosが定期的に予定されている、ホストやサービスのアクティブチェックを実行する時間を制限できます。 Nagiosがホストやサービスのチェックのスケジュール変更を試みる時、それは、次のチェックが定義された時間帯の中の有効な時間の範囲内に置かれる事を確かめます。そうしないならNagiosは、指定された時間帯に次の「有効な」時間と同時に起こる次のチェック時間を調整するでしょう。これは、ホストやサービスが時間、日、または週などの間、再びもうチェックされないかもしれないことを意味します。

[[ファイル:Note.gif|bottom]]Note 注意: オンデマンドチェックとパッシブチェックは、あなたがcheck_period設定で指定する時間帯によって制限されません。定期的にスケジュールされているアクティブチェックだけが制限されます。

あなたにそうしない十分な理由がないなら、私は、あなたが24×7の時間の範囲をカバーする期間を使用する、すべてのホストとサービスを監視することを勧めるでしょう。あなたがこれをしないなら、あなたは「停電」の時(時間帯定義で有効でない時)の間、いくつかの問題に出くわす事があります。

#ホストまたはサービスの状態は、停電の間、変わりがなく見えるでしょう。
#通知先は停電の間、ホストまたはサービスに関する問題の再通知はおそらくほとんどされないでしょう。
#ホストかサービスが停電時間に回復すると、通知先はすぐには回復について通知されないでしょう。

== 通知先通知での時間帯の働き方 How Time Periods Work With Contact Notifications==
ホストまたはサービス定義のnotification_period設定で時間帯を指定することによって、あなたは Nagiosがいつそのホストかサービスのために問題または回復に関して通告を送れるかをコントロール出来ます。ホスト通知を出そうとしているとき、Nagiosは、notification_periodの時間帯の有効枠の中に現在の時間があるのを確かめます。有効な時間であれば、Nagiosは、問題か回復の各通知先に通知を試みるでしょう。

あなたはまた、いつ個々の通知先に通知を出されることができるかを制御するのに時間帯を使用できます。 [http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#contact 通知先]定義における service_notification_periodとhost_notification_periodの設定を使用することで、それぞれの通知先の"on call"を本格的に定義できます。通知先はあなたが通知期間の設定で指定する回の間、ホストとサービス通知を受け取るだけでしょう。

どうやってon callローテーションを使うための時間帯定義を作成するかの例を[http://nagios.sourceforge.net/docs/3_0/oncallrotation.html ここ]で見つけることができます。

== 通知エスカレーションでの時間帯の働き方 How Time Periods Work With Notification Escalations ==
サービスとホストの[http://nagios.sourceforge.net/docs/3_0/escalations.html 通知エスカレーション]は、そのエスカレーションが有効である時に、あなたが時間帯を指定できる任意のescalation_periodの設定を持って、利用できます。あなたがエスカレーション定義におけるescalation_periodの設定を使用しないなら、エスカレーションはいつも有効であると考えられています。あなたがescalation_periodの設定で時間帯を指定すると、Nagiosは時間帯定義で有効な回の間だけ、エスカレーション定義を使用するでしょう。

== 依存での時間帯の働き方 How Time Periods Work With Dependencies==
サービスとホスト[http://nagios.sourceforge.net/docs/3_0/dependencies.html 依存] は、依存が有効であるときにあなたが時間帯を指定できる任意のdependency_periodの設定を持って、利用できます。あなたが依存定義におけるdependency_periodの設定を使用しないなら、いつでもその依存を使用できます。あなたがdependency_periodの設定で時間帯を指定すると、Nagiosは時間帯定義で有効な回の間だけ、依存定義を使用するでしょう。

マクロとその動作についての理解

2010-08-31T04:32:03Z

Wikiadmin: ページの作成: == マクロ Macros== Nagiosがとても柔軟である主要な特徴のひとつにコマンド定義でマクロを使えるという能力があります。マクロはあな…

== マクロ Macros==
Nagiosがとても柔軟である主要な特徴のひとつにコマンド定義でマクロを使えるという能力があります。マクロはあなたのコマンドで、ホスト、サービスやその他のソースからの情報参照を許可します。

== Macroの代替 - マクロの動作 Macro Substitution - How Macros Work==
Nagiosでコマンドを実行する前に、コマンド定義の対応する値を見つけることができれば、それはどんなマクロでも置き換えることができます。このマクロの代替はNagiosが実行する様々なコマンドのタイプで発生します - ホストとサービスチェック、通知、イベントハンドラ、その他。

特定のマクロは他のマクロ自身を含むかもしれません。それらは、 $HOSTNOTES$, $HOSTNOTESURL$, $HOSTACTIONURL$, $SERVICENOTES$, $SERVICENOTESURL$, and $SERVICEACTIONURL$ マクロを含みます。

==例 1: ホストアドレスマクロ Example 1: Host Address Macro ==
コマンド定義でホストとサービスのマクロを使う際、これらはコマンドが実行されているホストかサービスの値を参照します。例を示しましょう。我々はホスト定義を用いて check_ping コマンドを以下のように定義しているとします。

<pre>
define host{

host_name linuxbox

address 192.168.1.2

check_command check_ping

...

}

define command{

command_name check_ping

command_line /usr/local/nagios/libexec/check_ping -H $HOSTADDRESS$ -w 100.0,90% -c 200.0,60%

}
</pre>

ホストチェックの際に展開された/最終的なコマンドラインは以下のようになります。:
<pre>
/usr/local/nagios/libexec/check_ping -H 192.168.1.2 -w 100.0,90% -c 200.0,60%
</pre>

とてもシンプルでしょう? この美しさは、無制限のホストのチェックに、 1つのコマンド定義を使うことができるということです。各々のホストのアドレスが、実行前にコマンドラインに自動的に代入されるので、各々のホストは同じコマンド定義でチェックすることができます

== 例 2: コマンド引数マクロ Example 2: Command Argument Macros ==
あなたはコマンドに引数を持たせることが出来、それはコマンド定義よりむしろ元の形のまま手軽に行えます。引数はオブジェクト定義 (例　ホストやサービス)で指定し、コマンド名からはエクスクラメーションマーク(!)で区切ります:

<pre>
define service{

host_name linuxbox

service_description PING

check_command check_ping!200.0,80%!400.0,40%

...

}
</pre>

上の例では、サービスチェックコマンドに2つの引数を持っています ( [http://nagios.sourceforge.net/docs/3_0/macrolist.html#arg $ARGn$] マクロを参照して下さい)。 $ARG1$ マクロは "200.0,80%" そして $ARG2$ は "400.0,40%" になります(両方ともダブルクォートはありません)。 check_ping コマンド定義より早くホスト定義が以下のようにされているとします:

<pre>
define command{

command_name check_ping

command_line /usr/local/nagios/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$

}
</pre>
展開された/最終的にサービスチェックで実行されるコマンドラインは以下のようになります:
<pre>
/usr/local/nagios/libexec/check_ping -H 192.168.1.2 -w 200.0,80% -c 400.0,40%
</pre>

[[ファイル:Hint.gif|bottom]]豆知識: もし、あなたが、感嘆符 (!) の文字をコマンド引数で用いる必要がある場合、バックスラッシュ (\) でエスケープします。もしあなたが、コマンド引数の中でバックスラッシュを含む必要がある場合、それらもバックスラッシュでエスケープしなくてはいけません

== オンデマンドマクロ On-Demand Macros ==
通常、コマンド定義でホストとサービスのマクロを使う時、コマンドが実行されているホストやサービスの値を参照します。例えば、ホストチェックコマンドが"linuxbox"という名前に対して実行される時、全ての [http://nagios.sourceforge.net/docs/3_0/macrolist.html 基本ホストマクロ] はホスト("linuxbox") の値を参照します。

コマンドの中で別のホストやサービス(コマンドを実行していないホスト)の値を参照したいのであれば、 "オンデマンド"マクロと呼ばれるものを使うことができます。オンデマンドマクロは通常のマクロに見えますが、ホストやサービスが得るべき値を含んでいる事だけが違います。以下にあるのは基本的なオンデマンドマクロのフォーマットです:

*$HOSTMACRONAME:host_name$
*$SERVICEMACRONAME:host_name:service_description$

HOSTMACRONAMEとSERVICEMACRONAMEを[http://nagios.sourceforge.net/docs/3_0/macrolist.html ここで]見つけられる、サービスマクロの標準のホストのひとつの名前に置き替えてください。

マクロ名がコロン(:)によってホストかサービス識別子と分けられる事に注意してください。またオンデマンドサービスマクロのために、サービス識別子がコロン(:)によって分けられたホスト名とサービス記述の両方から成ります。

[[ファイル:Hint.gif|bottom]] On-demand service macros can contain an empty host name field. In this case the name of the host associated with the service will automatically be used.

オンデマンドホストとサービスマクロの例は次の通り:

<pre>
$HOSTDOWNTIME:myhost$ <--- On-demand host macro

$SERVICESTATEID:novellserver:DS Database$ <--- On-demand service macro

$SERVICESTATEID::CPU Load$ <--- On-demand service macro with blank host name field
</pre>

また、オンデマンドマクロもホストグループ、サービスグループ、コンタクトおよびコンタクトグループマクロに利用可能です。例えば:

<pre>
$CONTACTEMAIL:john$ <--- On-demand contact macro

$CONTACTGROUPMEMBERS:linux-admins$ <--- On-demand contactgroup macro

$HOSTGROUPALIAS:linux-servers$ <--- On-demand hostgroup macro

$SERVICEGROUPALIAS:DNS-Cluster$ <--- On-demand servicegroup macro
</pre>

== オンデマンドグループマクロ On-Demand Group Macros ==
あなたは、あなたのオンデマンドマクロ宣言のための特別なフォーマットを使用することによって、特定のグループにおける全てのコンタクト、ホスト、またはサービスのまたがってマクロの値を得ることができます。あなたは以下のように、オンデマンドマクロにおける特定のホストグループ、サービスグループ、またはコンタクトグループ名に参照をつけることによってこれをします。：
*$HOSTMACRONAME:hostgroup_name:delimiter$
*$SERVICEMACRONAME:servicegroup_name:delimiter$
*$CONTACTMACRONAME:contactgroup_name:delimiter$

HOSTMACRONAME、SERVICEMACRONAMEとCONTACTMACRONAMEを、 [http://nagios.sourceforge.net/docs/3_0/macrolist.html ここ]で見つけられる標準のホスト、サービスまたはコンタクトのひとつの名前に置き替えてください。あなたが指定するデリミタは、各グループメンバーのためのマクロ値を切り離すのに使用されます。

例えば、以下のマクロはhg1ホストグループのメンバーであるホストのための、ホスト状態のidのコンマで切り離されたリストを返すでしょう:

<pre>
$HOSTSTATEID:hg1:,$

This macro definition will return something that looks like this:
</pre>
このマクロ定義はこれに似ている何かを返すでしょう:

0,2,1,1,0,0,2

== カスタム可変マクロ Custom Variable Macros ==
Any 「custom object variables」that you define in host, service, or contact definitions are also available as macros. あなたがホスト、サービスまたはコンタクト定義において定義するどんな [http://nagios.sourceforge.net/docs/3_0/customobjectvars.html カスタムオブジェクト変数]もマクロとして利用可能です。カスタム可変マクロは以下の通り指定されます:
*$_HOSTvarname$
*$_SERVICEvarname$
*$_CONTACTvarname$

"_MACADDRESS"と呼ばれているカスタム変数の、以下のホスト定義で取ってください…

<pre>
define host{

host_name linuxbox

address 192.168.1.1

_MACADDRESS 00:01:02:03:04:05

...

}
</pre >

_MACADDRESSのカスタム変数は、$_HOSTMACADDRESS$と呼ばれるマクロで利用可能でしょう。カスタムオブジェクト変数と、それらをマクロにどのように使用できるかに関する詳しい情報を[http://nagios.sourceforge.net/docs/3_0/customobjectvars.html ここ]で見つけることができます。

== マクロ浄化 Macro Cleansing ==
実行されるべきコマンドに代用する前に、潜在的に危険なシェルメタ文字列をいくつかのマクロから取り去ります。マクロからどのキャラクタを取り去るかは[http://nagios.sourceforge.net/docs/3_0/configmain.html#illegal_macro_output_chars illegal_macro_output_chars]の設定内容に依ります。潜在的に危険な文字列は以下のマクロから取り去られます:

#$HOSTOUTPUT$
#$LONGHOSTOUTPUT$
#$HOSTPERFDATA$
#$HOSTACKAUTHOR$
#$HOSTACKCOMMENT$
#$SERVICEOUTPUT$
#$LONGSERVICEOUTPUT$
#$SERVICEPERFDATA$
#$SERVICEACKAUTHOR$
#$SERVICEACKCOMMENT$

== 環境変数としてのマクロ Macros as Environment Variables==
ほとんどのマクロを環境変数として簡単に参照できるように、Nagiosによって実行されるスクリプトかコマンドで利用可能にします。セキュリティと健全の目的のために、[http://nagios.sourceforge.net/docs/3_0/macrolist.html#user $USERn$]、「オンデマンド」ホスト、およびサービスマクロは、環境変数として利用可能にされなかったです。

標準のマクロを含む環境変数は、名前の先頭に"NAGIOS_"を付け加えられて ( [http://nagios.sourceforge.net/docs/3_0/macrolist.html ここ]に記載される)それら一致するマクロ名と同じように命名される。例えば、[http://nagios.sourceforge.net/docs/3_0/macrolist.html#hostname $HOSTNAME$]

[http://nagios.sourceforge.net/docs/3_0/macrolist.html#hostname 利用可能なマクロ]

Nagiosで利用可能なすべてのマクロのリストおよびそれらを使用できる時の表を[http://nagios.sourceforge.net/docs/3_0/macrolist.html ここ]で見つけることができます。

TCP ラッパー

2010-08-31T04:13:59Z

Wikiadmin: ページの作成: == 導入 Introduction == このドキュメントでは、TCPラッパーズによって拒絶される接続の試みのためにNagiosで簡単にアラートを生成する…

== 導入 Introduction ==
このドキュメントでは、TCPラッパーズによって拒絶される接続の試みのためにNagiosで簡単にアラートを生成する方法を説明します。例えば、権限のないホストがあなたのSSHサーバに接続するのを試みるなら、あなたは拒絶されたホストの名前を含めて、Nagiosでアラートを受信することができます。あなたのリナックス/ユニックスボックスにおいてこれを実装すると、あなたはあなたのネットワークの向こう側にどれだけ多くのポートスキャンを検出できるか、驚かせるでしょう。

これらの指示の推測:
#あなたは既に[http://nagios.sourceforge.net/docs/3_0/passivechecks.html パッシブチェック]と、それらがどう働いているか、よく知ってます。
#あなたは既に[[Volatile サービス]]と、それらがどう働いているか、よく知ってます。
#あなたが(すなわち、あなたがTCPラッパーを使用しているホスト)のためにアラートを生成しているホストは、(この例においてファイヤーストームと呼ばれる)リモートホストです。 Nagiosを実行している同じホストの上でアラートを生成したいなら、あなたは私が提供する例へのいくつかの変更を行う必要があるでしょう。
#あなたの監視しているサーバにおいて[http://nagios.sourceforge.net/docs/3_0/addons.html#nsca NSCAデーモン]と TCPにラッパーのアラートを生成しているリモートマシンにおいて、NSCAクライアント(send_nsca)をインストールしました。

== サービスの定義 Defining A Service ==
もしそれを既にしていないなら、リモートホスト(ファイヤーストーム)のための[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html# ホスト定義]を作成してください。

次に、ホストファイヤーストーム上のTCPラッパーのアラートのための[http://nagios.sourceforge.net/docs/3_0/configobject.html オブジェクト構成ファイル]の1つでサービスを定義してください。サービス定義はこのように見えるかもしれません:
<pre>
define service{

host_name firestorm

service_description TCP Wrappers

is_volatile 1

active_checks_enabled 0

passive_checks_enabled 1

max_check_attempts 1

check_command check_none

...

}

</pre>

上のサービス定義に関して注意するいくつかの重要なことがあります:
#その変わりやすいオプションが可能にされた。私たちは、私たちが、入るあらゆる警戒のために通知を生成して欲しいと思うので、このオプションを可能にして欲しいと思います。
#パッシブチェックが可能な間、そのサービスのアクティブチェックは出来なくなります。これは、そのサービスがNagiosによって、決してアクティブにチェックされないことを意味します--外部ソースからの全てのアラート情報をパッシブに受け取らなければならないでしょう。
#そのmax_check_attemptsは1に設定されます。これは最初のアラートが発生する時に、あなたが通知を得るのを保証します。

== TCPラッパーを構成する Writing The ScriptWriting The Script==
あなたが最後にする必要があるのは、Nagiosサーバにアラートを送り返すファイヤーストームに関するhandle_tcp_wrapperスクリプトを書くことです。このように見えるかもしれません:
<pre>
#!/bin/sh

/usr/local/nagios/libexec/eventhandlers/submit_check_result firestorm "TCP Wrappers" 2 "Denied $2-$1" > /dev/null 2> /dev/null
</pre>

handle_tcp_wrapperスクリプトは、submit_check_resultスクリプトに、実際に監視ホストにアラートを送り返す事を指令するのに注意してください。あなたのNagiosサーバが監視と呼ばれると仮定して、submit check_resultスクリプトはこのように見えるかも知れません:

<pre>
#!/bin/sh

# Arguments

# $1 = name of host in service definition

# $2 = name/description of service in service definition

# $3 = return code

# $4 = output

/bin/echo -e "$1\t$2\t$3\t$4\n" | /usr/local/nagios/bin/send_nsca monitor -c /usr/local/nagios/etc/send_nsca.cfg

</pre>

== 完了 Finishing Up==
あなたがしなければならないのは、ファイヤーストームでのinetdプロセスの再起動とあなたの監視サーバ上でのNagiosの再起動であり、あなたは必要な物すべてを今、構成しています。それです! ファイヤーストーム上のTCPラッパーズが接続の試みを拒否する時、あなたはNagiosでアラートを得るべきです。アラートのためのプラグイン出力は、以下のように見えるでしょう:

統合概要

2010-08-28T17:30:29Z

Wikiadmin: /* 統合の例 */

== 初めに ==
Nagiosがそのように人気のある監視用途である理由の1つは、容易にそれをあなたの既存のインフラストラクチャに統合されることができるという事実です。あなたが既に使用している管理ソフトウェアとNagiosを統合するいくつかのメソッドがあり、そして、あなたが持っているかも知れないほとんどあらゆるタイプの新しい、またはあつらえのハードウェア、サービス、アプリケーションも監視できます。

== 統合ポイント ==
新しいハードウェア、サービスまたはアプリケーションを監視するために、以下でドキュメントを調べてください。:

*[[プラグイン]]
*[[プラグインAPI]]
*[[パッシブチェック]]
*[[イベントハンドラ]]

外部のアプリケーションからNagiosにデータを入れるため、ドキュメントをチェックせよ:
*[[パッシブチェック]]
*[[外部コマンド]]

Nagiosから外部のアプリケーションまで状態、性能、または通知の情報を送るため、ドキュメントをチェックせよ:
*[[イベントハンドラ]]
*[[OCSP]]と[[OCHP]]コマンド
*[[パフォーマンスデータ]]
*[[通知]]

== 統合の例 ==
私は、どのように外部のアプリケーションとNagiosを統合するかのいくつかの例を記録しました。:
*[[TCPラッパー]] (セキュリティアラート)
*[[SNMP Traps|SNMP トラップ]] (アークサーブノバックアップジョブ状態)

パッシヴホストステート解釈

2010-08-28T17:26:22Z

Wikiadmin: ページの作成: == 初めに == Nagiosがリモートソース(ディストリビュートされた、もしくはフェイルオーバーセットアップにおける他のNagiosインスタ…

== 初めに ==
Nagiosがリモートソース(ディストリビュートされた、もしくはフェイルオーバーセットアップにおける他のNagiosインスタンス)からパッシヴホストチェックを受け取ったら、リモートソースによってレポートされたホストのステータスは、Nagiosの視点からホストの状態を正確に反映しないかもしれません。ディストリビュートされるフェイルオーバー監視のインストールはかなり一般的であるのと同様に、 Nagiosの異なったインスタンスの間の正確なホストのステータスを確実にするのにメカニズムを供給するのは重要です。

== 別天地の眺望 ==
以下のイメージは、簡単にしたフェイルオーバー監視のセットアップの視点を示しています。

*Nagios-Aはプライマリ監視サーバであり、すべてのスイッチやルータをアクティブに監視しています。
*Nagios-BとNagios-C、バックアップ監視サーバであり、Nagios-A からパッシブチェック結果を受けとっています。
*Router-CとRouter-Dは共に失敗をこうむり、オフラインです。

Router-CとRouter-Dは現在、どんなステータスにいるか? 答えはあなたがどのNagiosインスタンスを尋ねるかによります。
* Nagios-Aは、Router-DをDOWNとして、Router-CをUNREACHABLEとして見ます。
* Nagios-Bは、Router-CをDOWNとして、Router-DをUNREACHABLEとして見ます。
* Nagios-Cは、両方のルータをDOWNとして見ます。

それぞれのNagiosインスタンスには、ネットワークの異なった視点があります。バックアップ監視サーバはプライマリ監視サーバからパッシブホスト状態を盲目的に受け入れるべきではありません。または、彼らはネットワークの現状に関する不正確な情報があるでしょう。

プライマリ監視サーバ(Nagios-A)からパッシブホストチェックの結果を解釈せずに、それが本当に観点に基づくDOWNである時、Nagios-Cは、Router-DをUNREACHABLEと考えるでしょう。同様に、Router-CとRouter-DのためのDOWN/UNREACHABLEステータス(Nagios-Aの観点からの)は Nagios-Bの観点からはじき出されるべきです。

Note 注意: あなたが、ローカルのNagiosインスタンスの観点から、リモートソースから「正しい」それらの状態までDOWN/UNREACHABLE状態をNagiosに解釈して欲しくないいくつかの状況があるかもしれません。例えば、分散監視環境においては、あなたは、ディストリビュートされたインスタンスがどのようにそれらのネットワークのそれぞれの部分を見るかを知るために中央のNagiosインスタンスが欲しいかも知れません。

== 状態の解釈を可能にする ==
デフォルトで、Nagiosはパッシブチェック結果からDOWN/UNREACHABLEの状態を自動的に解釈しないでしょう。あなたがもし、それが必要であり欲しいなら、あなたは、この特徴を容易にする必要があるでしょう。

パッシブホストチェックの状態に関する自動解釈は、[http://nagios.sourceforge.net/docs/3_0/configmain.html#translate_passive_host_checks translate_passive_host_checks]変数によってコントロールされます。それを可能にしてください。そうすれば、NagiosはNagiosのローカルのインスタンスのためにリモートソースから正しいそれらの状態まで自動的にDOWNとUNREACHABLE状態を解釈するでしょう。

埋め込みPerlインタプリタの使用

2010-08-28T17:19:59Z

Wikiadmin: ページの作成: == 序文 == Nagiosは、埋め込みPerlインタプリタを有効にしてコンパイル出来るようになりました。これはNagiosがはるかに効率的にPerlの…

== 序文 ==

Nagiosは、埋め込みPerlインタプリタを有効にしてコンパイル出来るようになりました。これはNagiosがはるかに効率的にPerlのプラグインを実行することができるので、Perlで書かれたプラグインに大きく依存している場合には興味深いものとなるでしょう。

埋め込みPerlインタプリタなしでは、Nagiosは外部コマンドとしてプラグインをフォークして、実行することによって、Perl（そして、Perl ではない）プラグインを実行します。埋め込みPerlインタプリタが使われるときは、Nagiosは単にライブラリを呼び出すことによってPerlプラグインを実行することができます。

Tip Tip: 埋め込みPerlインタプリタは、Nagiosが実行するすべてのPerlスクリプトで動作します - プラグインだけでなく。このドキュメンテーションはホストとサービスチェックのために使用されるプラグインに関して埋め込みPerlインタプリタを説明します、しかし、あなたが他のタイプの命令で使用しているかもしれない他のタイプのPerlスクリプトにあてはまります (例. notificationscripts, event handler scripts, etc.).

Stephen Daviesは、数年前に、元の埋め込みPerlインタプリタコードを寄稿しました。Stanley Hopcroftはかなり埋め込みPerlインタプリタコードを改善するのを手伝っている主要な人で、それを使う利点/欠点についてコメントしました。彼は、きちんと埋め込まれたインタプリタで動作するPerlプラグインを作成することに、いくつかの役に立つヒントもしました。

このドキュメントで"ePN"として使用されている単語は、embedded Perl Nagiosをさしています。それか、Nagios compiled with an embedded Perl interpreter のほうがよければこちらでもかまいません。

== 利点 ==

ePN (embedded Perl Nagios)の有利な点には以下があります:

*NagiosはPerlプラグインをずっと少ない時間で実行出来ます。なぜなら(Perlインタプリタをロードする度に)プラグインを実行するのにフォークしないからです。代わりにライブラリコールによってプラグインを実行します。
*Perlプラグインによるシステム負荷を大きく減らし、組み込みPerl無しの時より多くのチェックが可能になります。言い換えれば、一般的に Perlより開発時間が必要と考えられている(そのかわりTCL以外は10倍速く実行出来るが)CやC++、Expect、TCLなどの他の言語でプラグインを書く魅力はなくなります。
*Cプログラマでなくても、Perlに重たい処理をさせることでNagiosを遅くさせずパフォーマンスを上げることが出来ます。しかし、インタープリターのロード時間と別でePNによってプラグインは速くならないことに注意してください。もし速いプラグインが必要なら、使っているPerlがチューニングされていて最適なアルゴリズムを用いていることを確認した後で(Benchmark.pmはPerl言語の本質的なパフォーマンス比較に欠かせません)、 XSUBs (XS)かCを検討してください。
*ePNの使用はさらにPerlを学ぶこの上無い機会です。

== 欠点 ==

ePN (embedded Perl Nagios)の欠点はApacheのmod_perl (組込みインタープリター付きのApache) とそのままのApacheとを比較した場合とほぼ同じです:

*そのままのNagiosで''調子良く''動作するPerlプログラムはePNを使うと動かないかもしれません。動作するようにプラグインを修正する必要があります。
*ePN無しの時よりPerlプラグインのデバッグが困難になります。
*ePNはそのままのNagiosよりサイズ(メモリ消費)が大きくなります。
*あるPerlの概念は使用出来ない、または思ったのと違うように振る舞います。
*"何かをするのには複数の方法がある"ことに気づき、おもしろくなさそうであったり明白な方法を選ばなければなりません。
*Perlのより深い知識が必要になるでしょう。(しかしXSUBSを使用するプラグインでなければ、非常に難解であったりPerlの内部的なものはありません。)

== 埋め込みPerlインタプリタ付きでNagiosをコンパイル ==

Perlプラグインとスクリプトを走らせるために埋め込みPerlインタプリタを利用したいのなら、下記のことをする必要があります:
#埋め込みPerlインタプリタを有効にし、Nagiosをコンパイルしてください (下記の指示を見てください)。
#メインコンフィグレーションファイルの [[enable_embedded_perl]] オプションを有効にしてください。
#必要ならば、 [[use_embedded_perl_implicitly]] オプションをセットしてください。このオプションは、Perlインタプリタが個々のPerlプラグインとスクリプトをデフォルトで使うかどうかを決定します。
#任意で、埋め込みPerlインタプリタを利用して動くことから、特定のPerlプラグインとスクリプトを使用可能または使用不可にしてください。特定の PerlスクリプトがPerlインタプリタの元で走っている問題があるならば、これは役に立つことがありえます。詳細は以下の指示を見てください。

== 埋め込みPerlと一緒にNagiosをコンパイル ==

あなたが埋め込みPerlインタプリタを利用したいのなら、埋め込みPerlインタプリタを有効にしてNagiosをコンパイルする必要があります。これは単に ''--enable-embedded-perl'' オプションをconfigureスクリプトに追加して再実行するだけです。埋め込みPerlインタプリタに内部コンパイルキャッシュをさせたいなら ''--with-perlcache'' オプションを同様につける必要があります。例:
./configure --enable-embedded-perl --with-perlcache otheroptions...

一旦あたらしいオプションをつけてconfigureスクリプトを再実行したら、Nagiosを再コンパイルしてください。

== Perlインタプリタの特殊プラグインの利用 ==
Nagios 3から始めて、プラグインまたはスクリプトを埋め込みPerlインタプリタで実行するかどうかについて指定することができます。Perlインタプリタで動作しない厄介なPerlスクリプトがあるならば、これは特に役に立ちます。

特定のperlスクリプトのために埋め込みPerlインタプリタを利用するべきかどうかを、はっきりとNagiosに指定するために、以下のエントリのうちの1つをPerlスクリプト/プラグインに加えてください...

特定のスクリプトがPerlインタプリタを利用するようNagiosに伝えるために、このラインをPerlスクリプトに加えてください：

# nagios: +epn

特定のスクリプトがPerlインタプリタを利用しないようNagiosに伝えるために、このラインをPerlスクリプトに加えてください：
# nagios: -epn

どちらの場合でも、Nagiosが設定を見つけるために、スクリプトの最初の10行目以内に記述しなければなりません。

Tip Tip: If you do not explicitly 個々のプラグインがPerlインタプリタの元で動くことができるかどうかを、Nagiosに伝えるために、上記の方法をはっきりと使用しないならば、Nagiosはその答えを決定します。この判定のプロセスは、 [[use_embedded_perl_implicitly]] 変数によって制御されます。値が1にセットされるならば、すべてのPerlプラグイン/スクリプト（ePNを明示的に有効にしない/無効にする）はPerlインタプリタの元で動きます。値が0であるならば、Perlインタプリタの元で動きません。

== 埋め込みPerlとしての発展中のプラグイン ==
埋め込みPerlインタプリタとしての発展中のプラグインに関する情報は、 [http://nagios.sourceforge.net/docs/3_0/epnplugins.html ここ]を見て下さい.