序論
そこで最後にNagiosを起動し実行し、そして、もう少しどの様に微調整できるかを知りたくなります。 多くの（>1000）ホストやサービスの監視し始めるとき、性能を上げるためにNagiosを調整する必要な場合があります。 ここに、Nagiosを最適化する事についての幾つかがあります…
最適化情報:
- MRTGを使った性能統計グラフ 時間と共にNagiosインストールが適切に負荷を扱っているか、そしてそれに設定変更が影響を与えているかを見続けるためMRTGの幾つか重要な統計グラフを取るべきです。 Nagiosインストールの性能を調整する事をはじめると、本当に本当に本当に役に立ちます。 本当に。 ここでこれどの様に扱うかに関する情報があります。
- 大きなインストール微調整を使用します。 use_large_installation_tweaks オプションを許可すると、より良いパーフォマンスが得られるかもしれません。 ここでこのオプションについての詳細
- 環境マクロを無効 通常、マクロは、チェック、通知、イベントハンドラなどを行うコマンドの環境変数として作られています。 これは大きなNagiosインストールでの問題かもしれません、それは、追加メモリや(より重要)CPUを使います。 スクリプトが環境変数のマクロにアクセスする必要が無いなら(例えば、あなたはコマンドラインに全て必要なマクロを渡しします)、この特徴は必要ありません。 enable_environment_macros オプションを使うことでマクロを環境変数として使う事を防ぐことができます。
- 結果刈取り頻度をチェック check_result_reaper_frequency 変数は、Nagiosが処理すべきホストとサービス・チェック結果をどれくらいの頻度でチェックするかを決定します。 それらの結果を処理するのに使う事ができる最大の時間は、最大刈取り時間で決定められています(以下を参照)。 刈取り頻度が高過ぎるなら(珍し過ぎる)、ホストとサービスチェックは待ち時間が長いかもしれません。
- 最大の刈取り時間。 max_check_result_reaper_time 変数は、Nagiosデーモンが、他の処理に移る前にホストやサービスのチェック結果を処理するのに使える合計の時間を決めます。 - 次の処理は、新しいホストやサービスのチェックなどです。 あまり高い値では、結果、ホストとサービスの長い待ち時間となります。 あまりに低い値では、同じ結果が待っています。 長い待ち時間があると、この変数を調整すると、どんな効果をもたらすかが分かります。 一方、この決断をするのに統計をグラフで表すべきです。
- バッファ・スロットを調整 external_command_buffer_slots オプションの値を調整する必要があるかもしれません。 このオプションにどんな値を使うべきかを決めるのにMRTG(上を参照)でバッファ・スロット統計をグラフに表すのは重要です。
- 最大の同時発生のチェックの最も良い値を決定するためにサービス待ち時間をチェックします。 Nagiosは max_concurrent_checks オプションで指定した値でサービス・チェックを同時に実行する数を制限する事ができます。 Nagiosにあなたの監視しているホストの開始している負荷をどの程度Nagiosに課すかについて何らかの制御をするのは良いのですが、また、それはまた、遅くなります。 サービス・チェック(extinfo CGI で)の大部分が長い待ち時間(10秒か15秒以上)なら、たぶん必要とするチェックでNagiosを飢えさせています。 それはNagiosのせいではありません--それはあなたせいです。 すべてのサービス・チェックには、理想的状態の下では、0の待ち時間でしょう、それは実行される予定であったその時に実行された事を意味して。 しかしながら、いくつかのチェックに少しの待ち時間があるのが普通です。 私は、-s コマンドライン引数でNagiosを実行した結果のチェック最大同時実行数の最小値を使い、それを倍にすることを勧めます。 サービスのための平均したチェック待ち時間がかなり低くなるまでそれを増やし続けます。 ここにサービス・チェック・スケジューリングに関する詳しい情報があります。
- 可能な時に、パッシブ・チェックを使用します。 パッシブ・サービス・チェック結果を処理するのに必要なオーバーヘッドが、アクティブ「通常の」チェックよりはるかに低いので、多くのサービスを監視しているなら、その情報を使います。 パッシブ・サービス・チェックは何らかのタイプの監視か報告をする外部のアプリケーションがあるが場合だけ本当に役に立つ事に注意すべきであり、Nagiosにすべての仕事をさせるならこれは助けとなりません。
- インタプリタのプラグイン使用を避けます。 監視ホストで負荷をかなり減少させる1つの事は、スクリプト(Perlなど)プラグインをインタプリタで使うよりコンパイルされた(C/C++など)プラグインの使用です。 Perlスクリプトは書きやすく良く働きますが、実行時に毎回 コンパイル/解釈 される事実は 多くのサービスがあるホストを監視していると大きな負荷増となります。 Perlプラグインを使用したいなら、perlcc(1)(標準に配布されテイルPerlのユーティリティ)を使用することで本当の実行形式にコンパイルし直すか、または組込Perlインタプリタを入れてNagiosをコンパイルする事を考えます。(以下を参照)。
- 組込Perlインタプリタを使用します。 サービス・チェックなどに多くのPerlスクリプトを使用している場合、組込PerlインタプリタをNagiosにバイナリーでコンパイルするスピードアップするのが多分わかります。
- ホスト・チェック・コマンドを最適化します。 check_pingプラグインを使用してホストステータスをチェックしていると、チェックが終わってみるとホスト・チェックがはるかに速く実行されるのがわかります。 max_attempts の値をホスト定義で1に設定し、check_ping プラグインが 10 のICMPパケットをホストに送る代わりに、max_attemptsを10に設定し、毎回ICMPパケットを1回しか送らない方がずっと高速です。 一度プラグインを実行した後、しばしばNagiosは、ホストの状態を決めるという事のため、あなたはできるだけ速く最初のチェックをしたいと考えます。 この方法には、いくつかの状況で落とし穴がありますが(すなわち、反応が、遅いホストは停止していると思われるかもしれません)、それを使うと、より速いホスト・チェックが行えます。 別のオプションは、check_pingの代わりにhost_check_command として、より速いプラグイン(すなわち、check_fping)を使う事です。
- 定期的なホスト・チェックの計画をします。 ホストの定期的なチェック計画をすると、実際にNagiosの性能を改善することができます。 これはキャッシュされたチェック・ロジックiが働く(以下を参照)ためです。 Nagios3の前では、定期的に予定しいるホスト・チェックが以前はよく大きなパフォーマンス改善が出来ました。 これはもうそうでなくなりました。それは、ホスト・チェックが平行に実行されるから - ちょうどサービス・チェックの様に ホストの定期的なチェックの計画をするのに、ホスト定義のcheck_interval 指示に 0 より大きな数を設定します。
- キャッシュされたホスト・チェックを可能にします。 Nagios3 からオンデマンドのホスト・チェックはキャッシュから利益を得ることができます。 Nagiosがサービスステータスの変化を検出するときはいつも、オンデマンド・ホスト・チェックが実行されます。 Nagiosが、サービスの変化に関連しているホストを知るため、これらのオンデマンド・チェックが実行されます。 キャッシュされたホスト・チェックを許可することで、性能を最適化できます。 いくつかの場合、Nagiosは実際にホスト・チェック・コマンドを実行する代わりにホストの古い/キャッシュ状態を使うことができるかもしれません。 これは、高速化し、監視サーバの負荷を減少させることができます。キャッシュされたチェックが有効にするように、ホストの定期的なチェックを計画する必要があります(上を参照)。 ここでキャッシュされたチェックに関する詳しい情報があります。
- アグレッシブ・ホスト・チェックを使用しません。 ホストの復旧をNagiosが認識するのに問題が無い限り、 use_aggressive_host_checking オプションを許可しない事を進めます。 このオプションをオフにするとホスト・チェックはずっと早く実行されます。サービス・チェック結果の処理を早くした結果です。 しかしながら、電源が切られた時の様なある環境では、ホストの復旧は見逃される事があります。 例えば、ホストが復旧して、関連しているサービスのすべてがOKでない状態だと(そして、同じOKでない状態である'変わらない')、Nagiosはホストが復旧したという事実を見逃すかもしれません。 多くの人が必要ないが、ほんの数人の人々が、このオプションを可能にする必要があるかもしれませんが、それが必要であることがわからないなら使うことを勧めません。…
- 外部コマンドの最適化。 あなたのNagiosデーモンが多くのパッシブ・チェックか外部のコマンドを受け取っているなら、バッファがいつも完全である状況で終わるかもしれません。 command_check_interval = -1. 外部のコマンド・ファイルに書くのを試みるとき、これは、子プロセス(外部のスクリプト、NSCAデーモンなど)ブロッキングをもたらします。 私は、ここで説明されるように、MRTGを使用する外部のコマンド・バッファ・スロット用法とnagiostatsユーティリティをグラフで表して、あなたのNagiosインストールの典型的な外部のコマンド・バッファの使用状況を理解することを強く勧めるでしょう。
- 最大性能を出すためハードウェアを最適化します。 注意: ハードウェア性能を問題にすべきでない、: 1) あなたは、何千ものサービスを監視している 2)性能データなどの多くの後処理をしている。 あなたのシステム構成とあなたのハードウェア・セットアップが直接あなたのオペレーティングシステムがどう働くかに影響するでしょうから、それらはNagiosがどう働くかに影響します。することができる中で最も一般的なハードウェア最適化があなたのハードドライブであります。 CPUとメモリ速度は明らかに性能に影響する要素ですが、ディスク・アクセスは最大のボトルネックになるでしょう。 プラグインやステータス・ログなどを遅いドライブに保存してはいけません(すなわち、古いIDEドライブや、またはNFSマウントです)。 それらがあるなら、UltraSCSIドライブや速いIDEはドライブを使用します。 IDE/Linuxユーザーにとって、重要な注意は、多くのLinuxインストールは、ディスク・アクセスを最適化を試みないということです。 ディスク・アクセス・パラメタ(hdparamのようなユーティリティを使用して)を変えないと、新しいIDEドライブの高速化の特徴を生かせません。
参照: