Nagios

序論


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

Nagiosの監視ロジックの性能は、キャッシュされたチェックを使う事で、かなり向上できます。 キャッシュされたチェックで、Nagiosは、比較的最近のチェック結果が代わりに使えるならホストかサービス・チェック命令の実行を行わないことができます。

オンデマンド・チェックだけに

定期的に予定されているホストとサービス・チェックはキャッシュされたチェックを使っても性能の改善はされません。 キャッシュされたチェックはホストとサービス・チェックのオンデマンド性能を向上させるのにだけ役に立ちます。 定期チェックは、定期的なホストとサービス・ステータスが更新される確認を助けます。結果として将来キャッシュされたチェックを結果として使える大きな可能性をもたらすかもしれません。

参考のため、オンデマンド・ホスト・チェックが行われます…

そして、オンデマンドサービス・チェックは行われます…

注意: サービスの依存を利用しないなら、Nagiosは、サービス・チェックの性能を向上させるのにキャッシュされたチェック結果を使用できません。 心配しないで下さい - 普通です キャッシュされたホスト・チェックには、大幅な性能改善があり、皆この利益に目を向けるべきです。

キャッシュはどう働くか。

キャッシュされて、論理をチェックします。

Nagiosが、オンデマンドのホストかサービス・チェックを実行する必要があるとき、キャッシュされたチェック結果を使用するか、プラグインを実行して実際のチェック結果を得るかを判断をします。 それは、最後のホストかサービスのチェックが X分間の間に起こったかどうか確認するためにチェックで行われます。なお、Xはキャッシュされたホストかサービス・チェック限界時間です。

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

この本当の意味

時間内に正確なその時のホストやサービスの状態を知るのが必要であるので、Nagiosはオンデマンド・チェックを実行します。 キャッシュされたチェックを利用する事は、現在のホストの状態を決めるのに最新の結果で"十分”とNagiosに考えさせることです。そしてホストやサービスの状態を実際再チェックの必要がないことでもあります。

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

Nagiosがそれが実際に実行しなければならないオンデマンド・チェック数に対して使用したキャッシュ・チェック結果の数がキャッシュされたチェック「ヒット」率と考えることができます。 ホストの一定のチェック間隔と等しいようにキャッシュされたチェック限界を増加させることによって、理論的に100%のキャッシュ・ヒット率を達成できるでしょう。 その場合、そのホストのオンデマンドのチェックでは全てキャッシュのチェック結果を使うでしょう。 何という性能改良でしょう! しかし、本当に、そうですか? たぶんそうではありません。

キャッシュされたチェック結果情報の信頼性は時間がたつにつれ減少します。 より高いキャッシュ・ヒット率である事は前のチェック結果が、より長い期間に「有効である」と考える事が必要です。 いろいろな事はどんなネットワーク・シナリオでも急速に変化します、そして、30秒前に適切に機能していたサーバが、たった今障害となっていないという保証が全くありません。 トレードオフです - 信頼性とスピード 大きいキャッシュされたチェック限界を使うと、監視ロジックで使われるチェックの結果が信頼できないリスクを冒します。

Nagiosは結局、全てのホストとサービスの状態を決定するので、キャッシュされたチェック結果が真の値には信頼出来ないとしても、Nagiosは短期間、不正確な情報で動作します。 短期のあてにならないステータス情報さえ管理者に厄介です、それは、もう存在しない障害の通知を受け取るかもしれないからです。

あらゆるNagiosの利用者に許容できるような標準のキャッシュ・チェック限界時間もキャッシュ・ヒット率もありません。 何人かの人々は短い限界時間枠と低キャッシュ・ヒット率を欲し、他の人は、より大きい限界時間枠と、より大きいキャッシュ・ヒット率(低信頼性のレートがある)を欲します。 ユーザの中には100%の信頼性のレートを得るために全体でキャッシュされたチェックを無効にしたがる人もいます。 異なった限界時間枠をテストし、ステータス情報の信頼性への効果は、それぞれのユーザがその状況で「適切な」値を見つけて欲しいということです。 この詳しい情報は、以下で議論されています。

設定変数

以下の変数は、前のホストやサービス・チェック結果がホストやサービスのキャッシュされたサービス結果として使える時間枠を決定します:

キャッシュの有効性を最適化します。


キャッシュされたチェックを最もうまく利用するために、あなたがするべき事:

ホスト定義check_interval オプションに値0以上を指定することで、ホストの定期チェックを計画できます。 これをするなら、max_check_attempts オプションを1以上に設定した事を確認します。さもなければ、大きなパーフォーマンス・ヒットを起こします。 この潜在的パフォーマンス・ヒットはここで、詳しく述べられています。

キャッシュされたチェックはグラフ化します。

キャッシュされたチェック限界オプションの固有値を決定する早道は、Nagiosが実際にオンデマンドチェックを実行する数とキャッシュされた値を使う回数を比較することです。 nagiostats ユーティリティはキャッシュされたチェック情報を作り出すことができます。それは、MRTGのグラフを作る事で出来きます。 右に示すようにMRTGグラフはキャッシュに対し実際のオンデマンド・チェックを見せています。

監視で上記のグラフを作り出すソフトをインストール:

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

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

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

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

参照 参照: ホスト・チェック, サービス・チェック, 予言の依存はチェックします

English Deutsch 日本語

目次