「生きているか」ではなく「働いているか」——自宅サーバー監視を実装する

ガジェット・周辺機器を描いたアイキャッチ画像

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

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

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

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

目次

監視は3層に分ける

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

問い 分かること 正常でも残る見落とし
死活 プロセスは生きているか 落ちた・再起動した 動いているが処理が止まっている
疎通 ポートやAPIは応答するか 外から到達できる 応答するが期待した仕事をしていない
進捗 単位時間に成果物が増えたか 実際に仕事が前へ進んでいるか 成果物の定義や観測自体が誤っている

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

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

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

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

S2の事件簿から、実装の問いへ

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

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

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

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

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

既出の仕組みの上に、進捗を置く

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

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

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

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

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

いま選ぶなら、どこまで持つべきか

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

選択肢 向いている人 向かない人 メリット デメリット
死活監視だけ まず停止通知を持っていない人 無人ジョブの完了が重要な人 早く始められる 無言停止を見落としやすい
死活+疎通 外部から使うサービスを運用する人 成果物の増加を見なければ判断できない人 到達不能を切り分けやすい 応答と成果を混同しやすい
死活+疎通+進捗 AI処理、バックアップ、定期処理を無人化する人 進捗の定義をまだ決められない人 「働いているか」を判断できる 対象ごとに成果物の定義が必要
まだ追加しない 運用対象や失敗時の対応を整理中の人 すでに無人処理を任せている人 過剰な通知を避けられる 見逃しのリスクは残る

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

自分の監視を数える

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

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

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

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

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

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

この検証を回している環境

この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。

ラボ構成のまとめを見る →
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次