自宅サーバー監視の設計図：死活・ログ・通知・進捗を11事例で切り分ける

監視ツールを増やす前に、いま困っている症状を一つ選んでください。この記事は11事例の全文集ではなく、症状から観測面と次に読む記事を選ぶ診断ハブです。公開中の個別記事があるテーマはそちらを正本とし、独立記事がない検証だけ、当時の実測の核を短く残します。

最初の分岐：止まったのか、届かないのか、進んでいないのか

独立記事がない検証は、観測点だけ残す

時刻ずれ：通知時刻より、比較している時計を確認する

時刻同期の検証では、単にNTPサービスの起動状態を見るのでは足りませんでした。ログの発生時刻、集計側の現在時刻、期限判定に使うタイムゾーンが別々なら、正常な処理を遅延と誤判定できます。切り分けでは各面のUTC時刻を同じ行に出し、差を確認します。

ログ配送：起動済みと着弾済みを分ける

Loki/PromtailとVectorの検証で残った核は同じです。コンテナがUpでも配送完了ではありません。送信元から一意なマーカーを1行流し、収集先でその文字列を検索できて初めて着弾と判断します。設定変更後に既存コンテナが設定を読み直さなかったケースもあったため、再作成の有無も観測対象です。

通知：HTTP成功と、意図したtopicへの到着を分ける

ntfyの隔離検証では、認証拒否は401として観測できました。一方、誤ったtopicを読むとリクエスト自体は成立しても中身が空です。送信HTTPの成否だけで終えず、受信側で一意な本文を読むところまでを一組にします。

死活：Uptime KumaのDownと通知失敗を別の故障として扱う

監視対象の停止と通知先の停止は、復旧手順が違います。対象がDownになること、通知受け口を止めると通知が届かないことを別々に起こし、監視画面の状態と通知先の着弾を分けて記録しました。

状態ファイル：古いrunningを現在の稼働と読まない

状態ファイルが9日間runningのまま残った事例では、値そのものより更新時刻が欠けていたことが死角でした。PID、プロセス開始時刻、状態ファイルの更新時刻を照合し、古い自己申告を現況として扱わないようにします。

同期ジョブ：停滞と通知重複を別々に数える

同期の監視では、最終成功時刻だけだと「仕事がない」と「止まった」を区別できません。入力の増分、処理済みの増分、直近通知の識別子を分けると、停滞判定と同じ警告の連投を切り離せます。

監視を追加する順番

1. 読者が困っている症状を一つ決める。
2. 死活・疎通・進捗・鮮度・着弾のどれを見るか決める。
3. 正常時の値と更新時刻を一度保存する。
4. 故障を一種類だけ起こし、期待した面が変わるか確認する。
5. 通知が届いたことではなく、復旧後に値が再び増えるところまで確認する。

監視ツールの台数ではなく、故障時にどの観測面が変わるかが設計の中心です。まず3層の整理から始め、症状が具体化したら個別記事へ進んでください。