監視スタックを選ぶ前に、紙に一行だけ書いてください。あなたは何で夜中に起こされたいのか。
それが書けないうちは、Prometheus、Loki、Uptime Kuma、通知サービスを入れても、見る理由のない画面と、鳴らない監視だけが残ります。道具は先ではありません。叩き起こされたい症状を、機械が判定できる条件に翻訳してから、その条件を採れるものだけを置きます。
本記事は「監視と可観測性の実装編」の回収回です。S2最終回のハード部品表が電源・回線・常時稼働の物理側を扱ったのに対し、こちらはソフト側の部品表です。物理側も含めて見直したい場合は、常時稼働・WoL・監視を組み合わせる無人運用の土台を参照してください。
症状を先に書いてアラート条件へ変える
「収集が止まった」「GPUノードが働いていない」「どこか一台のログを探せない」。人間が気づく症状は、そのままでは監視できません。
たとえば「何も進んでいない」は、成果物カウントの増分が20分ゼロ、と書き換えられます。これなら進捗カウンタを15分ごとに見て、原因シグネチャとデバウンスを組み合わせる設計を選べます。
- 叩き起こされたい症状を自分の言葉で書く。
- その症状を、機械が判定できる条件へ翻訳する。
- その条件を採れる道具だけを選ぶ。
採れない条件のために道具を増やしても、監視の穴は埋まりません。今は要らない、と判断するのも部品表の仕事です。
症状・検知条件・取得方法を対応づける
| 症状 | 検知条件 | 何で採るか | 該当話 | 層 |
|---|---|---|---|---|
| プロセスは生きているのに何も進んでいない | 成果物カウントの増分が20分ゼロ | 15分ポーリング、原因シグネチャ、デバウンス | e1 | 進捗 |
| ダッシュボードが「No data」になる | 受信カウンタ、メトリクス名、保存済みダッシュボードを順に確認 | 受信カウンタ、or vector(0)、冪等配備 |
e2 | 疎通 |
| グラフが規則正しく振動する | 観測時刻が古い | 値とobserved_atを組で返し、staleなら空／失敗 |
e3 | 進捗（計測系） |
| ジョブは成功しているのに成果がない | 連続SKIP N回、または最終成功からN時間 | SKIPのイベント化、ストリーク、鮮度 | e4 | 進捗 |
| 監視は正常と言うが、実際には死んでいる | プロセスが実在するか | プロセス実在確認、完了マーカー、タイムアウト | e5 | 死活 |
| 正常なのに定期的に警報が鳴る | 誤検知が出ている | 下位状態と残作業でガード | e6 | 横断 |
| 全体は正常だが一部だけ滞留する | 粒度を割った単位での滞留時間 | レーン別・ジョブ別のパネル | e7 | 進捗 |
| 回線や上流が落ちてから気づく | 上流の先行指標が閾値を超える | ルータの軽量メトリクス取得 | e8 | 予兆 |
| どのノードの障害か分からず、ログを探せない | 各ソースのマーカーが受信側に着弾するか | 送信元別のログ保存と一意タグによる検証 | e9 | 基盤 |
死活・疎通・進捗の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の経路が死んでいても、起動ログだけは届く場合があります。受信側にそのノードらしい行が見えても、そのノードのログが流れている証明にはなりません。
「デーモンが動いている」は「パイプラインが通っている」の証明ではありません。
死活・通知・進捗・ログを症状順に導入する
| 困っている症状 | 最初に入れる監視 | 導入条件 | 見送る条件 |
|---|---|---|---|
| 一台でも止まると困る | 死活監視 | 常時動かすサービスがある人 | まだ止まって困る対象がない人 |
| 通知が届くか不安 | 通知経路の検証 | 通知を運用判断に使う人 | 通知先をまだ決めていない人 |
| 処理が動いているか不明 | 進捗監視 | 完了数や鮮度を持つ処理がある人 | 成果物を定義できていない人 |
| ログを一台ずつ探す時間が増えた | syslog集約 | ノードが10台を超えた人 | まだ個別確認のほうが速い人 |
| 原因を絞れない | メトリクス基盤・トレース | 性能やデータ経路を調べる必要がある人 | 検知条件が未定の人 |
監視スタック一式を最初の週末に立てる、鳴らす条件を決めずにダッシュボードを作る、通知を試験しない、誤検知を放置する。これらは避けてください。
製品名より先に検知条件を書く
自宅サーバー監視で何を入れるかの答えは、製品名やスタック名からは始まりません。「何が起きたら自分を起こすか」を書き、その症状を検知条件に変え、その条件を取れる道具だけを採用します。
死活から始め、通知経路を検証し、必要になってから進捗とログ集約を足す。この順番なら、監視は飾りではなく運用の判断材料になります。マーカーが受信側へ着弾するまで、経路は完成していないと扱ってください。
この検証を回している環境
この検証は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →
