2026/04/10
監視の基本
下記4つの項目が特に重要となる(Four Golden Signals)
Latency
リクエストの処理時間、p50 / p95 / p99 を見る
Traffic
秒間リクエスト数(RPS)、1日のアクティブユーザー数
Errors
5xx エラーの割合、例外の発生頻度
Saturation
CPU・メモリ・ディスクの使用率、DBの接続数
Prometheus
オープンソースの監視・アラートシステム
特徴
Pull 型のデータ収集
Prometheus が監視対象のエンドポイント(/metrics)を定期的に叩いてメトリクスを収集する
監視対象側は「メトリクスを公開するだけ」でよい
強力なクエリ言語(PromQL)
時系列データを柔軟に集計・フィルタできる
例:http_requests_total{status="500"}[5m]
→ 過去5分間の 500 エラーの件数
ローカルの時系列 DB
収集したメトリクスを自前の TSDB に保存する
長期保存はThanos/Cortex等で補完する
Alertmanager との統合
条件を定義してアラートをSlack/PagerDuty等に通知する
OSS・無料
自分でサーバーを運用する必要がある
Datadog
SaaS 型の統合監視プラットフォーム
メトリクス・ログ・トレース・APM を1つのプラットフォームで統合管理できる
特徴
SaaS 型(インフラ管理不要)
Agent を入れるだけでデータが収集・送信される
サーバー・DB・ストレージの運用が不要
統合監視(Metrics + Logs + Traces)
メトリクス・ログ・APM トレースを横断して調査できる
「このエラーが発生した時刻のログを見る」を1画面でできる
インテグレーション
AWS/ GCP / Kubernetes / Rails / PostgreSQL / Redis 等、設定なしで自動的にメトリクスを収集できる
APM(Application Performance Monitoring)
リクエストの処理フローをトレースできる
どの関数・DB クエリが遅いかを可視化できる
有料 SaaS
課金制
比較
| Prometheus | Datadog | |
|---|---|---|
| 形態 | OSS(自己運用) | SaaS(マネージド) |
| コスト | 無料 | 有料 |
| セットアップ | 手間がかかる | Agent 導入のみ・簡単 |
| メトリクス収集 | Pull 型 | Push 型(Agent 経由) |
| ログ管理 | 別途Loki等 | 統合対応 |
| APM・トレーシング | 別途Jaeger等 | 統合対応 |
| 保存期間 | 自分で管理 | プラン依存 |
| スケール | 自分で管理 | 自動 |
- Loki:https://grafana.com/ja/docs/loki/latest/get-started/overview/
- Jaeger:https://www.jaegertracing.io/
ユースケース
Prometheus を選ぶ場面
・Kubernetes を中心としたインフラを自前運用している
・コストを最小限に抑えたい(大量のホスト・高頻度メトリクス)
・カスタムメトリクスを大量に収集したい
・OSS エコシステム(Grafana / Alertmanager)で完結させたい
・データを自社インフラに閉じておく必要がある(セキュリティ要件)
Datadog を選ぶ場面
・早く監視を立ち上げたい・運用コストをかけたくない
・APM・ログ・メトリクスを統合して調査したい
・SLO 管理・インシデント管理まで一体化したい
・AWS / GCP のマネージドサービスを多く使っている
・ログの全文検索・ダッシュボード構築をすぐにやりたい
両方を使う場面
以下のような使い分けをすることも可能
コストと機能のバランスを取るハイブリッド構成
Prometheus:Kubernetes のインフラメトリクス(安価に大量収集)
Datadog:APM・ログ・アラート管理(統合機能が必要な部分)
その他
コスト管理
Prometheus
・scrape_interval を適切に設定する
・不要なメトリクスは metric_relabel_configs で収集前にドロップする
・長期保存は Thanos + S3 でコスト効率よく実現する
- https://prometheus.io/docs/prometheus/latest/configuration/configuration/
- https://thanos.io/tip/thanos/getting-started.md/
Datadog
・ログのサンプリング
→ DEBUG ログは 1%、ERROR は 100% 送るなど
→ ログの量がコストに直結するため重要度で絞る
・カスタムメトリクスの上限管理
→ タグのカーディナリティが高いと課金が爆発する
→ user_id のような無限に増える値をタグにしない
・APM(Application Performance Monitoring)のサンプリングレート
→ エラーと遅いリクエストは 100%、正常リクエストは 10% 送るなど
→ 全トレースを送ると高額になる
参考
- Prometheus:https://prometheus.io/docs/
- Datadog:https://docs.datadoghq.com
- Grafana:https://grafana.com
- Thanos:https://thanos.io/
- Loki:https://grafana.com/ja/docs/loki/latest/get-started/overview/
- Jaeger:https://www.jaegertracing.io/
- Google SRE Book:https://sre.google/sre-book/monitoring-distributed-systems/