最大パフォーマンスを出すためのNagiosのチューニング


序文

Nagiosを起動し稼働させ始めると、どのようにしてNagiosをちょっと調整するのか知りたいと思うでしょう・・・ここではNagiosを最適化する方法についていくつか見てみます。もっと考えられるものがあったら教えてください・・・

最適化のTIPS:

  1. アグリゲートステータスアップデートを使う. アグリゲートステータスアップデート(aggregate_status_updatesオプション)を使うとステータスログを常に更新しようとしないので、監視ホストの負荷がかなり下がるでしょう。これは多数のサービスを監視している場合に特に推奨します。アグリゲートステータスアップデートを使うことで最もトレードオフされるのは、ホストとサービスの状態の変化がステータスファイルに即座に更新されないという点です。これはあまり大きな心配事にはならないかも知れません。

  2. ステータスデータの保存場所にラムディスクを使用する もしスタンダードなステータスログを使用していて、アグリゲートステータスアップデートを使用していないのであれば、ステータスログの保存場所をラムディスクにすることを考えましょう。これはディスク書き込みのIOを押さえるので(コアプログラムとCGIの両方)ほんの少しスピードアップできるでしょう。

  3. 最大並列チェックの最良値を決めるためサービス遅延状況をチェックする。 Nagiosはmax_concurrent_checksオプションを指定することで並列サービスチェックの最大値を決定できます。これはNagiosがどれぐらい監視ホストに負荷をかけるかコントロールできるのでとても有効ですが、当然処理は遅くなります。もしサービスチェックの大多数に大きな遅延(10か15秒以上)が発生しているのであれば(追加情報CGIから見られます)、おそらくNagiosにこの設定を調整してやる必要があります。これはNagiosが悪いのではなく運用者が悪いのです。 理想条件の元では、全サービスチェックの遅延値はスケジュールされた時間通り実行されたという意味では0が望ましいです。しかし、いくつかのチェックが少しの遅延を伴うのが通常です。 私は、Nagiosをコマンドラインから-sオプションをつけて起動し最大並列チェック値の最小値を求める事を推奨しましょう。サービスの平均遅延時間が低ければ増やします。サービスチェックのスケジュールのより詳しい説明はここにあります。

  4. できるだけパッシブチェックを使うパッシブサービスチェックの結果処理は"通常の"アクティブチェックのそれよりもオーバーヘッドが少ないです。ですので、多くのサービスを監視しているならこれを利用しましょう。もし監視やレポーティングになんらかの外部アプリケーションを使っているならパッシブチェックサービスは非常に有効であることに注目してください。 したがってNagiosですべてを行っている人にとってはこれは意味をなさないでしょう。

  5. インタプリタで書かれたプラグインを使うのを避ける. 監視ホストの負荷を下げる1つにはインタプリタスクリプト(perlなど)で書かれたプラグインを使うよりコンパイルされたプラグイン(C/C++など)を使うことが挙げられます。Perlスクリプトはプラグインを書いて動かすのが非常に簡単ですが、多くのサービスチェックを行っている場合、毎回コンパイル/インタプリタして実行するため監視ホストの負荷を著しく引き上げるのも事実です。もしperlプラグインを使いたいと思ったなら、perlcc(1)(標準的なPerlディストリビューションに含まれるユーティリティです)でそのプラグインをコンパイルするとか、Nagiosをenbedded perlインタプリタでコンパイル(後述)することを考えましょう。

  6. Embedded Perlインタプリタを使う. サービスチェックなどに多数のperlスクリプトを使っているなら、Nagiosをembedded Perlインタプリタでコンパイルすると、スピードアップにつながるでしょう。 Embeded Perlインタプリタでコンパイルするには、Nagiosをコンパイルする前のconfigureスクリプトで--enable-embedded-perlオプションをつける必要があります。同様に--with-perlcacheオプションをつけると、embeddedインタプリタでコンパイルされたPerlスクリプトが、再利用するためにキャッシュされるでしょう。

  7. ホストチェックコマンドを最適化する もしホストチェックにcheck_pingを使っているなら、そのホストチェックはもっと早くなるでしょう。ホスト設定ファイルのmax_attemptsの値を1に設定し、check_pingがホストに対して10 ICMPパケットを毎回送るというのに取って代わって、max_attemptsの値を10に設定しプラグインが毎回1 ICMPパケットをホストに送るようにするととても早くなるでしょう。これはNagiosが1回のプラグインの実行後にホストのステータスを毎回決定しているところに基づいており、最初のチェックをできるだけ早く終わらせるということです。この方法はいくつかの状況で危険性があります(たとえば、ホストが返すレスポンスが遅いとダウンしたと思われるでしょう)。しかし、ホストチェックを早くするには良い方法です。 他の方法としては、check_pingの代わりになる host_check_commandでより高速なもの(例:check_fping)を使うという手もあります。

  8. 定期的なホストチェックをスケジュールしない. 絶対に必要でない場合、ホストの定期的なチェックをスケジュールしないようにして下さい。 これを行う十分な理由は無く、ホストチェックが必要に応じて実行されます。 ホストの定期的なチェックを無効にするには、ホスト定義中check_interval設定を0にします。 ホストチェックを定期的に実行する必要があるなら、チェック間隔をより長くしてみて、確実にホストチェックを最適化して下さい(以下参照)。

  9. アグレッシブホストチェックを使わない。 Nagiosがホスト復旧の認識に問題がある場合を除いて、use_aggressive_host_checkingオプションは使用しないことをお勧めします。このオプションをオフにしていれば、サービスチェックの結果から判断するのでホストチェックはよりは迅速に実行されるでしょう。しかし、ホスト復旧の確実性は失われます。たとえば、ホストが復旧してもそれに属するサービスすべてがまだnon-OK状態(で異なるnon-OK状態間を"揺れて"いない)であったなら、Nagiosはホストが復旧したと判断できないかも知れません。おそらく少数の人々がこのオプションを有効にする必要があると思いますがほとんどの場合何らかの理由が無い限りこのオプションは使用しないと思います。

  10. 外部コマンドのチェック間隔を増やす。 もし多くの外部コマンドを処理しているなら(たとえば、分散設定でパッシブチェックを使っているとか)、おそらくcommand_check_interval値を-1に設定したいと思っているでしょう。これはNagiosが外部コマンドをできるだけ頻繁にチェックするという事です。これはほとんどのシステムがパイプのバッファサイズを少し(4KBとか)しかのでとても重要です。もしNagiosがパイプから十分早くデータを読み込めなかったら、外部コマンドファイルに書き込むアプリケーション(たとえば NSCAデーモン)がパイプに十分なフリースペースができるまでデータ書き込みがブロックされてしまいます。

  11. 最大パフォーマンスがでるようにハードウェアを最適化する。 システム設定とハードウェア設定はオペレーティングシステムのパフォーマンスに直接影響しますのでNagiosのパフォーマンスにも当然影響します。 最も一般的なハードウェアの最適化方法としてはハードディスクが挙げられます。 またCPUやメモリスピードも当然パフォーマンスに影響が出ますが、ディスクアクセスは最も大きなボトルネックです。プラグインや、ステータスログなどを遅いドライブ(古いIDEドライブやNFSマウント先とか)に置かないことです。もしそうしているなら、UltraSCSIドライブや、高速なIDEドライブを使いましょう。 IDE/Linuxを使う際に重要な事項としては多数のLinuxインストール状態ではディスクアクセスの最適化は考えられていません。ディスクアクセスパラメータを(hdparamなどのユーティリティを使って)変更しないのであれば新しいIDEドライブで得られるスピードアップの大部分を失ってしまうでしょう。