https://nagios.x-trans.jp/nagios/index.php?action=history&feed=atom&title=%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%95%E3%82%8C%E3%81%9F%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF 2026-04-19T16:16:13Z このウィキのこのページに関する変更履歴 MediaWiki 1.25.1 https://nagios.x-trans.jp/nagios/index.php?title=%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%95%E3%82%8C%E3%81%9F%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&diff=370&oldid=prev 2010-09-04T13:05:46Z

<p>ページの作成: == はじめに　Introduction == Nagiosの監視ロジックの性能は、キャッシュされたチェックを使用することで、とても向上させることができ…</p> <p><b>新規ページ</b></p><div>== はじめに　Introduction ==<br /> Nagiosの監視ロジックの性能は、キャッシュされたチェックを使用することで、とても向上させることができます。キャッシュされたチェックで、比較的最近行ったチェックが代わりに用いることができるのならば、 Nagiosは、ホストチェックやサービスチェックの実行を無視することが出来ます。 <br /> <br /> <br /> == オンデマンドチェクのためだけに For On-Demand Checks Only==<br /> 定期的にスケジュールされているホストチェックとサービスチェックは、キャッシュされたチェックを使っても、性能の改善はされません。キャッシュされたチェックは、ホストチェックとサービスチェックの、オンデマンド性能を向上させるのだけに役に立ちます。定期的なチェックは、定期的に行われるホストステータスとサービスステータスの更新の確認を手助けします。その結果、将来それらの結果が、キャッシュされたチェックに利用できる大きな可能性を持っているかもしれません。 <br /> <br /> <br /> 参考として、オンデマンドホストチェックが実行されます・・・ <br /> *ホストに関連したサービスが状態を変えた時<br /> *host reachability(ホストへの到達性) ロジックの一部として必要<br /> *predictive host dependency checks(予測ホスト依存チェック) に必要<br /> <br /> そして、オンデマンドサービスチェックが実行されます・・・ <br /> *predictive service dependency checks(予測サービス依存チェック) に必要な時<br /> <br /> <br /> [[ファイル:Hint.gif]]サービスの依存を利用しなければ、Nagiosはサービスチェックの性能を向上させるのにキャッシュされたチェックの結果を使用できません。ご心配はいりません。これが普通なのです。キャッシュされたホストチェックには、大幅な性能改善があるので、皆がこの利益に目を向けるべきなのです。 <br /> <br /> <br /> == キャッシュはどう動くのか How Caching Works ==<br /> Nagiosが、オンデマンドのホストチェックかサービスチェックを実行する必要があるとき、キャッシュされたチェックの結果を使用するか、プラグインの実行による実際のチェック結果を使用するかを判断をします。それは、最後のホストチェックやサービスチェックが直前までのX分間に発生したかどうかを調べる為に行われます。尚、Xはキャッシュされたサービスチェックの保持限界時間を指します。 <br /> <br /> <br /> キャッシュされたチェックの限界変数によって指定された時間枠の中で最後のチェックが行われたならば、 Nagiosは最後のホストチェックやサービスチェックの結果を利用して、新しいチェックは実行 しません 。ホストやサービスがまだチェックされていない、または最後のキャッシュされたチェックの結果がチェック限界時間枠外になると、 Nagiosは、プラグインを実行して、新しいホストチェックやサービスチェックを実行します。 <br /> <br /> <br /> ==これの本当の意味とは What This Really Means==<br /> 時間内で、 at that exact moment(正確なその瞬間での) のホストやサービスのステータス(状態)を知る必要があるため、Nagiosはオンデマンドチェックを実行します。キャッシュされたチェックを利用する事は、 Nagiosが、現在のホストの状態を決める為には最新のチェック結果だけで&quot;十分&quot;だと認め、ホストやサービスのステータス(状態)の再チェックも必要でないことを認めることです。 <br /> <br /> キャッシュされたチェックの限界は、ホストやサービスの現在の状態を反映する為に、チェック結果がどのくらい最近でないといけないかをNagiosに伝えます。例えば、キャッシュされたチェックの限界時間を30秒とする事は、あなたはNagiosにホストのステータスが30秒以内にチェックされたものならば、そのチェック結果はまだ、現在の結果とみなせと指示する事です。 <br /> <br /> Nagiosは実行されなければいけないオンデマンドチェックの回数に対して、キャッシュされたチェックの結果の回数がキャッシュされたチェックの&quot;hit(ヒット)&quot;率と考えます。ホストの一定間隔のチェックと等しいようにキャッシュされたチェックの限界を増やすことによって、理論上、100%のキャッシュヒット率を達成することが出来るでしょう。その場合、全てのオンデマンドチェックでは、キャッシュされたチェックの結果を使うでしょう。驚くような性能の向上ですね！しかし本当にそうなのでしょうかね？多分違うのですよ。 <br /> <br /> キャッシュされたチェック結果の情報の信頼性は、時間がたつにつれ減少していきます。より高いキャッシュヒット率を実現するには、前回行ったキャッシュチェックの結果が、より長い時間の間、&quot;有効である&quot;ことを示す必要があります。どのようなネットワークでもその状態は急速に変化していきます。そして、30秒前まで機能していたサーバーが、今現在も障害が発生していないという保証はどこにもありません。信頼性とスピードは、トレードオフ（等価交換）な関係なのです。キャッシュされたチェックの有効限界時間を長くするならば、監視ロジックで使用されるチェックの結果が信頼できないものであるというリスクを冒すことになるのです。 <br /> <br /> Nagiosは、最終的に全てのホストとサービスの状態を決定するので、キャッシュされたチェックの結果が、本当に信頼できないものだとしても Nagiosは短期間、不適格な情報で動作するのです。短期間の当てにならないステータスの情報でさえ、管理者にとっては厄介なものとなります。それらのせいで、既に存在しない障害の通知を受け取るかもしれないからです。 <br /> <br /> 全てのNagiosユーザが受け入れられるような、標準のキャッシュのチェック時間やキャッシュヒット率はありません。ある人は、短い限界時間枠と低いキャッシュヒット率を求め、他の人は、より大きな限界時間枠と、より大きなキャッシュヒット率（低い信頼性率を持っている）を求めます。ユーザの中には、100%の信頼性のレートを得るために、全体で行われたキャッシュされたチェックを無効にしたがる人すらいます。異なった限界時間枠でテストし、ステータス情報の信頼性へそれらが与える効果を、それぞれのユーザが、自らの環境で試して、「適正」な値を見つける必要があります。これに関する詳しい話は、以下で議論されています。 <br /> <br /> <br /> ==設定変数 Configuration Variables==<br /> 以下の変数は、前もってホストやサービスのチェック結果がキャッシュされたホストやキャッシュされたサービスの結果として使用できる時間枠を決定します。<br /> *cached_host_check_horizon（キャッシュされたホストの限界時間） 変数は、キャッシュされたホストのチェックを制御します。<br /> *cached_service_check_horizon（キャッシュされたサービスの限界時間） 変数は、キャッシュされたサービスのチェックを制御します。<br /> <br /> <br /> ==キャッシュの有効性を最適化する Optimizing Cache Effectiveness==<br /> キャッシュされたチェックを、最も効果的に利用するためにするべき事とは・・・: <br /> *ホストの定期的なチェックを計画します。<br /> *1]オンデマンドチェック 2]キャッシュチェックのためMRTGのグラフ統計を使います。<br /> *あなたのニーズに合うように、キャッシュされたチェックの限界変数を調整します。<br /> <br /> <br /> host definitions（ホスト定義）の check_interval オプションの値を、0以上を指定することで、ホストの定期的なチェックを計画できます。もしこれを行うなら、 max_check_attempts（最大チェック試行数） オプションを、1以上に設定した事を確認します。 もし設定しなければ、大きなパーフォーマンスヒットを起こします。この潜在的パフォーマンスヒットは、 [http://nagios.sourceforge.net/docs/3_0/hostchecks.html ここ]で、詳しく述べられています。 <br /> <br /> <br /> キャッシュされたチェックの限界オプションの最適値を決定するための近道は、 Nagiosが実際にオンデマンドチェックを実行した数と、キャッシュされた値を使う回数を比較することです。 nagiostats（ナギオスタッツ）ユーティリティは、キャッシュされたチェックの情報を作り出すことができます。それは、 graphed with MRTGのグラフを作る事で可能になります。右に示すように、MRTGのグラフはキャッシュに対し、実際のオンデマンドチェックを対比して示しています。 <br /> <br /> <br /> 上記のグラフを作り出す監視ソフトをインストールしましょう: <br /> *合計44個のホスト全てが、一定の間隔でチェックされました。<br /> *5分の平均した(定期的にスケジュールされている)ホストチェック間隔<br /> *15秒の、 cached_host_check_horizon（キャッシュされたホストの限界時間）<br /> <br /> <br /> 最初のMRTGグラフは、どのくらい多くのキャッシュされたホストチェックが、通常のホストチェックに比べてスケジュールされたかを示しています。この例では、平均53のホストチェックが5分毎に起こります。これら内、9個(17%)はオンデマンドチェックです。 <br /> <br /> 2番目のMRTGのグラフは、どれだけのキャッシュされたホストのチェックが時間内に起こったのかを示しています。この例では、キャッシュされたホストのチェックは5分毎に平均2回起こるということになります。 <br /> <br /> キャッシュされたチェックは、オンデマンドチェックだけで利用可能だという事を覚えておいてください。 5分間の平均に基づいたグラフから、 Nagiosがオンデマンドのチェックの9回中2回をキャッシュされたホストチェックの結果を使用しているという事がわかります。それはあまり実感できないものかもしれませんが、これらのグラフは小さな監視環境でのグラフです。 9個中の2個が22%であり、もしこれが、大規模な環境ならば、ホストチェック性能を大幅に向上させる事がいかに大切なのかが分かります。 キャッシュされたホストチェックの限界変数の値が増加したらパーセントは高くなります。しかし、キャッシュされたホストのステータスの情報の信頼性は低くなります。 <br /> <br /> 何時間か何日かの有用なMRTGグラフが出来あがると、どれだけの数のホストとサービスのチェックがどれだけの数のプラグインを使用して行われ、それに対しキャッシュされた結果がどれだけ使われたのかがわかります。その情報を用いれば、あなたの状況に適切なキャッシュされたチェックの限界変数の値に調整することができます。 MRTGグラフをずっと監視し続けていると、どのように限界変数の変更がキャッシュされたチェックの統計に影響を与えるかが分かります。これらは、必要に応じて更新を繰り返します。</div>

Wikiadmin