「ホストおよびサービスのダウンタイムのスケジュール」の版間の差分

2010年8月8日 (日) 20:21時点における最新版

導入 Introduction

Nagiosはあなたに、あなたが監視しているホストとサービスのために、計画されたダウンタイムをのスケジュールを許可します。これはアップグレードなどでサーバがダウンする時などに便利です。

ダウンタイムをスケジュールする Scheduling Downtime

あなたは追加情報 CGI(ホストやサービス情報もみられる)を通してホストやサービスのダウンタイムを設定します。 "Schedule downtime for this host/service"リンクをたどってダウンタイムを設定します。

いったんホストやサービスがスケジュールされたら、Nagiosは設定した期間ダウンすると言うことをホスト/サービスのコメントとして追加します。ダウンタイムで設定した期間が過ぎたら、 Nagiosは自動的にそのコメントを削除します。

固定 vs フレキシブル　ダウンタイム Fixed vs. Flexible Downtime

Webインタフェイス経由でホストやサービスのダウンタイムをスケジュールする時、ダウンタイムが"固定"なのか"フレキシブル"なのか尋ねられます。どのように"固定"と"フレキシブル"ダウンタイムの違いがあるかを説明しましょう。

"固定"ダウンタイムの開始と終了はスケジュールした通りに正確に開始と終了が行われます。はい、これは簡単です。

"フレキシブル"ダウンタイムはホストやサービスがX分(または時間)ダウンする事が分からない時を意図しています。フレキシブルダウンタイムをスケジュールしたら、 Nagiosはあなたの指定した開始と終了時間の間のいつかにダウンタイムを開始します。ダウンタイムはあなたがダウンタイムをスケジュールした時と同じくらい長い間続くでしょう。フレキシブルダウンタイムが設定されたホストやサービスがダウンする(もしくは通信不可になる)か、指定した開始と終了時刻にnon-OK状態に入っているとします。 ホストやサービスが問題状態に遷移する時にNagiosは実際にダウンタイムを開始させます。ホストやサービスがダウンタイムが過ぎる前に回復した時でもあなたが指定した時刻までダウンタイムが続きます。 これで好都合な事があります。誰もが知っている通り、あなたは正しく実際に稼動する前に、問題が10回修正されている(そしてサーバが再起動されてる)と考える事ができる。とてもスマートです。

ダウンタイムのトリガー Triggered Downtime

ホストやサービスのダウンタイムをスケジュールする時、"triggered"ダウンタイムオプションを使う事が出来ます。 triggeredダウンタイムって何じゃい、と聞きたくなりますよね？ダウンタイムの開始にtriggeredダウンタイムを指定すると、ホストやサービスのダウンタイムスケジュール開始のトリガーに出来ます。これは多数のホストやサービスのダウンタイムをスケジュールするなら非常に役立ちます。そして、ダウンタイム期間の開始時間は別のダウンタイムエントリーの開始時間に依存します。例えば、特定のホストに(メンテナンスなどでダウンしている為) フレキシブルダウンタイムをスケジュールすると、ホストの"子"全てがダウンタイムのトリガーにした方がよいです。

スケジュールされたダウンタイムによる通知への影響 How Scheduled Downtime Affects Notifications

ホストやサービスがスケジュールダウンタイムの時間に入ったら、Nagiosはホストやサービスの通知をしません。しかしながら、"DOWNTIMESTART"通知はホストやサービスのために、今度の障害アラートを受け付けないのに、どんなadminにも気付かせます。

ホストやサービスのスケジュールダウンタイムが終わったとき、Nagiosは、ホストやサービスの通知を再開します。 "DOWNTIMEEND"通知は、スケジュールダウンタイムが終わったことをadminに通知しながら送出されます。そして、再度通常通りホストやサービスの通知が行われます。

スケジュールダウンタイムを早まって取り消すと(期限が切れる前に)、"DOWNTIMECANCELLED"通知が適切なadminに出されるでしょう。

スケジュールダウンタイムのオーバーラップ Overlapping Scheduled Downtime

私はこれを"あらっ！うごかねーぞ！"症候群と呼ぶのが好きです。私が何が言いたいか分かると思います。 "定期的な"ハードウェアアップグレードを行ったけども、OSのドライバがうごかなかったわ、RAIDアレイは壊れるわ、ハードディスクイメージは失敗するわで世の中に残されているのはオリジナルディスクのみと言う状況です。こうなってしまっては、最初に想定していた時間を3倍も4倍もオーバーしてこの作業を行わなくてはならなくなります・・・

以下のシナリオで考えてみます：

1. ホストAのダウンタイムを月曜日の7:30pm-9:30pmに設定した
2. 月曜日の夕方・7:45pmにそのサーバーを停止してハードディスクのアップグレードを開始した
3. 1時間半SCSIエラーとドライバに悩まされて、ようやく機器を稼働させた
4. 9:15に、一つのあるパーティーションが、ドライブのどこにも見あたらないと気づく
5. 長い夜になる事を認識して、戻り、ホストAのダウンタイムの設定を月曜日9:20pm から火曜日の1:30amまで追加した

もしサービスやホストのスケジュールがオーバーラップした時(この場合7:40pm-9:30pmと 9:20pm-1:30am)、 Nagiosは最後に設定したダウンタイムの期間まで待ちます。この例では、通知は火曜日の1:30amまで飛ばされます。