自宅 Observability の完全ガイド — Prometheus + Grafana + Loki で家のサーバとネットワークを観測し続ける

自宅 Observability とは、自宅にある仮想化基盤・ネットワーク機器・公開サービス・スマートホームまでを、メトリクスとログとトレースで継続的に観測し、障害を予兆段階で捉え続けるための実践のことです。本ページは、Prometheus + Grafana + Loki を中核に据えた監視基盤を自宅ラボで運用しながら積み上げてきた構築判断・観測対象設計・複合障害の教訓・監視自体の運用までを 1 ページに集約した Pillar ガイドです。各章から個別の深掘り記事へ辿れる導線にしてあります。

このページの位置づけ

ちらりんブログには 自宅サーバ運用の完全ガイド という姉妹 Pillar があります。あちらは「物理 → 公開 → アプリ → 監視 → 運用」の全体像をカバーした総合ガイドで、自宅サーバの構築判断を入口から出口まで一気通貫で扱っています。

本ページは、その中の 観測（Observability）レイヤだけを深く切り出した専門ガイド です。「Proxmox の上に何を載せて公開するか」ではなく、「載せたあとに、それを観測し続けるためには何が必要か」を中心に据えています。両者を行き来しながら読むと、構築と運用の両面が立体的に見えるはずです。

なお、ちらりんブログでは AI エージェント運用の原則として「静かに壊れる前提で観察を仕組む」という考え方を採用しています。これは AI が裏でデータをどう拾い、どう判断したかを人間が言語化できる状態を保つための原則ですが、自宅サーバ運用にもそのまま当てはまります。監視は、壊れたあとに気づくための仕組みではなく、壊れているかどうかを継続的に確認するための仕組み です。本 Pillar の通奏低音はこの一文に尽きます。

なぜ自宅で Observability なのか — クラウド型監視と比べる動機

監視 SaaS はすでに成熟しています。Datadog・New Relic・Grafana Cloud・Sentry。どれを選んでもエージェントを入れた瞬間に綺麗なダッシュボードが立ち上がり、しばらくは無料枠で遊べます。それでも自宅で OSS スタックを組む理由は、価格比較表で説明できるものではありません。動機は 3 つあります。

ひとつめは 学習装置としての価値 です。クラウド型は「監視のベストプラクティスをパッケージ化して売る」プロダクトです。これは便利の裏返しで、自分の手で retention 設計・ラベル設計・アラート閾値・ダッシュボード分割を考える経験が削られます。Prometheus を自分の VM に立て、スクレイプ間隔と retention を自分で決め、ストレージが膨らんだら自分でディスクを拡張する。この一連の動作を経験しておくと、業務でエンタープライズ監視基盤のトラブルに遭遇しても発生位置の見当が一瞬で立ちます。

ふたつめは 観測対象の自由度 です。クラウド型は「監視できる対象」が事前に決まっています。Proxmox の VM ステータス・自宅 WAN ルータの SNMP・スマートホームのデバイス状態・自作プロダクトの内部メトリクスを、ひとつのダッシュボードに統合したいという要求は、SaaS では満たせないか、満たせても料金プランの上のほうに置かれます。自宅で完結する Prometheus なら、scrape_configs に対象を増やすだけで良いし、node_exporter や snmp_exporter のような既存 exporter が無償で揃っています。

みっつめは データ主権 です。家の中で起きていることのログを、家の外に送り続けることへの心理的な抵抗。アクセスログ・スマートホームの動作履歴・ライブカメラのストリーミング状態など、家庭内のセンサーデータは性質的に外に出したくないものが多いです。OSS スタックを自宅で動かせば、データは家の外に出ません。

これらの動機は「クラウド型より安いから」ではない点に注意してください。電気代・ストレージ・自分の時間を含めれば、Grafana Cloud の最小プランのほうが安く済むことすらあります。それでも自宅でやる価値があるのは、学習・自由度・主権という、料金表では比較できない価値が積み上がるからです。

監視基盤の設計判断 — Prometheus + Grafana + Loki を選んだ理由

監視 OSS スタックには選択肢が複数あります。Zabbix のような old-school エージェント型、Nagios 系のチェックベース、Elastic Stack のログ中心、TICK スタック (InfluxDB + Telegraf)、そして Prometheus + Grafana + Loki。最終的に後者を選んだ理由は、自宅という規模感に対して最適解だったからです。

Prometheus はメトリクスのスクレイプ・保存・クエリを一手に引き受けるサーバです。Pull 型のアーキテクチャは「監視対象が増えても監視サーバの設定追加だけで済む」「ファイアウォール越えで監視対象側に穴を開けなくて済む」という運用上の楽さがあります。node_exporter をはじめとした exporter エコシステムが豊富で、書きたいものは大抵 GitHub に既にあります。

Grafana はメトリクスとログを同じ画面で可視化できる UI 層です。Prometheus 単体にも Web UI はありますが、ダッシュボードとしての完成度は Grafana が圧倒的です。重要なのは、データソースを Prometheus に限定しないこと。Loki も Tempo も MySQL も、同じ Grafana から横断的に見られます。

Loki はログ集約サーバで、「ログをフルテキストインデックスしない、ラベルだけインデックスする」という割り切りが特徴です。Elasticsearch のような重量級と比べて圧倒的に軽く、自宅の小規模監視 VM でも余裕で動きます。Grafana との統合も滑らかで、メトリクスのスパイク時刻からそのままログにジャンプできます。

設計段階で意識したのは、「全部入りプラットフォーム」を避ける ことでした。メトリクス・ログ・ダッシュボードを 1 プロダクトで賄うと、どれかが弱点になるか、肥大化してリソースを食います。責務を分けた 3 つを組み合わせるほうが、後方互換性も保たれやすく長期運用に向きます。

設計思想と全体像、なぜ Zabbix や Datadog ではなくこの構成にしたかの判断軸は Chillarin Blog 構成紹介 - 8.監視基盤編 Part1（設計思想と全体像） で詳しく整理しました。これから自宅監視を始める人が最初に読むべき記事です。

構築の現実 — VM 配置・ストレージ設計・retention の決め方

設計思想が決まったら、次は「どこに何を置くか」の物理的な構築です。ここでつまずきがちなポイントが 3 つあります。

ひとつめは 監視 VM の配置場所 です。Proxmox クラスタの中で、監視 VM を「監視対象と同じ物理ホストに置く」と、そのホストが落ちた瞬間に監視も一緒に落ちます。これは観測ギャップの最も古典的な失敗で、ホスト障害を検知すべき監視がホスト障害と運命を共にする構図です。3 台クラスタなら、監視 VM はクラスタ内で最も「停めたくない」プロダクション系とは別ノードに置く、というのが基本指針です。

ふたつめは ストレージ設計 です。Prometheus は TSDB を書き続けます。スクレイプ間隔と retention と監視対象数の積で必要量が決まり、対象を増やすと簡単に数十 GB に膨らみます。Loki のログ保存と Grafana の SQLite を含めて、監視 VM のディスクは「想定の倍は用意する」くらいで丁度よいです。後述する「ディスクフル 4 重奏」もこの油断から来ました。

みっつめは retention 期間の決め方 です。「永久に保存」は現実的でなく、短すぎると振り返り分析ができません。メトリクスは 30〜90 日、ログは 14〜30 日が自宅規模での実用範囲です。長期保存は Thanos や Mimir のような remote storage に追い出す選択肢もありますが、自宅では過剰投資です。「ローカルは割り切って短く、必要なら NAS に定期スナップショット」という運用に落ち着きました。

これらの構築判断、docker-compose.yml の構造、リバースプロキシ経由でのアクセス、Grafana の初期セットアップなどは Part2（構築手順編） に手順込みで残しました。設定ファイルの具体的な値や、コピペで動く docker-compose.yml 全量については、シリーズ記事と有料コンテンツを参照してください。

観測対象 — Proxmox・WAN・アプリ・スマートホームまで

監視基盤を立てたら、次はどこに何を観測しに行かせるかを決めます。自宅 Observability で観測対象になりうるレイヤを、ちらりんブログの構成で実際に動いている範囲で並べると次のようになります。

Proxmox クラスタ が一番下のレイヤです。VM・LXC の起動状態、ホストの CPU・メモリ・ディスク IO、クラスタ HA の状態、ストレージプールの使用量。これらは pve-exporter や node_exporter で取れます。とくに重要なのは「VM が ON のはずなのに OFF になっている」を検知するクエリで、Proxmox API から状態を引いてアラート対象にしています。後述する複合障害は、この「動いているはずが動いていない」を検知できなかったことが核心でした。

自宅 WAN は意外と盲点になりがちな観測対象です。家のインターネット回線が瞬断する・速度が落ちる・特定の時間帯に詰まる、といった事象は ISP のせいなのかルータのせいなのかケーブルのせいなのか、肌感覚では判別できません。Cisco ルータの SNMP を Prometheus に取り込み、回線インタフェースの flap カウントとリンク状態を継続記録する、という地味な観測が大きな価値を生みました。詳細は 家のWAN回線がぽろぽろ落ちる原因を Prometheus + Grafana で見える化した でまとめましたが、「壊れていることに気づくための監視」の典型例です。

アプリケーション層 はブログ本体・コメント基盤・自作プロダクトなど。Hugo は静的サイトで CPU を食いませんが、Cloudflare Tunnel・ライブ配信・ストリーミング機材は意外と落ちます。Docker コンテナの状態と再起動回数、HTTP 応答時間、Tunnel 接続数を Prometheus で見ています。

スマートホーム は趣味と実用が混在する領域です。エアコン制御・温湿度センサー・室内カメラの状態。Home Assistant や独自プロダクトから Prometheus へメトリクスをエクスポートして、リビングの気温と機械学習推論ジョブの実行状況を並べて見られるようにしています。「家の中で何が動いているか」を一画面で把握できる体験は、SaaS では作れません。

ダッシュボードの設計、何を 1 画面にまとめるか、どこで切り分けるか、運用 1 年で見えてきた知見は Part3（ダッシュボード設計と運用知見） に整理しました。「監視を入れたあとに、どう見るか」の話です。

観測ギャップから生まれた複合障害 — 監視を入れただけでは足りない

監視を入れていても、観測の網に穴があると障害は静かに進行します。実際にあった代表例が、ある朝「VM がひとつも起動しない」事象でした。

このときの根本原因は単一ではありませんでした。NIC ドライバ（e1000e）の特定状態・NFS マウントのタイミング依存・監視のカバレッジ漏れという 3 つが同時に刺さりました。技術的な原因については VMが起動しない日の話 — e1000e・NFS・監視ギャップが同時に刺さった複合障害 で時系列とともに残しましたが、Observability の文脈で振り返ると、教訓は次の 3 点です。

第一に、監視カバレッジは「設計時の想定」と「実際の障害モード」が必ずズレます。VM の up/down は監視していました。しかし「VM が起動しようとして失敗している」遷移状態は監視していませんでした。サービスが止まっていたのに、Grafana のダッシュボードは「VM 数: 0」を平然と表示していて、これは仕様通りの挙動でしたが、人間にとっては「監視が機能していない」のと同じです。

第二に、メトリクスとログをセットで見られる状態を作っておくことの重要性です。Prometheus のメトリクスだけ見ていると、「VM が落ちた」事実はわかっても「なぜ落ちたか」がわかりません。Loki に Proxmox ホストの journalctl を流し込んでおいて、Grafana から「メトリクスのスパイク時刻のログ」に 1 クリックで飛べる導線を作っておくと、原因切り分けの速度が桁違いに変わります。今回の事故では、この導線があったから NIC ドライバまで辿り着けました。

第三に、冗長化は冗長化されている前提で運用しないこと。HA クラスタを組んでも、それ自体が依存している共有ストレージや NIC ドライバが壊れたら全台が同時に倒れます。監視はこの「同時倒壊」を検知できる位置に置く必要があります。同じノードで動かしていたら、監視も一緒に倒れます。

ここで強調したいのは、複合障害そのものは技術的なミスというより、「監視を入れたつもりで観測ギャップを作っていた」設計上の盲点 が引き起こしたという点です。Prometheus も Grafana も Loki も健全に動いていました。動いていたのに、肝心の障害を検知する形になっていなかった。Observability の仕事は「ツールを動かすこと」ではなく「観測の網に穴を作らないこと」です。

監視自体の運用 — ディスクフル・retention・NAS 退避

監視基盤は「動かしたら終わり」ではなく、それ自身が運用対象です。むしろ、長期運用で一番手を入れた回数が多いのが監視 VM だったというのが正直なところです。

代表的なトラブルが 監視 VM のディスクフル です。Prometheus の TSDB が想定より早く膨らみ、Loki のログ保存が予想を超え、Grafana の sqlite が雪だるま式に増え、さらに OS のシステムログが回らずに溜まる。この 4 種類が同時に効いた結果、ある日 Grafana が無反応になり、調べてみたらディスクが 100% でした。

教訓は明確で、「監視 VM のディスク使用率を、別の監視で見る」 という再帰的な構造が必要です。監視自身が監視できなくなったらアウトです。ntfy や LINE 通知を別経路に逃がしておくこと、/var/lib/docker や /var/log といった伸びやすいパスを個別に dashboards 化しておくこと、そして retention 設定が docker-compose.yml のどの行で効いているかを文書化しておくこと。地味な作業ですが、これをやらないと「気づいたときには手遅れ」になります。

ディスクフルが起きたときの 4 つの原因の重なりと、それぞれの再発防止策については 監視VMのディスクフル原因4重奏 に整理しました。NAS への退避・retention の見直し・ログローテーション設定の再点検と、4 軸での対応が必要だった事例です。

監視自体の運用で意識しているのは次の 3 点です。

1. 監視を監視する経路を別に用意する。Prometheus が落ちたら通知が出ない状況を作らない。シンプルには、外部の死活監視 SaaS (UptimeRobot など) を 1 つだけ無料枠で併用すると保険になります。
2. retention は「短く」「明示的に」決める。「いつか整理する」と思って永久保存にしておくと、必ずディスクフルが先に来ます。
3. データの退避先を最初から決めておく。NAS への退避、コールド保管、必要な期間だけホットで持つ運用設計を、構築時点で書いておきます。

次のステップ — どこまで広げるか

自宅 Observability の終わりはありません。観測対象もダッシュボードも、こだわり始めると終わりません。だからこそ「どこで止めるか」を意識する必要があります。

ちらりんブログでは現状、Proxmox + WAN + アプリ + スマートホームの 4 系統で監視を回しています。次の拡張候補は、(1) アプリ内部メトリクスの拡充（自作プロダクトに Prometheus client を仕込む）、(2) トレーシング層の導入（Tempo + OpenTelemetry で AI 推論の内部時間を可視化）、(3) SLO/SLI の明示化（個人ブログにも SLO を入れアラート精度を上げる）あたりです。

ただし全部やる必要はありません。自宅 Observability の目的は、家にあるシステムを安心して運用し続けること であって、SRE の教科書を再現することではありません。観測のために観測するのではなく、次に取り組みたい新しいプロダクトに集中するために、既存システムが静かに壊れていないことを確認できる状態を保つ。それが本来の目的です。

無料記事として公開しているのは設計判断と教訓です。本番の docker-compose.yml 全量や、Grafana ダッシュボードの JSON、トラブルシューティング集など、再現に必要な素材は会員特典コンテンツとして順次提供しています。詳細は会員ページから確認できます。

自宅 Observability は、誰かが書いたベストプラクティスを並べただけでは動きません。家の物理環境・ISP の事情・運用に避けられる時間・気にしたい範囲、すべてが個別解として絡みます。本 Pillar が示せるのは「こういう判断軸でこう積み上げた事例」であって、読者にとっての最適解そのものではありません。自宅 Observability は、ベストプラクティスを知った上で個別判断を積み重ねる総合格闘技です。ここを起点にシリーズ記事を行き来しながら、自分の家に合う観測の形を見つけてもらえれば、Pillar として書いた甲斐があります。

関連 Pillar

• 自宅サーバ運用の完全ガイド — Proxmox + Cloudflare Tunnel + Docker — 物理〜公開〜運用の全体像を扱う姉妹 Pillar
• 下記の記事一覧（このカテゴリに属する記事が自動で表示されます）