Prometheus vs Datadog：SRE向けPoCと選定ガイド

要約と意思決定の採否基準（Prometheus／Datadog）

ここでは意思決定者が短時間で判断できる要旨と、採否を決めるための具体的な基準を先に示します。長文を読む時間がない場合はこのセクションだけ参照して下さい。PrometheusとDatadogのどちらを採用すべきかは、運用リソース、データ主権要件、コスト許容度で変わります。

経営／意思決定者向け要旨

この短い要旨は意思決定のための核となるポイントを示します。

• 運用人員が少なく迅速な導入が最優先なら、DatadogのSaaSは早期価値が出やすい選択肢です（ただし機能・保持はプラン依存）。
• 自社でデータ管理／ラベル設計に投資でき、長期分析やコスト最適化を重視するなら、Prometheus（＋長期保存レイヤ）を中心とした構成が適しています。
• 中間の要望（低レイテンシなオンプレ解析＋クラウドでの長期保存）はハイブリッド構成が現実的です。

採否基準（具体的チェックリスト）

以下はPoC結果に基づく採否判断のための具体閾値です。数値は組織要件に応じて調整してください。Datadogの機能可否やトライアル範囲はプランで異なるため、必ず公式ドキュメント／契約で確認してください。

• SLI実装性：同一SLI（例：request success rate, p95 latency）を両環境で2週間実行し、SLO消費の差が10%以内なら可。差が30%超なら要精査。
• クエリ性能：運用で頻出するダッシュボードクエリの95パーセンタイル応答時間が1秒未満を理想、2秒以下を許容ラインとする。
• 運用工数：週次の監視維持工数が「週当たり人時」で比較し、SaaSがセルフホストより50%以上工数低減する場合はSaaSを有利と判断。
• コスト差異：総TCO（月額または年換算）でDatadogがセルフホストより30%以上高く、運用工数差で相殺できない場合はセルフホストを検討。
• セキュリティ／データレジデンシー：法務・情報セキュリティが「特定リージョンでの保存」「SOC2/ISO等の認証」「専用VPC接続」を必須条件にしている場合はSaaS利用時に契約上で担保できるか必須で確認。
• 長期保存要件：ログ・メトリクスを365日以上保持する要件があり、廉価なオブジェクトストレージでの保持を望む場合はPrometheus＋長期層を優先検討。

これらの基準をPoCで測定し、合格/不合格で判定してください。

両製品の基本アーキテクチャと公式参照

ここではPrometheusとDatadogの基本的な設計を公式資料に基づいて整理します。各製品の機能はバージョンやプランで変わるため、公式ドキュメントの確認を推奨します。

Prometheusの基本（導入文）

Prometheusは主にプル型スクレイプとローカルTSDBを中核とするオープンソースの監視基盤です。PromQLでの集計やAlertmanagerによるアラートルーティングを中心に短期解析を担います。詳細は公式ドキュメントを参照してください。

• 公式情報：Prometheus 公式ドキュメント（https://prometheus.io/docs/introduction/overview/）
• 特徴：プルベースのスクレイプ、ラベル中心のデータモデル、ローカルTSDB、Alertmanager。
• 長期保存：remote_writeによる外部保存が一般的です（remote_write設定例：https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write）。
• 拡張：長期保存やグローバルクエリはThanos/Cortex/Mimir等で補います。

Datadogの基本（導入文）

DatadogはSaaS型のフルスタック観測プラットフォームで、Agentを通じてメトリクス・ログ・APMを取り込みます。運用負荷を低減し早期で可視化を得やすい半面、料金や保持はプラン依存です。詳細は公式ドキュメントを参照してください。

• 公式情報：Datadog ドキュメント（https://docs.datadoghq.com/）
• 特徴：Agentベースのプッシュ収集、統合UI、SaaS側でのスケール管理。
• 注意点：保持日数、機能（セキュリティモニタリング等）、トライアルでの利用可否は契約・プランで異なります（料金とプラン：https://www.datadoghq.com/pricing/）。

主要な技術差分と運用インパクト

このセクションではデータモデル、スケーリング戦略、ログ・トレース統合、アラート運用の差分を整理します。SRE的に重要なのは「自前でどこまで運用するか」の判断です。

データモデルとクエリ言語（導入文）

Prometheusはラベルベースの時系列とPromQLを持ち、柔軟な集計が可能です。一方、Datadogはタグベースのメトリクスと独自クエリ/UIを提供します。完全互換でないためクエリ表現差の検証が必要です。

• Prometheus：ラベル中心、PromQLにより時系列解析が強力。高カーディナリティに注意が必要。
• Datadog：タグとメトリクス名ベースの集計。UIやダッシュボードが充実する反面、PromQLをそのまま再現できない場合がある。
• 実務対策：主要なPromQLクエリをDatadog側で実装し、結果差を比較してSLO影響を評価する。

スケーリングとHA（Thanos／Cortex／Mimir の差分）（導入文）

Prometheus単体はシングルノードTSDBです。大規模運用はThanos/Cortex/Mimirなどの設計と運用が必要です。各プロジェクトはアーキテクチャや運用コストが異なります。

• Thanos（https://thanos.io/）：PrometheusのSidecarでS3等へオブジェクト保存、グローバルクエリを実現。比較的導入が容易。
• Cortex（https://cortexmetrics.io/）：マイクロサービス風のスケール（ingester/querierなど）。マルチテナント運用に向く。
• Grafana Mimir（https://grafana.com/docs/mimir/latest/）：Cortex系の設計思想を引き継ぐ実装。
• 運用差：各コンポーネントの冗長化、クエリエンジンのスケール、S3等バックエンドのチューニングが必要。バージョン差でAPIや安定性が変わるため、導入時は各プロジェクトの公式ドキュメントと導入事例を確認する。

ログ・トレース・APMの統合（導入文）

Prometheus単体はメトリクス専用です。ログやトレースは別ツール（Loki/ELK、Jaeger/Tempoなど）と連携します。一方、Datadogはメトリクス・ログ・APMを統合提供します。

• Prometheus連携例：Loki（ログ）、Jaeger/Tempo（トレース）、Grafana（可視化）。
• Datadog：Metrics/Logs/APM/RUMが同一プラットフォームで結び付きやすい。
• 検証ポイント：ログ・トレースの相関（リンク付け）やサンプリング設計をPoCで比較する。

アラーティングとインシデント管理（導入文）

アラートの精度と運用フローはSRE運用で重要です。Prometheus＋Alertmanagerは柔軟なルーティングを提供しますが、運用ルールは自前で作る必要があります。DatadogはSaaSで通知／エスカレーションが統合されています。

• Prometheus：Alertmanagerでルーティング、サイレンス、グルーピングを実装。運用ルール整備が必要。
• Datadog：Monitorsで閾値や異常検知、エスカレーションをSaaSで管理。ノイズ軽減機能が組み込まれている場合があるが、詳細はプラン依存。
• 運用勘所：アラートの責務を1箇所に集約し二重通知を避ける設計を徹底すること。

コスト要素とサンプル試算

ここではコスト構成要素と、実務で使えるサンプル試算を示します。実数は構成・保持日数・クラウド領域で大きく変わるため、以下は「計算方法とサンプル例」です。

コスト要素（導入文）

監視コストはSaaSライセンス、ストレージ、ネットワーク（egress）、Compute（セルフホストのVM/Pod）、運用人件費に分解できます。各要素をPoCで定量化してください。

• SaaSライセンス：ホスト単位やカスタムメトリクス、APM/ログ別課金。
• ストレージ：メトリクス（短期はTSDB、長期はオブジェクトストレージ）、ログストレージ。
• ネットワーク（egress）：SaaSへ送る場合のアウトバウンド転送量と費用。
• Compute：Cortex/Thanos等のコンポーネントに必要なインスタンスコスト。
• 運用工数：導入初期、週次保守、トラブル対応の人時。

サンプル試算（仮定を明示して算出例を示す）

以下は計算式と、現実的な仮定に基づく2つの例です。数値は仮定であり、実際は計測値とクラウド価格で再計算してください。

基本の計算式（メトリクス）：

• サンプル数/月 = シリーズ数 × (秒/月 ÷ スクレイプ間隔[s])
• データ量[GB/月] = サンプル数/月 × 1サンプル当たりの平均バイト数 ÷ 10^9

仮定（例）：スクレイプ間隔=60s、1サンプル=100 bytes、秒/月=2,592,000（30日換算）

例 A：小規模クラスタ

• ホスト数：50、平均シリーズ/ホスト：100 → 総シリーズ = 5,000
• サンプル数/月 = 5,000 × 43,200 = 216,000,000
• データ量 = 216,000,000 × 100 bytes ≒ 21.6 GB/月
• オブジェクトストレージ（S3想定）コスト = 21.6 GB × $0.023/GB ≒ $0.50/月（ストレージ単価はリージョンで差あり）
• Datadog例（想定単価）：$18/ホスト/月 × 50 = $900/月（注：実際はプランに依存）

例 B：中規模クラスタ

• ホスト数：1,000、平均シリーズ/ホスト：200 → 総シリーズ = 200,000
• サンプル数/月 = 200,000 × 43,200 = 8,640,000,000
• データ量 = 8,640,000,000 × 100 bytes ≒ 864 GB/月
• オブジェクトストレージ（S3想定）コスト = 864 GB × $0.023/GB ≒ $19.87/月
• SaaS送信時のegress（想定1サンプル200 bytesで計算）：データ量 ≒ 1,728 GB/月 → egress費用 $0.09/GB × 1,728 ≒ $155/月（egress単価はクラウドベンダーで変動）
• Datadog例：$18/ホスト/月 × 1,000 = $18,000/月（ログ・APMは別課金のため増加）

注意点：

• PrometheusのTSDBやThanos/Cortexの保存方式、レプリケーション、圧縮レベルにより実際のGBは大きく変わります（実務では2×〜3×の安全係数を入れることを推奨）。
• Datadogの料金体系はプラン・コミットメントで大きく変わるため、上記のSaaS想定単価は例示です。詳細はDatadog公式の料金ページで確認してください（https://www.datadoghq.com/pricing/）。

セキュリティとコンプライアンスのチェックポイント

このセクションでは法務／情報セキュリティが要求する主要チェックポイントを列挙します。SaaS利用時は契約で担保できるかを必ず確認してください。

法務・セキュリティ担当向けチェックリスト（導入文）

下の項目をPoC前に法務・セキュリティチームとすり合わせ、PoCで実証してください。SaaSを選ぶ場合は公式のコンプライアンスページと契約条項を参照のうえ確認します。

• データレジデンシー：データを保存するリージョンの指定可否（Datadogのデータレジデンシー情報：https://docs.datadoghq.com/account_management/data_residency/）。
• 転送時の暗号化：TLS強制、相互TLSの要否、remote_writeのTLS設定（Prometheus remote_writeドキュメント参照）。
• 保存時の暗号化：KMS等での暗号化（セルフホストは自組織で管理、SaaSはベンダーの方式を確認）。
• 認証・認可：SSO（SAML/OIDC）、SCIMによるユーザー同期、細かなRBAC設定の有無。DatadogのSSO/SCIM情報は公式ドキュメント参照。
• 監査ログ：管理操作ログの取得・保持、監査証跡の提出可否。
• サードパーティ証明：SOC2/ISO27001/PCI/HIPAA等の有無（Datadogのコンプライアンス情報：https://www.datadoghq.com/security/）。
• データ削除と保持ポリシー：特定データの削除要求に対応できるか、保持期間の設定とエクスポート／消去方法。
• ネットワーク接続形態：VPC接続、PrivateLink、オンプレゲートウェイの利用可否。
• マスキング／匿名化：PIIを送る場合のマスキング機能の有無と実装方法。
• 脆弱性対応／SLA：セキュリティインシデント時の対応フロー、SLA（SaaS契約で必須確認）。

PoC 計画と再現性のあるテスト手順

ここでは再現性を担保しつつ、短期間で有用な結果を得るためのPoC設計と具体手順を示します。測定方法は定量化可能であることが重要です。

PoC設計（規模・期間・判定基準）（導入文）

推奨PoCは2週間程度の並行実行です。期間中に平常負荷とピーク負荷の両方を再現し、上記の採否基準で評価します。

• 期間：最低14日（7営業日で平常挙動、48時間で負荷テスト）。
• 規模例：実運用の10%〜100%の負荷を段階的に投入。高カーディナリティは意図的に発生させる（例：ユーザーID毎のメトリクスをn種生成）。
• 測定項目（必須）：SLI/SLO消費率、ダッシュボードクエリp95応答時間、アラート発火遅延、エージェントリソース消費、月間データ量（GB）、egress量（GB）。
• 合否判断：前節の採否基準を用いる。

具体的手順（導入文）

以下は実施手順の例です。手順は自社環境に合わせて調整してください。

1. 事前準備：評価テンプレートとSLI一覧、計測方法、runbookを作成する。
2. 環境構築（Prometheus）：Prometheus（K8sならPrometheus Operator）をデプロイし、スクレイプ対象を登録。長期保存用にThanos/Cortex/Mimirのプロトタイプを用意し、S3等のオブジェクトストレージを接続する。
3. 環境構築（Datadog）：Datadog AgentをDaemonSetまたはホストに導入し、同一メトリクス・ログ・トレースを収集するよう設定する。Datadogの組織設定で必要な権限とデータレジデンシーを確認する。
4. ベースライン計測：通常負荷で48時間稼働させ、CPU/メモ/ネットワーク、クエリ応答を記録する。
5. 負荷試験：k6/vegeta等でトラフィックを増やし、高カーディナリティメトリクスや大量ログを注入して48時間実施する。
6. 障害シナリオ：Prometheusのスクレイプ停止やリーダー選出の障害、Datadog Agent停止等の障害を再現し、MTTD/MTTRを測定する。
7. データ集計・評価：評価テンプレートに実測値を記入し、採否基準で判定する。

測定と判定の具体的閾値（導入文）

ここでは測定方法と具体的閾値例を示します。PoCではこれらを事前に合意しておくことが重要です。

• クエリ遅延：代表的なダッシュボードクエリを30分ウィンドウ、過去6時間のリクエストで測定。p95 < 1s を合格ライン、p95 < 2s を許容ライン。
• アラート伝搬時間：アラート発生から通知到達までの中央値 < 30秒、p95 < 120秒を目安。
• データ欠損率：受信すべきサンプル数に対する欠損率 < 0.1% を目標。
• 運用工数：初期導入（人時）、週次保守（人時）を算出し、SaaSとセルフホストを比較する。

評価テンプレート（記入例）（導入文）

下はPoCで使える簡易テンプレートと記入例です。実測値を埋めて比較します。

（上は記入例です。実値はPoCで記録してください。）

移行手順・段階的ロードマップ（運用化まで）

ここでは移行フェーズごとの作業と、運用化までのロードマップを示します。段階的に進めてリスクを低減します。

段階的移行ステップ（導入文）

移行は段階的に行い、各段階でKPIを満たすか確認しながら進めます。

1. 重要メトリクスの棚卸と優先順位付けを実施する。
2. PoCで合格した構成をステージ環境で部分導入する（アラートやダッシュボードは並行運用）。
3. データ搬送設計を確定し（remote_write→中継→SaaS等）、テストを行う。
4. アラートを段階的に切替え、オンコール手順を更新する。
5. 完全移行後、旧構成は一定期間フェイルバック可能な状態で保管し、問題なければ破棄する。

アラート・ダッシュボード移行の注意点（導入文）

アラートやダッシュボードの表現差により運用影響が出ます。段階的検証を推奨します。

• PromQLベースのアラートはDatadogで再現できない場合があるため、近似クエリで検証する。
• 発火ウィンドウや集約単位を揃えないと誤検知が発生するため、移行前に比較テストを行う。
• 重要SLOのパネルを優先移行し、運用チームが実運用で使えることを確認してから残りを移行する。

参考（公式ドキュメントと事例）

ここでは本文で参照した主な公式ドキュメントを示します。各リンクで最新仕様・料金・コンプライアンス情報を確認してください。

• Prometheus 公式ドキュメント（概要、remote_write）: https://prometheus.io/docs/introduction/overview/
• Prometheus remote_write 設定: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
• Thanos: https://thanos.io/
• Cortex: https://cortexmetrics.io/
• Grafana Mimir: https://grafana.com/docs/mimir/latest/
• Loki（ログ）: https://grafana.com/docs/loki/latest/
• Jaeger（トレース）: https://www.jaegertracing.io/
• Tempo（Grafanaのトレーシング）: https://grafana.com/docs/tempo/latest/
• Datadog ドキュメント（Agent/Logs/APM/Monitoring）: https://docs.datadoghq.com/
• Datadog 料金ページ（プラン確認）: https://www.datadoghq.com/pricing/
• Datadog セキュリティ／コンプライアンス情報: https://www.datadoghq.com/security/
• SRE リソース（Google SRE Book）: https://sre.google/sre-book/table-of-contents/
• AWS Observability（参考）: https://aws.amazon.com/observability/

まとめ

本記事はSRE視点でPrometheusとDatadogを比較し、短期PoCで判断できる実務的な手順と評価基準を示しました。Prometheusはメトリクス表現とコントロール性に優れ、長期保存やコスト最適化に強みがあります。DatadogはSaaSとして統合性と導入スピードでメリットがありますが、機能や保持条件はプラン依存のため契約確認が必須です。提示した採否基準とサンプル試算、PoC手順を用いて2週間の並行PoCで定量評価を行い、結果に基づいて最終判断してください。