死活監視

🐾 猫で例えると？

頭に前足を添えて眠る茶トラ。この姿を見て「休んでいるのかな」と様子を確かめるように、ITでも対象の状態を確認します。ただし、プロセスが動いていることと、利用者の要求を処理できることは別です。何をもって正常とするかを決め、確認用の応答や内部状態を調べるのがヘルスチェックです。

💻 IT現場における「死活監視」とは？

死活監視は、システムの安定稼働を支える運用の要です。サーバーがダウンした際、エンジニアがユーザーからの苦情で気づくのではなく、システム側が自動で検知してアラート（通知）を飛ばすために行われます。

監視の対象は、サーバーのOSレベル（Pingが通るか）、ミドルウェアレベル（Webサーバーが動いているか）、アプリケーションレベル（特定のAPIが正しい値を返すか）など、複数のレイヤーに分かれています。これらを組み合わせることで、「サーバーは動いているが、画面が表示されない」といった微細な異常も発見できるようになります。

⚠️ 死活監視の仕組みと注意点

一般的な死活監視には、主に以下の手法が使われます。

• Ping監視（L3）： ICMPパケットを送り、応答があるか確認します。
• ポート監視（L4）： HTTP(80/443)やDB(3306)などのポートが接続可能か確認します。
• HTTP/URL監視（L7）：期待するステータスや本文、応答時間を確認します。200が返るだけでは、ログインや保存などの機能が正常とは限りません。

監視スクリプトの例

Bashとcurlがある環境で、指定したURLのHTTP応答だけを調べる例です。接続と全体の待機時間に上限を設け、通信失敗と想定外のステータスを分けています。

if status=$(curl --connect-timeout 3 --max-time 10 -sS -o /dev/null -w "%{http_code}" https://example.com); then
  if [ "$status" = "200" ]; then
    echo "HTTP 200を確認"
  else
    echo "想定外のHTTPステータス: $status"
  fi
else
  echo "通信に失敗（DNS・TLS・タイムアウトなどを確認）"
fi

Kubernetesでは、再起動を判断するliveness、トラフィックを受けられるか見るreadiness、起動完了を見るstartupのプローブを区別します。DBの一時障害を理由に全コンテナを再起動させるなど、確認と対処の組み合わせを誤ると障害が広がることもあります。

🛠️ 死活監視を賢く運用するためのポイント

ただ監視するだけでなく、誤検知を防ぎつつ確実に異常を捉える工夫が必要です。

• しきい値と検知時間を決める：連続失敗の回数を増やすと一時的な揺れに強くなりますが、検知は遅れます。監視間隔、タイムアウト、許容停止時間を合わせて決めます。
• 依存関係の考慮： ネットワークの入り口が死んでいる時に、その先のサーバー100台分のアラートを一斉に鳴らさない（依存関係の定義）ように設定します。
• 外形監視の導入： サーバーの中からではなく、インターネット越し（ユーザーと同じ経路）で監視することで、より正確な利用状況を把握できます。

猫の食欲と動きのどちらを見るかで分かることが違うように、ヘルスチェックも確認内容によって意味が変わります。Pingに応答してもログインや保存が成功するとは限りません。何を異常と判定し、通知や切り離しにつなげるかを目的ごとに決めましょう。