Prometheus + Grafana
時系列メトリクスを収集する Prometheus と、可視化・通知を担う Grafana の定番の組み合わせ
分野「監視・可観測性」：動いているものの様子を知り、壊れたら気づく。 分野の役割とつながりは分野の解説へ。
別名：Prometheus、Grafana、PromQL、Grafana Cloud
できること
- 指標を監視し異常を通知する ：落ちたらすぐ知りたい
- データを可視化・ダッシュボード化する ：グラフで見たい・共有したい
- ログを集約して検索する ：何が起きたか後から追いたい
Prometheus + Grafana ができないこと
- 例外のスタックトレース収集とイシュー管理（数値の時系列しか扱わない。エラー追跡は Sentry 等の領域）
- 課金計算など 100% の正確さが必要な集計（公式が「不適」と明記）
- 1 台の Prometheus だけでの長期保存と冗長化（ローカルストレージは複製されず、既定 15 日で消える）
- Prometheus 単体でのログ収集（ログは Loki など別コンポーネントを追加して Grafana で束ねる）
- 運用ゼロでの利用（自前で立てる場合、サーバー・ディスク・アップグレードをすべて自分で持つ）
制約
先頭の行が、このツールで最も先に当たる制約。値はすべて出典の一次情報で確認したもの。
| 項目 | 値 | 影響 | 出典 | 検証日 |
|---|---|---|---|---|
| ローカルストレージの既定保持期間 （主要制約） | 15 日（--storage.tsdb.retention.time の既定 15d。サイズ上限 retention.size は既定 0 = 無効） | 「先月と比較したい」は既定では不可能。長期保存は remote write で外部ストレージ（Thanos、Mimir、Grafana Cloud 等）へ送る設計にする | prometheus.io | |
| ローカルストレージの冗長性 | 1 ノード。クラスタ化も複製もされない | ディスクやノードの障害でデータが消える。単一ノードの DB と同じ扱いで、耐久性が要るなら外部ストレージへ | prometheus.io | |
| 取得（スクレイプ）間隔の既定 | scrape_interval 1m、scrape_timeout 10s、evaluation_interval 1m | 既定では 1 分粒度で、数秒の瞬間的なスパイクは見えない。間隔を短くすると系列あたりのサンプル数と保存量が比例して増える | prometheus.io | |
| 精度の前提 | 100% の正確さが必要な用途（リクエスト単位の課金など）には不適と公式が明記 | 収集データは欠損しうる前提の「監視用」であり、請求や監査の根拠にしてはならない。会計用途は別系統で集計する | prometheus.io | |
| Grafana Cloud 無料枠 | メトリクス 10k アクティブ系列 / 月、ログ・トレース各 50 GB / 月、保持 14 日、Grafana ユーザー 3 人 | 自前運用を避けて Grafana Cloud に載せる場合、系列数 1 万が最初の壁。Pro は $19 / 月 + 1k 系列あたり $6.50 から | grafana.com | |
| Grafana のライセンス | AGPL v3（Prometheus は Apache 2.0） | Grafana を改変してネットワーク越しに提供する場合、改変部分のソース公開義務が生じる。組み込み配布には注意 | github.com |
典型的な落とし穴
- ラベルにユーザー ID やリクエスト ID など値の種類が多いものを付けると、系列数が爆発してメモリを食い尽くす（カーディナリティ問題）
- Prometheus はプル型で、監視対象へ HTTP で取りに行く。NAT の内側や短命なバッチジョブは直接スクレイプできず、Pushgateway などの迂回が要る
- Prometheus 単体は記録するだけで通知しない。Alertmanager か Grafana Alerting を別途設定するまで「落ちたら知らせる」は成立しない
- Grafana のダッシュボードを画面上だけで作ると、環境の再構築時に消える。JSON をリポジトリに置くかプロビジョニングで管理する
コスト
- 課金モデル
- 無料
- 跳ねる条件
両者とも OSS で無償（Prometheus は Apache 2.0、Grafana は AGPL v3）。費用はサーバーとディスクとして発生し、系列数と保持期間の積で決まる。Grafana Cloud を使う場合は無料枠を超えた時点で Pro $19 / 月から
- 出典
- github.com 検証
代替手段と差分
選定判断
自前のサーバーや Kubernetes のメトリクス監視では事実上の標準で、費用をかけずに始めるなら第一候補。15 日を超える保持、冗長化、ログの集約が必要になった時点で外部ストレージ（Grafana Cloud、Thanos、Mimir）を足すか、運用を丸ごと買う Datadog へ。例外追跡は Sentry を併用する
Prometheus は監視対象から HTTP で数値を定期的に取りに行き（プル型）、ラベル付きの時系列として保存する。PromQL で集計し、Alertmanager 経由で通知する。Grafana はその時系列をダッシュボードにする可視化ツールで、Prometheus 以外のデータソース（PostgreSQL、Loki、CloudWatch 等）にもつながる。両者は別プロジェクトだが、組み合わせて使うのが通例である。
最初に当たる制約は「既定 15 日で消える」「1 ノードで複製されない」というローカルストレージの性質である。Prometheus 自身がこれを「単一ノードの DB として扱え」と明記しており、長期保存と耐久性は remote write の先に置く設計が前提になる。次に当たるのはラベルのカーディナリティで、これは保持期間の設定では解決しない。