今回は、ホストとサービスの監視間隔についてのナレッジを紹介します。ホストとサービスの監視間隔の関係を正しく理解すれば、より適切に監視設定を設計できます。
監視間隔 – ホスト vs サービス
Nagios管理者が共通して遭遇する問題の１つに、ホストがダウンしたときにサービスの通知を受け取るということがあります。ホストがダウンするとサービスの通知が抑制されるはずなのに、なぜこのようなことが起こるのでしょうか・・・。
ホストがダウンすると（非OKステータスになると）、Nagiosはこのホストに関連するサービスの通知を抑制します。しかし、これはホストがHARD非OKステータスになったときだけです。
ホストがダウンしたのになぜサービス通知が送信されるのか？これは、ホストとサービスの監視間隔、リトライ間隔、試行回数の設定が関係しています。
たとえばホストとサービスに同じ監視間隔が設定されているとどうなるでしょうか？
これはよくある設定の誤りです。ホストとサービスの監視間隔が同じ場合、ホストのHARD 非OKステータスが検出される前にサービスのHARD非OKステータスが検出されてしてしまう可能性があります。これが起こると不要なサービス通知が送信されてしまいます。
不要な通知の送信を防ぐには、ホストのHARD非OKステータスをサービスの障害よりも早く検出できるように設定しましょう。
簡単なシナリオで説明します。
下はホストとサービスで同じ監視間隔と最大試行回数が設定されています。
|
define host{
use windows-server host_name host1 alias host1 address 10.25.14.51 check_interval 5 retry_interval 1 max_check_attempts 5 notification_interval 30 }
define service{
use local-service host_name host1 service_description Memory Usage check_command check_nrpe!CheckMem!ShowAll type=physical MinWarn=512M MinCrit=256M check_interval 5 retry_interval 1 max_check_attempts 5 notification_interval 30 } |
以下は、この設定例をもとにしたシナリオです。
- 13:10:10
- Nagiosがhost1に対してホストチェックを実施
- 結果 = OK
- HARD ステータス
- 試行 1/5
- 次回のチェック 13:15:10
- 13:10:30
- host1停止
- Nagiosはまだこれを知らない
- 13:10:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 1/5
- 通知送信なし
- 次回のチェック 13:12:20
- 13:12:20
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 2/5
- 通知送信なし
- 次回のチェック 13:13:50
- 13:13:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 3/5
- 通知送信なし
- 次回のチェック 13:15:20
- 13:15:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 1/5
- 通知送信なし
- 次回のチェック 13:16:10
- 13:15:20
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 4/5
- 通知送信なし
- 次回のチェック 13:16:50
- 13:16:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 2/5
- 通知送信なし
- 次回のチェック 13:17:10
- 13:16:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 5/5
- 通知送信
- 次回のチェック 13:22:20
- 次回の通知 13:47:20
- 13:17:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 3/5
- 通知送信なし
- 次回のチェック 13:18:10
- 13:18:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 4/5
- 通知送信なし
- 次回のチェック 13:19:10
- 13:19:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 5/5
- 通知送信
- host1がHARD Downステータスになったので、host1のサービス通知は抑制される
- 次回のチェック 13:24:10
- 次回の通知 13:49:10
- 13:22:20
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 5/5
- host1がHRAD DOWNステータスのため、通知は送信されない
- 次回のチェック 13:27:50
上のシナリオの場合、Nagiosはホストが停止してから約 4分間、ホストがダウンしていたことを知りませんでした。この 4分の間に、Memory UsageサービスがHARD非OKステータスになり、通知が送信されました。
次に、ホストとサービスで異なる監視間隔と試行回数を設定した改善例をみてみましょう。
|
define host{
use windows-server
host_name host1
alias host1
address 10.25.14.51
check_interval 2
retry_interval 1
max_check_attempts 2
notification_interval 30
}
define service{
use local-service
host_name host1
service_description Memory Usage
check_command check_nrpe!CheckMem!ShowAll
type=physical MinWarn=512M MinCrit=256M
check_interval 5
retry_interval 1
max_check_attempts 5
notification_interval 30
}
|
以下は、上の設定をもとにしたシナリオです：
- 13:10:10
- Nagiosがhost1に対してホストチェックを実施
- 結果 = OK
- HARD ステータス
- 試行 1/2
- 次回のチェック 13:12:10
- 13:10:30
- host1が停止
- Nagiosはまだこれを知らない
- 13:10:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 1/5
- 通知送信なし
- 次回のチェック 13:12:20
- 13:12:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 1/2
- 通知送信なし
- 次回のチェック 13:13:10
- 13:12:20
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 2/5
- 通知送信なし
- 次回のチェック 13:13:50
- 13:13:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 2/2
- 通知送信
- host1がHARD Downステータスになったので、host1のサービス通知は抑制される
- 次回のチェック 13:15:10
- 次回の通知 13:43:10
- 13:13:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 3/5
- 通知送信なし
- 次回のチェック 13:15:20
- 13:15:10
- Nagiosがhost1に対してホストチェックを実施
- ホストがダウンしているので、チェックはタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 2/2
- 次回の通知は13:43:10のため通知送信なし
- 次回のチェック 13:17:10
- 13:15:20
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- SOFT ステータス
- 試行 4/5
- 通知送信なし
- 次回のチェック 13:16:50
- 13:16:50
- Nagiosがhost1のMemory Usageサービスチェックを実施
- ホストがダウンしているので、チェックは30秒後にタイムアウト
- 結果 = CRITICAL
- HARD ステータス
- 試行 5/5
- host1がHARD DOWNステータスのため通知送信なし
- 次回のチェック 13:22:20
改善例の方では、NagiosはMemory UsageサービスがHARD非OKステータスになる前に、ホストがダウンした（HARD非OKステータス）となったことを知っています。これにより、サービス通知が抑制されました。
情報源：
- Nagios XI – Intervals – Host vs Service
https://support.nagios.com/kb/article.php?id=504 - Host And Service Check Intervals
http://sites.box293.com/nagios/guides/configurations-and-definitions/host-and-service-check-intervals
ダウンロード（フリー版/評価版）
Nagios XIにはフリー版（最大：７ホスト）と評価版（６０日間、機能制限なし）があります。
インストーラは、Linuxソース版、vSphere/ESX OVFテンプレート版、VirtualPC版の３種類です。ぜひお試しください。
オンラインデモ（Nagios社オンラインデモサイト）
Nagios XI Web GUIをご確認いただけます。
ご希望のアクセスレベルのアカウントを使用してログインしてください。ログインユーザ名/パスワードは以下のとおりです：
- 管理者アクセス： nagiosadmin/nagiosadmin
- 読取専用ユーザアクセス：readonly/readonly
- 上級ユーザアクセス： advanced/advanced
- 一般ユーザアクセス： jdoe/jdoe
お問合せ
購入前のNagios XIについてのお問合せは以下から承っております。
ご不明な点やお気づきの点がございましたらお問い合わせください。
