とことこロゴス
メニュー

死活監視

読み：しかつかんし　／　英語表記：liveness monitoring

応答の有無や内容、定期通知の受信状況を基に、機器やサービスの稼働状態を継続的に確認する監視である。確認方法と判定条件を決め、利用できなくなった兆候の検出と通知につなげる。

イマシルちゃんの解説

サーバが止まっても、利用者から連絡が来るまで気付けなければ対応が遅れてしまうね。
死活監視は、機器やサービスが動いているかを継続的に確かめる監視だよ。
例えば一定間隔で確認の通信を送り、決めた時間内に返事が届くかを調べるんだ。
ただ、一度返事が来なかっただけでは、サーバの停止なのか途中の通信の問題なのかは分からないよ。
だから、何回続けて失敗したら知らせるかや、どこから確かめるかも決めておくの。
異常に早く気付き、どこを調べるべきか判断するための手掛かりを得られるんだよ。

より深い解説

何が使える状態かを決める

死活監視は、対象の機器やサービスから期待する応答が得られるかを継続的に確認する。異常を見つけて担当者へ知らせたり、ロードバランサの振り分け先を判断したりするために使う。

最初に決めるのは、何を確認できれば「正常」と判断するかである。Webサーバを監視する場合も、IP通信が往復できること、接続を受け付けること、必要な処理が成功することでは確認の深さが異なる。対象の状態を試す確認処理をヘルスチェックという。

確認方法確かめることその結果だけでは分からないこと
pingによるICMPのエコー要求・エコー応答その確認通信が対象との間で往復できるかWebアプリケーションが正常に処理できるか
設定したポート番号へのTCP接続対象が接続を受け付けられるか接続後のログインやデータ取得が成功するか
HTTPで指定URLへ要求期待したHTTPステータスコードや本文が返るかそのURLで確認していない機能まで正常か

例えばWebアプリケーションだけが停止しても、OSが動いていればpingに応答することがある。反対にICMPが遮断されていても、Webアプリケーションは利用できる場合がある。注意：監視の成功が示すのは、選んだ通信と確認条件がその時点で成立したことまでである。

HTTPの監視では、正常とするHTTPステータスコードや応答内容を設定する。/healthへ要求する構成でも、その処理がデータベースへの接続まで確認するかはアプリケーション次第である。HTTPSを使う場合はTLS接続や証明書の検証も関係する。利用者が必要とする機能に合わせて、何を確認対象に含めるかを決める。

通信の段階ごとの具体的な要求と応答は次のようになる。

段階送るもの確認するもの
IPの到達性ICMP Echo Request（エコー要求）対象からのICMP Echo Reply（エコー応答）
TCPの待受け接続を開始するSYN接続要求を受け付けるSYN/ACK。接続方式の監視では最後のACKまで交換する
HTTPの機能指定URLへのGETなどステータスコード、本文、応答時間が期待する条件に合うこと

TCPのRSTが返れば、その接続が拒否されたことを判断できる。無応答の場合は対象の停止だけでなく、経路やファイアウォールの遮断も候補になる。SNMPに対応していない機器でも管理用IPアドレスがICMPに応答するなら、pingによる監視は可能である。ただしポートごとの詳細な状態までは取得できない。

HTTPの機能まで調べる監視はレイヤー7のヘルスチェックに相当する。例えば監視専用のパス /status へGETを送り、200 OKと期待する本文が返ることを成功条件にする。ただし200がすべての業務機能の正常を意味するわけではない。認証画面へのリダイレクトやエラー内容を200で返す実装もあるため、パス、Hostヘッダー、期待するコードと本文を具体的に決める。

問い合わせる方法と通知を待つ方法

監視側が一定間隔で対象へ問い合わせる方式をポーリングという。pingやTCP接続を繰り返すほか、SNMPで機器の状態を取得する構成でも使われる。監視側で確認の時刻と結果を管理できるが、対象台数や頻度が増えると通信と処理の負荷も増える。

一方、対象が稼働していることを知らせるために定期的に送る通知をハートビートという。受信側は、決めた期間内に通知が届き続けているかを確認する。冗長構成の装置同士や、機器と管理サーバの間などで利用する。

ハートビートが途絶えた場合も、対象が停止したとは限らない。対象から受信側までの経路が切れた場合や、受信側の処理が止まった場合にも届かなくなる。また、その通知を送る処理だけが動いていて、別の業務処理が停止している可能性もある。

状態の変化などの事象を知らせるSNMPのTrapやログは、定期的な生存確認とは役割が異なる。突然電源を失えば、対象が停止を知らせる余裕はない。異常の通知が来ないことを、対象が動いている証拠にはしない。 定期的な確認と事象の通知を組み合わせて、見落としを減らす。

検出の速さと誤判定の少なさを両立させる

応答を待つ監視では、少なくとも次の三つを区別して設定する。

設定項目決めること値を小さくしたときの傾向
監視間隔次の確認を始めるまでの間隔早く異常を発見しやすいが、問い合わせの負荷が増える
タイムアウト一回の確認で応答を待つ上限時間無応答を早く判定できるが、遅い正常応答も失敗にしやすい
連続失敗回数何回続けて失敗したら異常にするか検出は早まるが、一時的な損失や遅延の影響を受けやすい

独自の例として、確認の開始時刻を10秒間隔に固定し、一回の応答待ちを2秒、異常とする条件を3回続けての失敗とする。0秒に正常な応答を確認した後、1秒に対象が停止し、以降は全く応答しないものとする。

時刻起きること判定
0秒正常な応答を確認する正常
1秒対象が停止する次の確認までは分からない
10秒 → 12秒最初の確認で応答を得られない失敗1回
20秒 → 22秒次の確認でも応答を得られない失敗2回
30秒 → 32秒三度目も応答を得られない異常を検出する

この例では、停止から検出までに31秒かかる。監視間隔だけを見て「10秒で検出する」とは判断できない。実際の時間は、障害が起きる時刻、応答の待ち方、再試行や監視処理の遅れにも左右される。確認の終了から次の開始までを一定時間空ける実装では、この表とは時刻が変わる。

正常へ戻す条件も決める。例えば異常後に2回続けて成功したら正常へ戻すように、復旧判定用の連続成功回数を設ける。正常と異常が短時間に繰り返し切り替わる状態をフラッピングという。通知や振り分け先の変更が頻発しないようにする一方、安定して戻ったサービスの再利用を遅らせすぎない値を選ぶ。

監視する位置で見える状態が変わる

監視結果は、対象だけでなく監視元と通信経路にも左右される。監視サーバとWebサーバが同じLANにあれば正常でも、利用者が通る拠点間回線が切れていれば、その利用者はWebアプリケーションを使えない。

確認する位置や対象調べる目的
対象と同じ拠点の監視元対象に近い範囲で応答できるかを確認する
利用者に近い位置の監視元利用者が通る経路を含めて確認する
対象へ向かう途中のルータ複数の対象に共通する障害を探す
監視サーバや通知経路監視や連絡自体が止まっていないかを確認する

一つの回線断で、その先の機器すべてが無応答になることもある。接続関係から機器間の依存関係を把握し、共通する原因を調べる。複数の監視元から確認すると判断材料を増やせるが、同じ回線や電源に依存していれば同時に確認できなくなる可能性は残る。

検出後の対応とほかの監視につなげる

異常を検出したら、対象、発生時刻、確認方法、失敗理由などをアラートとして担当者へ知らせる。誰へどの手段で連絡するかを決め、復旧時の通知や計画作業中の通知の扱いも用意する。原因の切り分けから復旧までの進め方は、障害管理の記事で扱う。

ロードバランサでは、ヘルスチェックの結果を処理先の選択に利用できる。冗長構成で予備側へ切り替えるフェイルオーバーにも監視結果を使う。ただし、異常を検出する機能と切替えを行う機能は別であり、監視を始めただけでサービスが自動復旧するわけではない。

死活監視は応答できるかを捉えるのに向くが、停止に至る前の余裕まで十分に分かるとは限らない。応答時間やCPU使用率、回線使用率などの変化を調べる性能監視や、エラーなどの記録を調べるログ監視を組み合わせると、異常の兆候と原因を判断しやすくなる。SNMPやSyslogの詳しい仕組み、pingの操作方法は、それぞれの記事へつなげて理解するとよい。

参考資料

実際の試験ではここに出る！全5問

ネットワークスペシャリスト

午後Ⅱ
午後Ⅰ

この用語が出てくる記事

↑