plan-4ging

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
課金制

比較

PrometheusDatadog
形態OSS(自己運用)SaaS(マネージド)
コスト無料有料
セットアップ手間がかかるAgent 導入のみ・簡単
メトリクス収集Pull 型Push 型(Agent 経由)
ログ管理別途Loki統合対応
APM・トレーシング別途Jaeger統合対応
保存期間自分で管理プラン依存
スケール自分で管理自動

ユースケース

Prometheus を選ぶ場面

・Kubernetes を中心としたインフラを自前運用している
・コストを最小限に抑えたい(大量のホスト・高頻度メトリクス)
・カスタムメトリクスを大量に収集したい
・OSS エコシステム(Grafana / Alertmanager)で完結させたい
・データを自社インフラに閉じておく必要がある(セキュリティ要件)

Datadog を選ぶ場面

・早く監視を立ち上げたい・運用コストをかけたくない
・APM・ログ・メトリクスを統合して調査したい
・SLO 管理・インシデント管理まで一体化したい
・AWS / GCP のマネージドサービスを多く使っている
・ログの全文検索・ダッシュボード構築をすぐにやりたい

両方を使う場面

以下のような使い分けをすることも可能
コストと機能のバランスを取るハイブリッド構成

Prometheus:Kubernetes のインフラメトリクス(安価に大量収集)
Datadog:APM・ログ・アラート管理(統合機能が必要な部分)

その他

コスト管理

Prometheus

・scrape_interval を適切に設定する
・不要なメトリクスは metric_relabel_configs で収集前にドロップする
・長期保存は Thanos + S3 でコスト効率よく実現する

Datadog

・ログのサンプリング
 → DEBUG ログは 1%、ERROR は 100% 送るなど
 → ログの量がコストに直結するため重要度で絞る
・カスタムメトリクスの上限管理
 → タグのカーディナリティが高いと課金が爆発する
 → user_id のような無限に増える値をタグにしない
・APM(Application Performance Monitoring)のサンプリングレート
 → エラーと遅いリクエストは 100%、正常リクエストは 10% 送るなど
 → 全トレースを送ると高額になる

参考