Chillarin Blog 構成紹介 - 8.監視基盤編 Part1（設計思想と全体像）-

はじめに

前回（7.ギミック編）までで、ブログの「動かす」部分はひと通り紹介しました。今回からは 「守る・見る」 の話 ── 監視基盤編です。

正直、自宅サーバの監視って後回しにされがちです。「動いてるし、まあいいか」で何ヶ月も放置して、ある日突然ディスクが100%になって慌てる…… みたいなのは自宅LABあるあるだと思います。

自分もそうだったんですが、ブログを本格運用し始めてからは「あ、これは監視ないとダメだ」と痛感するようになりました。理由は単純で、壊れたことに気づけないから。

VPSなら提供元がある程度面倒を見てくれますが、自宅サーバは全部自分です。ディスクが埋まっても、コンテナが落ちても、証明書が切れても、誰も教えてくれません。

というわけで、本章では Prometheus + Grafana + Loki を使った監視基盤の 設計思想 と 全体像 を紹介します。具体的なセットアップ手順は Part2 以降で掘っていきます。

なぜ Prometheus + Grafana + Loki なのか

監視スタックの選択肢は色々あります。ざっくり比較するとこんな感じ。

スタック	メトリクス	ログ	特徴	自宅向き度
Prometheus + Grafana + Loki	◎	◎	業界標準、エコシステムが巨大	◎
Splunk (Enterprise / Free)	◎	◎	最強のログ分析基盤。ただし高い	△
Zabbix	◎	△	エンタープライズ向け、設定が重い	△
Datadog / New Relic	◎	◎	SaaS。楽だけど従量課金	✕
Uptime Kuma	○	✕	死活監視特化。軽い	○（単体なら）
Netdata	◎	△	インストールするだけで動く	○

正直に言うと、Splunk を入れたかった

これは本音です。仕事で Splunk を触ったことがある人なら共感してもらえると思いますが、ログの検索・可視化・相関分析に関しては Splunk が頭一つ抜けています。 SPL（Search Processing Language）の表現力は本当に強力で、「あのログとこのログを時間軸で突き合わせて、特定パターンだけ抽出する」みたいなことが直感的に書ける。

じゃあなぜ入れなかったかというと、コストです。

ライセンス	制限	月額/年額
Splunk Free	500MB/日まで	無料
Splunk Enterprise	無制限	約 $1,800/GB/年〜

Splunk Free は 500MB/日の取り込み制限があります。 nginx のアクセスログだけで 500MB/日を超えることがある自宅サーバだと、この枠はすぐに埋まります。しかも Free 版はアラート機能が使えない、ユーザー認証が使えない、分散サーチができない…… と、監視基盤として使うには制約がきつい。

Enterprise は言うまでもなくエンタープライズ価格なので、個人の自宅サーバには論外です。

Splunk の代替としては OpenSearch（旧 Elasticsearch OSS）もありますが、JVM ベースでメモリを大量に食うので NUC の限られたリソースには厳しい。結局、軽量 + 無料 + Docker と相性が良い という条件で絞ると、Prometheus + Loki の組み合わせに落ち着きました。

「お金が無限にあるなら Splunk + SOAR で全自動化したい」というのは自宅ラボ勢共通の夢ではないでしょうか。

選定理由をまとめると

結論、Prometheus + Grafana + Loki にしました。理由は3つ。

1. 仕事で使っている

業務でもPrometheus/Grafanaを触る機会が多いので、自宅で使うことがそのままスキルの維持になります。 Zabbixも悪くないんですが、最近のトレンド的にはPrometheus系に寄ってきている印象です。（Splunk のスキルは仕事で別途維持できるので、自宅は別のスタックで経験を積む方が得という判断もあります）

2. Docker との相性が良い

うちの環境は基本的にDockerで動かしているので、cAdvisorやnode_exporterをコンテナとして追加するだけでメトリクスが取れる手軽さは大きい。 Prometheus の設定も prometheus.yml 1ファイルで管理できるので、Gitで管理しやすいです。 Splunk も Docker で動かせますが、コンテナ1つで 4GB+ メモリを要求してくるので、NUC 環境だとリソースが厳しい。

3. ログも同じ画面で見たい

GrafanaにLokiを繋げば、メトリクスとログを同じダッシュボードで横断的に見れます。「CPU使用率が跳ねた時間帯のnginxログを見る」みたいなことが1画面でできるのは、トラブルシュートの速度が全然違います。 Splunk ならこれがもっと高度にできるのは事実ですが、自宅サーバの規模では Grafana + Loki で十分です。

何を監視するか ── 設計思想

ここが一番大事なところです。ツールを入れるのは簡単ですが、「何を見るか」を決めないと意味がない。

自分は以下の4レイヤーに分けて考えています。

レイヤー1: ホスト（物理/仮想マシン）

まず土台。NUC 3台と、その上で動くVM/LXCの基本リソースです。

メトリクス	取得元	なぜ見るか
CPU使用率	node_exporter	異常プロセスの検知
メモリ使用率	node_exporter	OOMの予兆を掴む
ディスク使用率	node_exporter	一番大事。自宅サーバの事故原因No.1
ディスクI/O	node_exporter	NASのNFS遅延を検知
ネットワークトラフィック	node_exporter	異常通信の検知
システム稼働時間	node_exporter	意図しない再起動の検知

特にディスク使用率は最重要です。ログが溜まる、Dockerイメージが増える、VMのスナップショットが残る…… 自宅サーバでディスクが埋まるパターンは無限にあります。

レイヤー2: コンテナ（Docker）

うちはブログも含めて全サービスをDockerで動かしているので、コンテナ単位の監視は必須です。

メトリクス	取得元	なぜ見るか
コンテナCPU/メモリ	cAdvisor	リソースリークの早期発見
コンテナ稼働状態	cAdvisor	落ちたら即検知
コンテナリスタート回数	cAdvisor	再起動ループの検知
コンテナネットワーク	cAdvisor	コンテナ間通信の異常

cAdvisor は Google が作ったコンテナメトリクス収集ツールで、Docker socketを読み取って各コンテナのリソース使用量をPrometheusフォーマットで吐いてくれます。コンテナとして動かすだけなので導入は楽です。

レイヤー3: アプリケーション

ここからはサービス固有の監視です。

メトリクス	取得元	なぜ見るか
ブログの死活	node_exporter の up/down（chillarin-sv01 が応答しているか）	Cloudflare Tunnel ホストが落ちた＝外からアクセス不可と等価
nginx のリクエスト数/ステータス	nginx の stub_status + exporter	4xx/5xxの急増を検知
Cloudflare Analytics	cf-exporter	PV数、国別アクセス、キャッシュヒット率
Remark42 コメント数	カスタムexporter or API	スパムの急増検知

ブログの死活監視は、chillarin-sv01 の node_exporter が応答しているかどうかで判断しています。 chillarin-sv01 が落ちると Cloudflare Tunnel（ブログへの入口）も道連れになるため、「node_exporter が応答しない ≒ ブログが外から見えない」 と等価で扱えます。 blackbox-exporter は chillarin-ops 側でネットワーク機器・NAS への ICMP ping 監視に使っており、ブログの HTTP 外形監視には使っていません。

レイヤー4: ログ

メトリクスだけでは「何が起きたか」はわかっても「なぜ起きたか」がわからないことが多い。そこでLokiによるログ集約が効いてきます。

ログソース	収集方法	見るポイント
nginx アクセスログ	Promtail	異常なアクセスパターン、404の急増
nginx エラーログ	Promtail	upstream接続エラー
Docker コンテナログ	Promtail (docker driver)	アプリケーションエラー
システムログ (syslog)	Promtail	カーネルエラー、OOM killer

Promtail は Loki 専用のログ収集エージェントで、ファイルを tail して Loki に送るシンプルなやつです。 Dockerのログドライバーとして設定すると、各コンテナのstdout/stderrを自動的にLokiに流してくれます。

全体構成図

テキストで描くとこんな感じです。（画像は後日差し替え予定）

snippet

┌─────────────────────────────────────────────────────────────┐
│                    chillarin-ops (VM)                        │
│                    172.16.1.151                              │
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │ Prometheus   │  │  Grafana    │  │    Loki     │         │
│  │  :9090       │  │  :3000      │  │  :3100      │         │
│  │              │  │             │  │             │         │
│  │ scrape every │  │ dashboards  │  │ log storage │         │
│  │ 15s          │  │ + alerts    │  │             │         │
│  └──────┬───────┘  └──────┬──────┘  └──────┬──────┘         │
│         │                 │                │                │
│         │    query ───────┘                │                │
│         │    query ────────────────────────┘                │
│         │                                                   │
└─────────┼───────────────────────────────────────────────────┘
          │ scrape (pull)
          │
    ┌─────┴───────────────────────────────────┐
    │                                         │
    ▼                                         ▼
┌─────────────────────┐            ┌─────────────────────┐
│ chillarin-sv01 (VM) │            │ nuc1 / nuc2 / nuc3  │
│ 172.16.1.100        │            │ (Proxmox hosts)     │
│                     │            │                     │
│ ・node_exporter     │            │ ・node_exporter     │
│ ・cAdvisor          │            │   (各ホスト)        │
│ ・nginx-exporter    │            │                     │
│ ・cf-exporter       │            └─────────────────────┘
│ ・promtail          │
│                     │
│ [nginx, hugo, ...]  │
└─────────────────────┘

ポイントは以下の通り。

監視サーバ (chillarin-ops) はブログサーバ (chillarin-sv01) とは別VMにしている。同居させると、ブログが落ちた時に監視も道連れになるので。
Prometheus は pull 型。各エクスポーターのエンドポイントを定期的にスクレイプしに行く。push型と違って、監視対象側の設定が最小限で済む。
Grafana は Prometheus と Loki の両方をデータソースとして使い、メトリクスとログを同じ画面で見れるようにしている。
Promtail は chillarin-sv01 側で動かして、ログを Loki に push する。
blackbox-exporter は chillarin-ops 側に置いている。ネットワーク機器・NAS への ping（死活）監視が主目的で、監視対象（chillarin-sv01）が落ちても ops 側から独立して動き続けられる構成にしている。

アラート設計 ── 「本当に通知すべきもの」だけに絞る

監視を入れると「とりあえず全部アラートにしよう」ってなりがちですが、自宅サーバでそれをやると通知地獄になって無視するようになります。本末転倒。

自分のアラートポリシーは 「寝てる間に起きたら翌朝気づきたいもの」 だけに絞っています。

アラート名	条件	通知先	理由
HostDiskAlmostFull	ディスク使用率 > 85%	Discord	事故原因No.1。余裕を持って80%台で気づきたい
ContainerDown	主要コンテナが5分以上停止	Discord	ブログやコメント機能が落ちてたら直したい
HighMemoryUsage	メモリ使用率 > 90% が10分以上	Discord	OOM killer が発動する前に気づきたい
CloudflareTunnelDown	chillarin-sv01 の node_exporter が2分以上無応答	Discord	Cloudflare Tunnel ホストが落ちた状態（外からブログにアクセス不可と等価）

通知先は Discord の Webhook にしています。 Slack でもいいんですが、個人利用なので Discord のほうが気軽です。 Grafana の Alerting 機能から直接 Webhook を叩けるので、通知の仕組みとしてはこれだけで完結します。

Alertmanager コンテナ（:9093）も同居させていますが、現時点では receiver を null に設定して意図的に無効化しています。将来的に「severity に応じて通知チャンネルを分ける」「同じアラートの再通知間隔を細かく制御する」といった運用が必要になったときのために、箱だけ置いてある状態です。

※ 最近 Phase 4 で会員ポータル系のアラート（PortalDown / GrafanaDown / WebhookErrors / HighPaymentFailureRate）も追加しましたが、そのあたりの話は有料コンテンツ側で詳しく紹介予定です。

コスト：「この監視をクラウドでやるといくら？」

せっかくなので、同じ監視をクラウドサービスで実現した場合のコストを概算してみます。

前提

監視対象: 3ホスト + 10コンテナ + 1 Webサイト
メトリクス: 約200系列（node_exporter + cAdvisor + exporter群）
ログ: 約 500MB/日
データ保持期間: 30日

クラウド監視サービスの場合

サービス	月額概算	備考
Datadog (Infrastructure)	$23/host × 3 = $69	ホスト数課金
Datadog (Logs)	500MB/日 × 30日 = 15GB → $38	インデックス課金
Datadog 合計	約 $107/月（約16,000円）
New Relic	無料枠内に収まる可能性あり	100GB/月のログ無料枠
Grafana Cloud	$0〜$29/月	Free枠: 10kメトリクス系列, 50GBログ

正直、Grafana Cloud の Free 枠なら十分収まる規模ではあります。ただし、自前で持つメリットは データの保持期間やクエリの自由度に制限がない こと。あと、Grafana Cloud に上げるということはメトリクスやログを外に出すことになるので、セキュリティ的にオンプレ完結のほうが安心という面もあります。

自前の場合のコストは、chillarin-ops の VM リソース分（CPU 2コア、メモリ 4GB 程度）だけ。電気代に換算すると月数百円レベルです。

ここまでのまとめ

自宅サーバの監視は ディスク使用率 と コンテナの死活 が最重要
Prometheus + Grafana + Loki を採用。理由は業務との親和性、Docker との相性、メトリクスとログの統合表示
監視対象は4レイヤー: ホスト → コンテナ → アプリケーション → ログ
アラートは 「寝てる間に起きたら翌朝気づきたいもの」 だけに絞る
監視サーバはブログサーバと 別VM に配置

次回 Part2 では、Prometheus / Grafana / Loki / Promtail の実際のセットアップと、docker-compose への組み込み方を紹介します。

← 一覧

自宅サーバとネットワークの観測の全体像は自宅 Observability の完全ガイド — Prometheus + Grafana + Loki で家のサーバとネットワークを観測し続けるにまとめています。監視基盤の設計判断から複合障害・retention 運用までを 1 ページで通読できる Pillar ガイドです。

· · ·