監視ツールの選び方：自宅サーバーの死活・通知・ログ集約

監視スタックを選ぶ前に、紙に一行だけ書いてください。あなたは何で夜中に起こされたいのか。

それが書けないうちは、Prometheus、Loki、Uptime Kuma、通知サービスを入れても、見る理由のない画面と、鳴らない監視だけが残ります。道具は先ではありません。叩き起こされたい症状を、機械が判定できる条件に翻訳してから、その条件を採れるものだけを置きます。

本記事は「監視と可観測性の実装編」の回収回です。S2最終回のハード部品表が電源・回線・常時稼働の物理側を扱ったのに対し、こちらはソフト側の部品表です。物理側も含めて見直したい場合は、常時稼働・WoL・監視を組み合わせる無人運用の土台を参照してください。

症状を先に書いてアラート条件へ変える

「収集が止まった」「GPUノードが働いていない」「どこか一台のログを探せない」。人間が気づく症状は、そのままでは監視できません。

たとえば「何も進んでいない」は、成果物カウントの増分が20分ゼロ、と書き換えられます。これなら進捗カウンタを15分ごとに見て、原因シグネチャとデバウンスを組み合わせる設計を選べます。

1. 叩き起こされたい症状を自分の言葉で書く。
2. その症状を、機械が判定できる条件へ翻訳する。
3. その条件を採れる道具だけを選ぶ。

採れない条件のために道具を増やしても、監視の穴は埋まりません。今は要らない、と判断するのも部品表の仕事です。

症状・検知条件・取得方法を対応づける

死活・疎通・進捗の3層は、順番に足すものです。同時に買うフルセットではありません。

死活は「止まったら困る」サービスができた時点で必要になります。まずは、Uptime Kumaの死活監視：DownとNotify失敗を実際に起こして見るのように、Downだけでなく通知失敗も含めて確認します。

約18ノードで必要になったsyslog集約

ノードが10台を超えると、ログは「あるが探せない」ものに変わります。そこで約18ノードからsyslogを一か所へ転送し、送信元別・月別のファイルとして保存する構成にしました。

受信側にはsyslog受信デーモンを置き、共有ストレージへ送信元別・月別に保存します。送信側は各ノードに転送設定を置き、*.infoを集約先へ送る一般形です。journaldからの転送も、既定値に頼らず明示的に有効化します。

AppArmorでログが完全に沈黙する

非特権コンテナでは、AppArmorのプロファイルがjournaldからログデーモンへのソケット送信をDENYする場合がありました。denialはホスト側の監査ログにだけ出て、ゲスト内からは何も見えません。プロファイルをcomplainモードにして再ロードする方法で回避しました。

設定の外側にあるパーミッション

あるノードではルートディレクトリのパーミッションが700になっていました。非rootのログデーモンはパスを走査できず沈黙します。755へ戻すと復旧しました。設定を何度も見直しても直らないとき、犯人は設定の外にいることがあります。

ジャーナル直読で起きる履歴の再生

ソケット経由が止まる場合、ジャーナルファイル直読へ切り替えられます。ただし、過去のメッセージを無視する指定を忘れると、全ジャーナル履歴が再生されます。実際に集約先へ大量に流れたため、すぐ停止しました。状態ファイルを書ける作業ディレクトリも必要です。

NASの受信機能を過信しない

家庭用NASの「ログ受信」機能は、汎用syslogサーバではないことがあります。受信機能があることと、一般的なsyslogを保存できることは別です。最初に一行だけ流し、保存先で確認してください。ログ配管の失敗を先に観測する考え方は、Loki+Promtailを家庭ラボに入れる前に「ログが流れない」失敗を作って観測するとも共通しています。

起動ログではなく、送信元ごとのマーカーで確認する

ログ集約の完了判定は、デーモンの起動メッセージでは行いません。各送信元から、そのノードでしか出ない一意なマーカーを一行流し、受信側で全文検索して着弾を確認します。

ログデーモン自身の起動メッセージは内部生成です。journaldの経路が死んでいても、起動ログだけは届く場合があります。受信側にそのノードらしい行が見えても、そのノードのログが流れている証明にはなりません。

「デーモンが動いている」は「パイプラインが通っている」の証明ではありません。

死活・通知・進捗・ログを症状順に導入する

監視スタック一式を最初の週末に立てる、鳴らす条件を決めずにダッシュボードを作る、通知を試験しない、誤検知を放置する。これらは避けてください。

製品名より先に検知条件を書く

自宅サーバー監視で何を入れるかの答えは、製品名やスタック名からは始まりません。「何が起きたら自分を起こすか」を書き、その症状を検知条件に変え、その条件を取れる道具だけを採用します。

死活から始め、通知経路を検証し、必要になってから進捗とログ集約を足す。この順番なら、監視は飾りではなく運用の判断材料になります。マーカーが受信側へ着弾するまで、経路は完成していないと扱ってください。