自宅サーバー監視を死活・疎通・進捗の3層で設計する

自宅サーバーやGPUノードを無人で動かしていると、「壊れたら気付けない」ことが最初の不安になります。通知を入れ、画面を用意し、プロセスが落ちたときに知らせる。そこまでは重要です。

ただし、監視が正常を示していても、仕事が進んでいるとは限りません。

前シーズンでは、無人運用で起きた停止、見かけだけの正常値、資源の詰まりを事件として記録しました。たとえばGPUノードは16時間止まっていても、プロセスの存在や通信だけでは異常を十分に示せませんでした。そこで嘘をつかなかったのは、成果物が単位時間あたり増えていない、という進捗でした。まずはホームラボAIの無人運用シーズンで扱った不安を、実装可能な判断基準へ戻していきます。

S3「監視と可観測性の実装編」で扱うのは、監視ツールを増やすこと自体ではありません。監視がどこまで真実を伝え、どこから見逃すのかを確かめることです。

監視は3層に分ける

ホームラボの状態は、少なくとも次の3層に分けて考えると整理しやすくなります。

死活監視は「死んだら気付く」ための層です。Downと通知失敗を実際に起こした死活監視の記録は、この層を作る際の出発点になります。

疎通監視は、その次です。プロセスが存在するだけでなく、ポートが開き、APIが応答することを確かめます。テレメトリーを運ぶ配管については、OpenTelemetry Collectorで「流れないtelemetry」を観測した記録が役に立ちます。

しかし、死活と疎通がともに正常でも、処理が止まることはあります。AIエージェント群やGPUノードでは、待機、詰まり、無言の停止があり得ます。そこで必要になるのが進捗監視です。成果物、完了件数、キューの減少など、運用対象に合った「前進」を測ります。

「生きているか」を測っても、「働いているか」は分かりません。ここが可観測性をホームラボへ持ち込む理由です。

無言停止の事例を監視条件へ変える

前シーズンで扱ったのは診断でした。何が壊れ、なぜ通常の表示だけでは見落としたのか。S3では、その宿題を実装の問いとして順番に扱います。

1. 何を測るか
2. その計測は信じられるか
3. 誰が鳴らすか
4. 鳴りすぎ・鳴らなさすぎをどう扱うか
5. 何を先に見るか
6. で、結局何を入れるか

GPUが無言で止まった事例からは、「状態ではなく進捗を監視する」という宿題が残りました。S3 e1では、その進捗をどのように定義して実装するかを扱います。

残量が99%と表示されながら実エラーが起きた事例からは、「監視値と実エラーが矛盾したら、実エラーを信じる」という宿題が残りました。S3 e3では、古くなった値を正常として扱わないための鮮度ゲートを扱います。

また、回線では帯域だけを見ても十分ではありません。10G回線でも実効値が約3Gにとどまり、外側のポートが約240まで増えた記録が示したのは、資源には先に詰まりを示す指標があるということです。S3 e8では、回線側の先行指標を扱います。

死活・疎通の上に進捗指標を足す

死活監視やテレメトリーの配管を否定する必要はありません。むしろ、どちらも必要です。ただし役割を混ぜないことが重要です。

• 死活監視は、落ちたことを知らせる。
• 配管は、観測した値を運ぶ。
• 進捗監視は、運用対象が成果を出しているかを問う。

既存の仕組みがあれば、まずはその上に「進んだか」を一つ追加するのが現実的です。すべてを一度に作り替える必要はありません。

この考え方は、バックアップにも通じます。バックアップが存在するだけでは復元可能性は分からず、実際に復元を確かめて初めて監視の意味が生まれます。復元失敗とprune候補を先に見る検証は、表示を信じ切らずに確かめる姿勢の別の実例です。

無人運用の土台がまだない場合は、先に常時稼働・WoL・遠隔・監視を組み合わせる考え方を整理しておくとよいでしょう。監視は、運用の代わりにはなりません。運用の穴を見つけるための装置です。

監視をどの層まで実装するか

死活監視だけで始めることには利点があります。導入の負荷が小さく、停止を見逃す確率をすぐ下げられるためです。一方で、正常表示に安心しすぎると、処理が止まったまま時間だけが過ぎます。

進捗を定義できないなら、急いでメトリクスを増やすより、「この処理が成功したと言える瞬間は何か」を書き出す方が先です。ファイルが増えることなのか、件数が完了することなのか、復元検証が通ることなのか。対象によって答えは異なります。

運用対象ごとに3つの問いを置く

最後に、いまの環境を3層で数えてみてください。

• 死活：落ちたプロセスやサービスに気付けるか。
• 疎通：必要な入口から到達でき、応答を確かめられるか。
• 進捗：一定時間、成果物や完了件数が増えなければ気付けるか。

持っていない層があるなら、それは欠点ではなく、次に作る場所です。死活がなければ既出の死活監視から始める。配管が不安ならテレメトリーの流れを確認する。死活と疎通があるのに仕事が止まるなら、S3 e1の進捗監視へ進む。

S3の最終回では、各話の判断を一枚のチェックリストへ畳みます。それまでの各回では、設定例だけで終わらせず、壊れ方と見逃し方を確認します。

監視は入れた瞬間から嘘をつき始めます。値が古いかもしれない。通知が届かないかもしれない。正常という表示が、仕事の停止を隠すかもしれない。

だから必要なのは、監視を足す手順だけではありません。自分の監視を疑う手順です。所長にも読者にも、通知があることではなく、必要なときに前進を確認できることを残します。

1つのサービスへ死活・疎通・進捗の3検査を置く

最小構成では、同じ対象へ異なる問いを3つ投げます。以下はsystemdサービス、HTTP health、成果物ディレクトリを例にした確認です。パスと許容時間は自分の処理へ合わせます。

systemctl is-active --quiet my-worker.service
curl -fsS --max-time "$HEALTH_TIMEOUT_SECONDS" https://worker.example.com/health > /dev/null
latest=$(find "$RESULT_DIR" -type f -printf '%T@\n' | sort -n | tail -1)
now=$(date +%s)
age=$(awk -v now="$now" -v latest="$latest" 'BEGIN {printf "%d", now-latest}')
printf 'latest_result_age_seconds=%s\n' "$age"
test "$age" -le "$MAX_PROGRESS_AGE_SECONDS"

死活失敗: unitがinactive
疎通失敗: health endpointへ到達不能
進捗失敗: unitとHTTPは正常だが成果物時刻が進まない

GPUノードでは最初の2層が正常でも16時間成果物が増えませんでした。三つを一つの総合ランプへ潰さず、どの層で止まったかを通知に残すと、再起動・ネットワーク確認・処理内容の調査を選び分けられます。