|
|
| 1行目: |
1行目: |
| − | === Level 2 ===Nagiosのパフォーマンスを最適化する
| |
| | | | |
| − | === Level 2 ===Nagiosのパフォーマンスを最適化するための微調整
| |
| − |
| |
| − | はじめに
| |
| − |
| |
| − | Nagiosが稼働したところで、微調整の方法をあげておきましょう。監視対象のホストとサービスが多数(1,000以上)だった場合には、パフォーマンスを最適化するためにNagiosを微調整する必要があります。以下にNagios最適化の詳細を示します...
| |
| − |
| |
| − | 最適化のポイント:
| |
| − | <li><b>MRTGによる統計グラフの取得。</b> 各時間帯とにNagiosがどの程度のロードを行っているか、又は構成変更がどんな影響を及ぼすかを知る為には、重要な統計をいくつかMRTGでグラフ表示させている必要があります。これはNagiosのパフォーマンスを最適化する場合には本当に、本当に、ほんとうに、役に立ちます。ほんとですよ。設定方法は<a href="mrtggraphs.html">こちら</a>です。<br><br>
| |
| − | <li><b>大規模監視の場合の微調整。</b> <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a>オプションを有効にすると、より良いパフォーマンスを提供できるかもしれません。より詳しい情報は<a href="largeinstalltweaks.html">こちら</a>。<br><br>
| |
| − | <li><b>環境マクロの無効化。</b> マクロは、チェック、通知、イベントハンドラなどが環境変数として実行するものです。これはいくらかのメモリと(さらに重要なことに)より多くのCPUを消費するので、Nagiosにとっては大きな問題となります。もしチェックスクリプトが環境変数としてのマクロにアクセスする必要がない場合(例えばコマンドラインに必要なマクロが揃っている場合)は、<a href="configmain.html#enable_environment_macros">enable_environment_macros</a>オプションを利用することで、マクロが環境変数として実行されることを防ぐことができます。<br><br>
| |
| − | <li><b>チェック結果の収集頻度。</b> <a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a>変数で、Nagiosがどのくらいの頻度でホストやサービスのチェック結果を調べなければならないかを決定します。その結果を処理するのに費やした時間の最大値は、最大収集時間(下記参照)で決定されます。もしその値が高くなりすぎるようなら(そんなことは稀ですが)、ホストやサービスチェックに時間がかかるかもしれません。<br><br>
| |
| − | <li><b>最大回収時間。</b> <a href="configmain.html#max_check_result_reaper_time">max_check_result_reaper_time</a>変数で、Nagiosがホストやサービスチェックの結果を処理するのに費やせる時間の最大値を変えることができます-新たなホストやサービスチェックはそれに従って行われます。値が大きすぎると、ホストやサービスチェックに大きな遅延が発生する場合があります。小さすぎる値も同じです。もし待ち時間が長いと思っているなら、この変数を調整してどのような影響が出るか確認してください。これについて決定する場合には、<a href="mrtggraphs.html">統計のグラフ表示</a>が必要です。<br><br>
| |
| − | <li><b>バッファスロットの調節。</b> <a href="configmain.html#external_command_buffer_slots">external_command_buffer_slots</a>オプションの値を調整する必要があるかもしれません。バッファスロットの統計を<a href="mrtggraphs.html">MRTGでグラフ表示</a>(上記参照)して、このオプションに設定する値を決定する際に役立ててください。<br><br>
| |
| − | <li><b>サービスチェックの遅延を減らし並列チェック数を最大にするためのベストな値を測定する。</b> Nagiosは、並行してサービスチェックを行う数を<a href="configmain.html#max_concurrent_checks">max_concurrent_checks</a>オプションで指定した値で制限できます。Nagiosがホストにかける負荷を少しは制御できますが、場合によっては却って遅延が発生する可能性もあります。もしサービスチェック(<a href="cgis.html#extinfo_cgi">追加情報CGI</a>参照)において遅延が発生している(10～15秒以上)場合は、Nagiosはこの部分のチェックが必要です。-つまりその遅延はNagiosではなくあなたのせいです。理想的な状況では、全てのサービスチェック遅延は0となりますが、通常はチェックのうちいくらかには多少の遅延が発生します。Nagiosで<b>-s</b>オプションを付けてコマンドを実行し、得られた結果のうち最小の値で最大の並列チェックを行うことをお勧めします。サービスチェックの遅延が低い値になるまで設定値を増やしてください。サービスチェックスケジューリングについてのより詳しい情報は<a href="checkscheduling.html">こちら</a>です。<br><br>
| |
| − | <li><b>できるだけパッシブチェックを利用する。</b> <a href="passivechecks.html">パッシブチェック</a>の処理に必要なオーバーヘッドは、"通常の"アクティブチェックより非常に少ないので、多くのサービスを監視する場合はこちらを利用してください。その場合は、外部アプリケーションによって監視やレポートを行っているかという点に注意してください。Nagiosが全て作業しているのであれば、この項目はあまり効果が期待できません。<br><br>
| |
| − | <li><b>インタプリタで書かれたプラグインを使うのを避ける。</b> 監視の負荷を下げる1つの方法としてあげられるのは、インタプリタ方式(Perlなど)ではなく、CやC++等でコンパイルされたプラグインを使用することです。Perlスクリプトはプラグイン作成が簡単で利用しやすいですが、多くのサービスチェックをしたい場合は毎回コンパイルを行うことになるため監視ホストの負荷が高くなります。Perlプラグインを利用したい場合は、perlcc(1)(Perlの標準ディストリビューションの一種)を利用するか、埋め込み型のPerlインタプリタ(下記参照)を利用することを考えてください。<br><br>
| |
| − | <li><b>埋め込み型のPerlインタプリタを利用する。</b> サービスチェックなどにPerlスクリプトを多用している場合は、<a href="embeddedperl.html">埋め込み型のPerlインタプリタ</a>でコンパイルすることによって、Nagiosの処理速度を上げることができるでしょう。<br><br></li>
| |
| − | <li><b>ホストチェックコマンドを最適化する。</b> もしホストのステータスチェックにcheck_pingプラグインを利用しているなら、それはより速く処理できるようになるでしょう。ホスト設定ファイルの<i>max_attempts</i>に1を設定してcheck_pingプラグインにICMPパケットを10個送信させる代わりに、<i>max_attempts</i>に10を設定してICMPパケットを毎回1つだけ送信させることにより、大幅な処理速度の向上が期待できます。これは、Nagiosが毎回のプラグイン実行後にホストのステータスを決定するためで、最初のチェックをできるだけ早く終わらせるということです。状況によってはリスクを伴いますが(ホストのレスポンスが遅ければダウン状態とみなされるかもしれません)、ホストチェックは高速化できます。<i>ホストチェックコマンド</i>として、check_pingプラグインの代わりにより速いプラグイン(即ちcheck_fping)を利用することもできます。<br><br>
| |
| − | <li><b>定期的なホストチェックをスケジュールする。</b> 定期的なホストチェックをスケジュールすることで、Nagiosのパフォーマンスを助けることができます。これは<a href="cachedchecks.html">キャッシュチェック論理</a>の働き(下記参照)によるものです。Nagios 3以前は、定期的なホストチェックのスケジューリングは大きな負荷がかかるものでした。しかし、サービスチェックと同じようにホストチェックの並行処理が可能となったため、その認識は誤ったものとなっています。定期的なホストチェックのスケジューリングは、<a href="objectdefinitions.html#host">ホスト定義</a>の<i>check_interval</i>ディレクティブに0より大きな値を設定することで可能となります。<br><br>
| |
| − | <li><b>ホストのキャッシュチェックを有効にする。</b> Nagios 3から、オンデマンドのホストチェックにおいてキャッシュからサービス状態を判断できるようになりました。オンデマンドのホストチェックは、サービスの状態変更を見つけるためや、そのサービスに関連したホストに状態変更があったかを知るために実行されます。キャッシュによるホストチェックを有効にすることで、パフォーマンスを最適化できます。Nagiosが度々チェックコマンドを実行するよりはキャッシュを利用する方が賢明です。これによりスピードアップと負荷の削減が可能です。ホストのキャッシュチェックを有効にするためには、定期的なホストチェックをスケジュールする(上記参照)必要があります。キャッシュチェックに関するより詳しい情報は<a href="cachedchecks.html">こちら</a>です。<br><br>
| |
| − | <li><b>アグレッシブホストチェックを利用しない。</b> Nagiosにホスト回復の認識に関する問題がない限り、<a href="configmain.html#use_agressive_host_checking">アグレッシブホストチェック</a>オプションを無効にすることをお勧めします。このオプションを無効にすると、サービスチェックはより早く完了しますが、特定の状況下ではホスト回復を見逃してしまう可能性もあります。例えば、ホストが回復しかつその全サービスがOKでない(またはOK以外のステータスを行ったり来たりしている)状態の場合、Nagiosはこのホストが回復していないと思う可能性があります。少数の人たちはこのオプションを有効にする必要があるかもしれませんが、大多数はその必要はないでしょう。必要であると確信できない限りはこのオプションを有効にしないことをお勧めします…<br><br>
| |
| − | <li><b>外部コマンド利用の最適化。</b> 外部コマンドを多用している場合(例えば<a href="distributed.html">分散監視</a>におけるパッシブチェック)は、<a href="configmain.html#command_check_interval">コマンドチェック間隔</a>オプションの値を<b>-1</b>に設定したくなるかもしれません。これによりNagiosは頻繁に外部コマンドを発行することになります。外部コマンドのために<a href="configmain.html#external_command_buffer_slots">外部コマンドバッファスロット</a>の値を増やすことも考える必要があるでしょう。外部コマンドバッファスロットは<a href="configmain.html#command_file">外部コマンドファイル</a>(それぞれ別のスレッド)から読み込まれた外部コマンドを、Nagiosが読み込むまで一時的に保持するために用いられます。Nagiosデーモンがパッシブチェックや外部コマンドを多用している場合、バッファは常にフル活用されていることになり、これは外部コマンドファイルへ書込みを行おうとすると子プロセス(外部スクリプトやNSCAデーモンなど)によってブロックされるという事態を招きます。<a href="mrtggraphs.html">こちら</a>で解説されているように、MRTGとnagiosユーティリティを利用している外部コマンドバッファスロットのグラフ表示をすることを強くお勧めします。グラフ表示から、Nagiosの外部コマンドバッファの使用状況を把握して下さい。<br><br>
| |
| − | <li><b>最大パフォーマンスのためのハードウェアの最適化。</b> 注釈:次のようなケースでない限り、ハードウェアは問題になりません... 1)何千ものサービスを監視している 2)パフォーマンスデータに多くの後処理をしている など。システム構成とハードウェアのセットアップは、OSに直接影響するのでそれはそのままNagiosにも影響します。一般的に、まずできることはハードディスクの最適化です。CPUやメモリ速度もパフォーマンスに影響を及ぼすのは明らかですが、それよりもディスクアクセスは最大のボトルネックとなります。プラグインやステータスログを、遅いドライブ(古いIDEドライブやNFSマウント上)に保存せず、必要ならUltra SCSIや速いIDEドライブを利用してください。ディスクアクセスを最適化しようとしないのは、IDE/Linuxユーザーにとって重要な問題です。(<b>hdparam</b>のようなユーティリティを用いて)ディスクアクセスパラメータを変更しない場合は、<b>多くの</b>スピーディな特徴を持つ新しいIDEドライブへ移行して下さい。<br><br>
| |
