サービスチェックスケジュール


目次

序論
設定オプション
初期スケジュール
内部チェック遅延
サービスインタリーブ
最大同時サービスチェック数
時間制御
通常スケジュール
問題発生中のスケジュール
ホストチェック
遅延スケジューリング
スケジュール例
スケジューリングに影響するサービス定義オプション

序論

私はとあるシチュエーションでどのようにサービスチェックがスケジューリングされているのか、チェックが実際に実行されて結果が処理される時スケジュールがどのように異なるのか、という事に関してたくさんの質問を受けました。

設定オプション

始める前に、どのようにサービスチェックをスケジュールし、実行し、そして処理するのかについてたくさんの設定オプションがあります。 手始めに、それぞれのサービス定義にはいつ、そしてどのようにサービスチェックをスケジュールし、実行するのかという事を決める3つのオプションを含んでいます。それらの3つのオプションは以下です:

メイン設定ファイルの中には4つの設定オプションがあります。以下になります:

これらのオプションがどのようにサービスチェックスケジュールに影響するかの詳細に入っていきましょう。始めはOFFになっています。Nagiosが起動もしくは再起動時にどのようにサービスがスケジュールされるかについて見ていきましょう…。

初期スケジュール

Nagiosが(再)起動する時、ローカルとリモートホストへ負荷を最小限にするような方法に従って全サービスチェックの初期化を行います。 インタリーブと同様、初期サービスを始める時に間隔をあける事でこれを実現します。 サービスチェックの間隔(内部チェック遅延ともいう)はNagiosが稼働するローカルホストの負荷を最小限に/平等にするよう使用され、インタリーブはリモートホストの負荷を最小限に/平等にするのに使用されます。内部チェック遅延とインタリーブ機能は両方とも以下の議論がなされました。

サービスチェックが最初にローカルとリモートのホスト両方に負荷を与えるようスケジュールされる事は、結局のところ混乱と少しランダムになる状態を引き起こしてしまうでしょう。 その理由は全サービスを同じ間隔でチェックするわけではないという事実、 サービスの問題などにより、ホストないし いくつかのサービスがひとつまたはより多くのサービスチェックなどと、同じタイミングに決める事ができる状態ではない事もあるからです。 少なくとも我々は良きスタートの為にオフにしておきたい。可能であれば初期スケジュールは時間が過ぎる毎にローカルとリモートホストの負荷が公平になるようにします…。

注意: 初期サービスチェックのスケジュール情報を見たければ、-sというコマンドラインオプションをつけてNagiosを起動してください。そうすると基本スケジュール情報(内部チェック遅延、インタリーブファクタ、最初と最後のサービスチェック時間など)を表示し、全サービスの初期スケジュールを正確に見せるステータスログを生成します。 このオプションはステータスログを上書きしてしまいますので、Nagiosがまた別に起動しているような時は使わない方がよいでしょう。 上記の方法をとった場合、Nagios は監視を始めません

内部チェック遅延

前述の通り、Nagiosは均等に初期サービスチェックの間隔をおくことによってNagiosを実行しているマシン自体の負荷も均等にしようとします。連続的なサービスチェックの間隔を内部チェック遅延といいます。メイン設定ファイル中のservice_inter_check_delay_methodに値をセットする事により、どのようにこの遅延を計算するかを修正できます。 どのように"smart"計算法が働いているのかについて述べます。通常はこのオプションを使いたい筈です。

service_inter_check_delay_method に"smart"を設定した時、Nagiosは次のような計算法で内部チェック遅延の値を計算します:

内部チェック遅延 = (全サービスのチェック間隔の平均) / (サービスの総数)

例をあげましょう。あなたは通常のチェック間隔が5分である、1000のサービスがあるとします(明らかにいくつかのサービスは異なった間隔でチェックされようとしますが、簡単な例として見て下さい…)。 全サービスの内部チェック時間の総数は5000になります(1000*5)。 すなわち各々のサービスのチェック間隔の平均は5分である事を意味します(5,000/1,000)。そういった情報で、私達は1000サービスの(平均)再チェックが5分おきである事が必要だとわかるのです。初期サービスチェックが広がる時、0.005分(0.3秒)の内部チェック間隔が使われる事を意味します。0.3秒おきにサービスチェックの間隔が空く事で、私達はNagiosが毎秒3つの新規チェックをスケジュール、実行していると幾分保証する事ができます。このように時間が経つにつれて均等な間隔をおく事により、私達はNagiosを走らせているローカルサーバの負荷がいくらかバランスがとれたままである事を望めます。

サービスインタリーブ

上で同じくらい議論していますが、 内部チェック間隔はNagiosがローカルホストに負荷を均等に負わせる助けとなります。ではリモートホストはどうでしょうか?リモートホストの負荷も均等にする必要があるのでしょうか? なぜ必要なのでしょう? 必要です。重要であり、必要なのです。Nagiosはこれも解決できます。 リモートホストの負荷の平均化はサービスチェックの並列化の到来により特に重要なものとなりました。 もしあなたがリモートホストにおける多数のサービスを監視し、チェックが広がっていかないなら、リモートホストは同じポートに対する大量の接続オープンによるSYN攻撃の犠牲にあったと考えているのかもしれません。加えて、ホストの負荷を平均化する良い機能が働いているのでしょう…。

メイン設定ファイル内にある、service_interleave_factor変数に 値を与える事によって、どのようにインタリーブファクタを計算するのかを編集する事が出来ます。 "smart"計算法がどのように働いているかについて述べます。これはたぶんあなたが通常の操作に使用したくなる設定になるので。 しかしながら、あなたの為にNagios が1つについて計算する代わりに事前に用意されたインタリーブ・ファクタを 使用する事ができます。 注意としては、インターリーブ・ファクタに1をセットすると サービスチェックインターリービングは基本的に無効になります。

サービスインタリーヴファクター変数に"smart"をセットした時、 Nagiosは以下の計算式を使ってインタリーブファクタを計算します。

interleave factor = ceil ( サービスの総数 / ホストの総数 )

例を挙げましょう。 あなたは1000のサービスと150のホストを監視しているものとします。 Nagios インタリーブファクタを7であるものと見込むでしょう。 これはNagiosが初期サービスチェックを行う際に最初の1回を実施し、次の6回を飛ばして、また次の1回・・・といった 風にスケジュールする事を意味します。 この過程はすべてのサービスチェックが予定されるまで繰り返し続けるでしょう。 サービスは、それらが関連しているホストの名前によってソートされるので(そして、このようにしてスケジュールされます)、 リモートホストが置かれている状態で、負荷を最小に/均等にする手助けになるでしょう。

以下のイメージはインタリーブが無効(service_interleave_factor=1)の時と service_interleave_factorを4に設定した時のサービスチェックスケジュールの動きを図示したものです。

インタリーブチェック無:インタリーブチェック有:
Non-Interleaved Checks Interleaved Checks
Non-Interleaved Checks Interleaved Checks
Interleaved Checks

最大同時サービスチェック数

In order to prevent Nagios from consuming all of your CPU resources, you can restrict the maximum number of concurrent service checks that can be running at any given time. NagiosがCPUリソース全てを消費するのを防ぐ為に、あなたはその 時々で稼動する同時発生サービスチェックの最大数を制限したくなる場合があります。 これはメイン設定ファイルにある、 max_concurrent_checksで制御できます。

この設定の良いところはNagiosのCPU使用率を規制出来るという事です。 悪いところとしては、この値がとても低くなっているとサービスチェックが遅れてしまう事です。 サービスチェックを実行する時、Nagiosはx以上のサービスチェックが 実行されようとしていないか結果が処理待ちになるかを確かめようとします。 (xはあなたがmax_concurrent_checksオプションで指定した数が入ります) 制限に達すると、Nagiosは前のチェックが終了するまで、どんなチェックの実行も延期します。 ではどのようにmax_concurrent_checks オプションを決定すればよいのでしょう?

始めにOFFの場合、以下の事を知る必要があります・・・

次に以下の計算を使用して、許容される同時発生チェック最大数の適正値を決定してください…

最大同時サービスチェック数 = ceil( max( サービス刈り取り頻度 , 平均チェック実行時間) / 内部チェックの遅延 )

計算によって得られた値はmax_concurrent_checks変数の合理的な出発点として提供されるべきです。 サービスチェックがスケジュールに遅れてしまっている場合はこの値を少し増やすべきですし、NagiosがCPUを大量消費している場合は減らすべきです。

あなたが875サービスを監視しているとして、それぞれの平均チェックに2分の間隔があるとします。 これは内部チェック遅延が0.137秒になる事を意味します。 サービス刈り取り頻度を10秒とした場合、あなたは最大の粗い値を計算できます。 つまり最大チェックの数は・・・(私は、サービスチェックのための平均した実行時間が10秒未満であると思います。)

最大同時サービスチェック数 = ceil( 10 / 0.137 )

この場合、計算された値は73になります。 (平均的に)Nagiosが1秒あたりちょうど7つ以上の新しいサービスチェックを実行して、10秒毎にサービス チェック結果を処理するだけであるので、これは理解できます。 それは、ある与えられた時にちょうど70以上サービスが、実行されるか、またはそれらの結果を持ってい るのを待つことを処理されたのをチェックするのを意味します。 この場合、私は最大同時サービスチェックを80にする事をたぶん勧めるでしょう。 Nagiosがサービスチェック結果を処理して、他の仕事をするとき、遅延してしまいますから。 明らかに、あなたのシステムでスムーズに動かせるようテストし、調整する必要はありますが、 うまくいくような一般的なガイドラインを提供しています。

時間の抑制

check_periodオプションでNagiosがサービスチェックを実行している間の 期間を決定できます。 特定のサービスがあるどんな状態にかかわらず、 チェックは指定された期間中にそれが実際に実行される時間が有効な時間でないなら、実行されないだろう。 代わりに、Nagiosは期間中に次のサービスチェックをりスケジューリングします。 チェックが実行できる時であれば(有効な期間であれば)、サービスチェックが実行されるでしょう。

注意: サービスチェックは一度に実行することができないかもしれませんが、 その時Nagiosは、まだそれが走る計画をしているかもしれません。 これは初期サービススケジューリング中にもっとも起こりがちですが、他にも起こりうるケースがあるでしょう。 これはNagiosがチェックする事を意味しているのではない! サービスチェックが実際に実行される時、Nagiosは現在実行できるかを検証します。 これができないと、Nagiosはサービスチェックをしないが、また後で再実行をスケジュールします。 混乱しないように!スケジュールとサービスチェック実行の2つには明確な(関連のある)違いがあります。

通常スケジュール

ネットワーク問題が起こらない事が理想ですが、そうであれば、ネットワーク監視ツールは不要でしょう。 とにかく、ものがスムーズに動いていて、サービスがOK状態にある時、我々は"normal"と呼びます。 サービスチェックは通常check_intervalオプションで指定された頻度でスケジュールされています。 それだけです。簡単だって?

問題発生中のスケジュール

サービスに関する問題がある時何が起こるのでしょうか? まず起こる事のひとつは、サービスチェックスケジュールが変わる事です。 あなたがサービス定義においてmax_attemptsオプションを1以上に設定しているなら、 Nagiosは本当に問題が起こっている事を決定づける為に再チェックを行います。 サービスが再チェックしている間(max_attemptsの回数になるまで)"soft"状態と考えられます (ここで述べられています) 。 そしてサービスチェックはretry_intervalオプションによって決定している頻度で再スケジュールされます。

Nagiosがmax_attemptsの回数分チェックしてもnon-OK状態の場合、 Nagiosはサービスを"hard"状態にして、(適切なら)通知先へ通知を送信し、 check_intervalオプションで決定された頻度で次のチェックを再スケジュールし始めます。

いつも通り、ルールには例外があります。 サービスチェック結果がnon-OK状態の時、 Nagiosはサービスが関連するホストがUPかどうかをチェックします。 (どのように行われているかは以下に情報があります). ホストがUPではない場合は(例 ダウンもしくはネットワーク疎通がとれない場合) Nagiosはすぐにサービスをhard non-OK状態に切り替え、 現在の実行回数を1にリセットします。 サービスがhard non-OK状態なので、 サービスチェックはretry_intervalオプションの代わりにcheck_intervalオプションで 指定された通常頻度で再スケジュールします。

ホストチェック

サービスチェックと違い、ホストチェックは定期的にスケジュールされません。 代わりに、Nagiosが必要性を認めるとき、それらは要求に応じて走ります。 これはユーザから行われる一般的な質問であるので、はっきりしておく必要があります。

Nagiosがホストの状態をチェックする一例が、サービスチェック結果がnon-OK状態の時です。 NagiosはホストがUPなのか、DOWNなのか、はたまた不到達状態なのかを 決定する為にホストをチェックしています。 最初のホストチェックがnon-OK状態を返すと、Nagiosは (a) ホストチェックの最大数(ホスト定義でmax_attemptsオプションで指定できる)に達しているか、 または (b) ホストチェックがOK状態をもたらすまで、 ホストのチェックをし続けるでしょう。

これも注意して頂きたいのですが - Nagiosがホストの状態をチェックするときは、 他の何かをするのを差し控えます。 (新しいサービスチェックを行う、サービスチェック結果の処理を行う、など) こういった事では処理を少し緩やかにすすめさせることができ、 しばらくペンディング状態のサービスチェックが発生しますが、 Nagiosは問題を抱えたサービスへのどんなさらなる行動も取ること ができる前にホストの状態を決定するのが必要です。

スケジュール遅延

サービスチェックのスケジューリングと実行は最も効果のある基礎を築いています。 個々のサービスチェックがNagiosの中で優先順位の低いイベントであると考えられるので、 高い優先権イベントが実行される必要がある場合は彼らを遅らせることができます。 優先順位の高いイベント例としてはログファイルローテーション、外部コマンドチェック そしてサービス刈り取りイベントがあります。 さらにホストチェックはサービスチェックの実行と処理が遅くなります。

スケジュール例

サービスチェック実行とその結果処理のスケジュールについて考察するのは難しい事ですので、 簡単な例を見てみる事にしましょう。

Image 5.

まずはじめに, the Xnイベントはメイン設定ファイル中の service_reaper_frequencyオプションで 指定された頻度でスケジュールされたサービス刈り取りイベントです。 サービス刈り取りイベントはサービスチェック結果を集めて、処理する仕事をします。 必要に応じてホストチェック、イベントハンドラ、および通知を開始して、 それらはNagiosのためのコア論理として役立ちます。

この例では、 サービスはA時間に実行されるようスケジュールされています。 しかしながら、Nagiosはイベントキューの後ろに待たされる為、チェックはB時間になるまで実際には 実行されませんでした。 サービスチェックがC時間に実行が完了し、CBの間の差分が実際にチェックが 走っていた時間という事になります。

チェックが実行された直後にサービスチェック結果が処理されるわけではありません。 代わりに、後で動作するサービス刈り取りイベントで結果が保存されます。 次のサービス刈り取りイベントはD時間で起こり、 それが結果が処理されるおよその時間になります。 (実際の時間は他のサービスチェック結果が処理されているのでD時間より遅れる事になるだろう)

サービス刈取りイベントがサービスチェック結果を処理する時に、 次のサービスチェックの時期をリスケジューリングし、それをNagiosのイベント待ち行列に置くでしょう。 サービスチェックがOK状態だったと仮定してすすめますが、次のEでのチェック時間は  元々予定されたcheck_intervalで指定された時間が経った後でスケジュールされます。 サービスは最後に実行された実行時間を元に再スケジュールされない事に注意して下さい! これもひとつだけ例外がある(いつもの事だって?) - サービスチェックが実際に実行される時間(ポイントB)が 次のサービスチェック時間(ポイントE)の後に起こると、 Nagiosは、次のチェック時間を調整することによって、代償するでしょう。 Nagiosが重い負荷状態にあって、サービスチェックをしようとしながら 気が狂っていないのを保証するためにこれをします。 そのうえ、過去に…何かのスケジュールをする意味は何でしょう・・・?

スケジュール後のサービス定義オプション

それぞれのサービス定義には normal_check_intervalretry_check_intervalオプションを含んでいます。 できたらこれら二つが行う事を、これらがサービス定義の中にある max_check_attemptsオプションがどう関わり関係するか、 そしてサービススケジュールにどう影響するかをはっきりさせたい。

はじめに、normal_check_intervalオプションはサービスが"normal"な状況下でチェックされる 間隔を指定します。 "Normal"状況下とはOK状態であるか、hard non-OK状態では無い状態で ある事を意味します。

サービスが最初にOK状態からnon-OK状態に変化するとき、 Nagiosは一時減速する能力をあなたに与えるか、 またはそのサービスのその後のチェックが起こる間隔を短くします。 サービスが最初に状態を変えるとき、 実際に問題があると決めつける前にNagiosはサービスチェックを max_check_attemptsの-1まで再試行します。 サービス再実行中は、retry_check_intervalオプションに一致する間隔で normal_check_intervalオプションよりも間隔を短く、もしくは長くしてスケジュールします。 サービスが再チェックされてる間(max_check_attempts-1回になるまで)、 サービスはソフトステートになります。 もしサービスがmax_check_attempts-1回になってもまだnon-OK状態であると、 サービスはハードステートに切り替えられ、 check_intervalオプションで指定された標準の頻度で再スケジュールされます。

少し注意ですが、max_check_attemptsオプションに1を指定していると、 サービスがretry_check_intervalオプションで指定した間隔でチェックされる事はありません。 そのかわり、すぐにハードステートに代わり、 normal_check_intervalオプションで指定された速度で再スケジュールされます。