Contents
- 1 主要参照ソース（公式ドキュメント・ガイド）
- 2 結論サマリ：組織規模・スキルセット・要件別の推奨（短期判断）
- 3 主要差分の一目でわかる比較表（機能カテゴリ）
- 4 機能詳細比較：メトリクス、ログ、トレース、合成監視／RUM、可視化、アラート
- 5 アーキテクチャと導入オプション（Datadog SaaS / Grafana 自己運用 / Grafana Cloud）
- 6 移行手順とチェックリスト（データ移行・並行運用・切替・ロールバック）
- 7 POCテンプレートとTCO試算サンプル
- 8 用語集（スケール系・転送・ログ/トレース関連の定義）
- 9 セキュリティ・コンプライアンス（検証ポイントと公式ドキュメント）
- 10 意思決定支援：簡易フローチャートと短縮判定表
- 11 FAQ（導入担当者が抱きがちな質問と短い回答）
- 12 まとめ
主要参照ソース（公式ドキュメント・ガイド）
以下は本比較で参照した主要な公式ドキュメントです。
Datadog、Grafana/Grafana Cloud、Prometheus系の公式ページを中心にしています。
仕様や料金は変わりやすいため、最終判断は各社の最新ドキュメントで確認してください。
ベンダー公式（Datadog / Grafana）
Datadog と Grafana 系の公式情報は製品仕様や料金の一次情報です。確認を推奨します。
- Datadog（製品・価格・ドキュメント）: https://www.datadoghq.com/
- Datadog ドキュメント（API / APM / Logs）: https://docs.datadoghq.com/
- Grafana（製品情報）: https://grafana.com/
- Grafana Cloud（製品・料金・ドキュメント）: https://grafana.com/products/cloud/
主要 OSS ドキュメント（Prometheus / Loki / Tempo / OpenTelemetry 等）
OSS の公式ドキュメントは実装と移行方針の根拠になります。
- Prometheus ドキュメント（remote_write 等）: https://prometheus.io/docs/
- Loki ドキュメント（ログの設計と検索）: https://grafana.com/docs/loki/latest/
- Tempo ドキュメント（分散トレース）: https://grafana.com/docs/tempo/latest/
- Grafana Mimir（長期メトリクス）: https://grafana.com/docs/mimir/latest/
- Thanos（長期保存・フェデレーション）: https://thanos.io/
- OpenTelemetry（仕様とCollector）: https://opentelemetry.io/docs/
料金・コンプライアンス参照先
料金や認証は契約やリージョンで異なるため、公式ページで必ず確認してください。
- Datadog 料金ページ（目安）: https://www.datadoghq.com/pricing/
- Grafana Cloud 料金ページ（目安）: https://grafana.com/pricing
- Datadog セキュリティ/コンプライアンス: https://www.datadoghq.com/security/
- Grafana Cloud セキュリティ情報: https://grafana.com/docs/grafana-cloud/latest/security/
結論サマリ：組織規模・スキルセット・要件別の推奨（短期判断）
最短で判断する観点と結論を先に示します。
選定は運用工数、コスト感、データ可搬性、コンプライアンスというトレードオフで決まります。
以下に要点と組織別の短期推奨を示します。
要点サマリ
ここでは判断の核となるポイントを簡潔にまとめます。
- SaaS（Datadog）は迅速導入と統合体験が強みで、運用負荷が低いです。ただしデータ量の増加で費用が増える可能性があるため見積りが重要です（参照：公式料金ページ）。
- 自己運用（Grafana + Prometheus 等）は可搬性と細かなコスト最適化が可能です。ただし運用コストやスケーリング設計が必要です。
- Grafana Cloud は OSS 互換性とマネージド運用のバランスを取る選択肢です。保持・課金条件はプランにより異なるため要検証です（参照：Grafana Cloud 料金）。
組織別の短期推奨
組織やリソースに応じた短期的な候補を提示します。
-
スタートアップ（小規模・短期で価値を出したい）
Datadog が適合しやすいです。迅速に統合監視/APM/ログ/RUMを利用できます。オンボーディング工数を抑えたい場合に有利です。 -
クラウドネイティブSaaS（運用チームあり・将来スケールあり）
Grafana Cloud を第一候補に、将来的に自前運用を目指すなら自己運用（Grafana + Mimir/Loki/Tempo）へ移行する選択が現実的です。 -
大規模エンタープライズ（大量データ・厳しいSLA）
運用体制と要件次第です。自社でスケールできるなら長期TCOを抑えられます。短期での安定性が重要なら SaaS やマネージドのエンタープライズサポートを検討してください。 -
規制業務（金融・医療等）
データ所在、KMS/BYOK、監査要件が厳しい場合は自己運用または専用契約のオプションを検討し、ベンダーのコンプライアンス資料を確認してください（リンク：セキュリティ参照先）。
よくある誤解と落とし穴
導入時によく見る先入観と注意点です。
- 「SaaS は常に安い」→ 初期運用は安価でも、ログ量やカスタムメトリクス増加でコストが大きく変動します。必ず見積りでシミュレーションしてください。
- 「Prometheus があれば移行は簡単」→ ラベル設計やcardinality、remote_write の負荷とコストを検証する必要があります（参照：Prometheus remote_write）。
- 「Loki は全文検索が得意」→ Loki はラベル中心の設計で、インデックス型の全文検索とは性質が異なります。ユースケースにより追加設計が必要です（参照：Loki ドキュメント）。
主要差分の一目でわかる比較表（機能カテゴリ）
各カテゴリでの強みと実務上の注意点を端的に示します。表の後にCSV版も用意しています。
料金や保持の詳細はベンダー公式で必ず確認してください。
| カテゴリ | Datadog（SaaS） | Grafana（自己運用） | Grafana Cloud（マネージド） |
|---|---|---|---|
| メトリクス | 統合UIと多数の組込機能。導入が速い。 注意：カーディナリティ増で費用に影響する可能性あり。 |
PromQL と密な制御。設計次第でコスト低減可能。 注意：長期保持は Mimir/Thanos 等の設計が必要。 |
OSS 互換を保ちつつ運用負荷を軽減。 注意：課金・保持条件は契約で異なるため確認。 |
| ログ | 高機能な検索とパイプライン。導入容易。 注意：ログインジェスト量でコストが変動しやすい。 |
Loki による低コスト設計。ラベル設計が鍵。 注意：全文検索要件は追加検討が必要。 |
マネージド Loki でスケール容易。 注意：インジェストと保持ポリシーはプランで異なる。 |
| トレース（APM） | 自動計装やプロファイリングが強み。操作体験が良い。 注意：サンプリング等の課金影響を検証。 |
Tempo + OpenTelemetry で可搬性高。 注意：サンプリング設計が運用要。 |
マネージド Tempo を提供。 注意：自動計装の利便性はベンダーで差。 |
| 可視化 / ダッシュボード | 統合UIで初心者に扱いやすいテンプレあり。 注意：カスタム表現は Grafana に軍配。 |
カスタマイズ性が高くプラグイン豊富。 注意：複雑なテンプレは運用工数増。 |
Grafana UI をマネージドで提供。 注意：利用可能なプラグインは契約で確認。 |
| アラート | 異常検知や統合通知が充実。 注意：監視対象増でノイズとコストが増える。 |
Alertmanager 等で柔軟ルール設計。 注意：ノイズ対策は自前で設計。 |
統合アラートをマネージドで提供。 注意：通知・エスカレーションの実装を確認。 |
| セキュリティ | セキュリティ製品群との統合がある。 注意：データ所在とエクスポート性を確認。 |
自己管理でデータ主権確保。 注意：SIEM 等は別構築が必要。 |
マネージドでセキュリティ機能を一部提供。 注意：適用範囲は契約で確認。 |
CSV 版（コピーして保存して利用できます）:
|
1 2 3 4 5 |
カテゴリ,Datadog（SaaS）,Grafana（自己運用）,Grafana Cloud（マネージド） メトリクス,"統合UIと多数の組込機能。導入が速い。注意：カーディナリティで費用影響","PromQL と密な制御。設計次第でコスト低減。注意：長期保持はMimir等が必要","OSS互換で運用負荷軽減。注意：課金保持条件は契約で異なる" ログ,"高機能検索とパイプライン。注意：ログ量でコスト変動","Lokiで低コスト。ラベル設計が鍵。注意：全文検索は要追加設計","マネージドLokiでスケール容易。注意：インジェスト保持はプランで異なる" トレース,"自動計装やプロファイラ。注意：サンプリング等で課金影響","Tempo+OpenTelemetryで可搬性高。注意：サンプリング設計が必要","マネージドTempoを提供。注意：自動計装の利便性を確認" |
機能詳細比較：メトリクス、ログ、トレース、合成監視／RUM、可視化、アラート
各領域で実務的に評価すべき点とPOCでの検証項目を示します。
ここでは主要な差分と、検証時の代表的なメトリクスを明示します。
メトリクス収集とクエリ言語（Datadog と PromQL 系）
メトリクス設計は監視コストと運用性に直結します。
- PromQL 系は時系列演算に強く、ラベルを基軸にした細かい制御が可能です。
- Datadog は UI 上での集約やロールアップが豊富で、可視化とセットアップが速いです。
- 検証項目（POC）：ユニーク時系列数、metrics/sec、主要クエリの95p応答時間、recording rules の効果。
- 参照：Prometheus recording rules / remote_write（https://prometheus.io/docs/）。
ログ取り込み・構造化・検索（インデックス型 vs ラベルストリーム型）
ログ設計は検索性と保持コストのトレードオフです。
- Datadog のインデックス型は高速な全文検索と多機能なパイプラインを提供しますが、インジェスト量やインデックス数がコスト要因になります。
- Loki 系はラベル中心の保存で長期保持コストを抑えやすい設計です。ただしインデックスベースの全文検索とは性質が異なり、検索要件に応じた設計が必要です（参照：Loki ドキュメント）。
- 検証項目（POC）：ログGB/日、検索QPS、代表検索クエリの応答時間、インデックス化フィールドの選定。
参照：Loki ドキュメント（検索の設計方針） https://grafana.com/docs/loki/latest/
トレース・RUM・合成監視・アラート（まとめ）
分散トレースとエンドユーザー観測は可観測性の深度に直結します。
- Datadog は自動計装、プロファイリング、RUM 統合など統合体験が強いです。トレース関連は大量スパンの扱いとサンプリング設計でコスト変動があります。料金算定は契約やプランで差が出るため公式を確認してください（参照：Datadog 料金ページ）。
- Tempo / OpenTelemetry は可搬性が高く、ベンダーロックインを避けやすい設計です。ただし自動計装や運用の利便性は追加作業を要する場合があります。
- 検証項目（POC）：スパン数/秒、平均スパンサイズ、ヘッドサンプリングとtail-samplingの効果、RUM→APM 相関の再現性。
参照：OpenTelemetry（https://opentelemetry.io/docs/）
アーキテクチャと導入オプション（Datadog SaaS / Grafana 自己運用 / Grafana Cloud）
導入形態ごとの運用負荷と主な設計ポイントを整理します。
選択は運用リソース、可搬性要件、法規制による制約で決まります。
Datadog（SaaS）の特徴と注意点
Datadog はエージェント経由で収集し、マネージドストレージで可視化する典型的な SaaS です。
利点は迅速な導入と豊富な統合です。注意点として大量データ時のコストやエクスポート性を事前に検証してください（参照：Datadog ドキュメント）。
Grafana 自己運用（Prometheus/Loki/Tempo 等）
Prometheus + 長期ストレージ（Mimir/Thanos）+ Loki + Tempo + Grafana の組合せが典型構成です。
自前でスケール設計・バックアップ・アップグレードを行うため、運用スキルと工数が必要です。設計次第で長期TCOを下げられます。
Grafana Cloud（マネージド）の位置づけと保持戦略
Grafana Cloud は OSS スタックをマネージドで提供します。運用負荷を下げつつ互換性を保てます。
保持戦略は Hot（高分解能短期） / Cold（ダウンサンプリング長期）を基本に設計してください。課金や保持はプランで異なるため事前確認が必要です（参照：Grafana Cloud 料金）。
移行手順とチェックリスト（データ移行・並行運用・切替・ロールバック）
移行は計画と検証が鍵です。ここでは実務で使える順序と検証項目を示します。
各ステップにおいて「死亡率（データ欠落・アラート漏れ）」を最小にすることを目標としてください。
事前準備（インベントリ・マッピング）
事前の棚卸と方針決定が成功の前提です。
- 移行対象のアプリ/サービスを一覧化する（ホスト数・サービス数・カテゴリ）。
- メトリクス一覧とラベル設計、ログソース一覧、トレースのサービスマップを作成する。
- 現行の保持方針と必要な保持期間（SLO・監査要件）を確定する。
- エクスポート要件（フォーマット・帯域・APIレート）を評価する。
データエクスポートと同期（並列配信の推奨）
移行中は二重書き（dual-write）で並行運用し整合を検証します。
- メトリクス：Prometheus が使える場合は remote_write で新環境へ並列送信を行う。Prometheus がない場合は Collector の並列 Export を設定する。
- ログ：ログフォワーダーを設定して既存と新環境へ同時に送る。必要に応じてオブジェクトストレージ（S3 等）にアーカイブを作る。
- トレース：OpenTelemetry Collector を用いて両方へ OTLP 出力するか、サンプリング設定を調整して重要トレースを確実に収集する。
- 歴史データの移行：長期データはアーカイブ→インポートの手順を確立（例：ログの S3 アーカイブ／メトリクスのバックフィル手順）。ベンダーの API 制限とコストに注意する。
参考：OpenTelemetry Collector のマルチエクスポート構成（https://opentelemetry.io/docs/collector/）
並行運用と検証
並行期間に整合性と運用フローを検証します。
- 指定 KPI（ユニーク時系列数、ログGB/日、スパン数/秒、代表クエリ95p）を双方で同時測定する。
- アラートを段階的に新環境へ追加し、誤報率と検出遅延を比較する。
- 運用 runbook（オンコール手順、エスカレーション）を新環境で走らせて実運用の問題点を洗い出す。
- データ差分が許容範囲内（例：1% 未満）であれば切替準備へ進める。
切替とロールバック
切替は段階的かつ可逆に行うことが重要です。
- 切替ウィンドウを設定し、関係者に通知する。低負荷時間帯を選ぶ。
- アラート通知先やダッシュボードの参照先を新環境へ切り替える。まずは非クリティカルなパイプから実施。
- 切替後、監視対象の SLO と検出時間、アラート発生数を一定期間監視する。
- ロールバック条件を事前定義（例：重要アラート未検出、データ欠落割合が閾値超）。ロールバックは旧設定に戻すか、旧パイプラインを再有効化する。設定のスナップショットと自動化スクリプトを用意しておく。
POCテンプレートとTCO試算サンプル
POC と TCO 試算にそのまま使えるテンプレート例を示します。コピペして使える CSV を付けています。
POC 計測テンプレート（CSVサンプル）
以下は POC で収集する代表項目の CSV サンプルです。実運用に合わせて列を拡張してください。
POC_METRICS.csv:
|
1 2 3 4 |
timestamp,metric_name,value,unit,host,labels,notes 2024-01-01T12:00:00Z,cpu.user,0.12,core,host-01,"env=prod,app=web","sample" 2024-01-01T12:00:00Z,http.requests.count,120,req/s,host-01,"env=prod,app=web","peak" |
POC_LOGS.csv:
|
1 2 3 |
timestamp,source,bytes,level,message_sample,labels 2024-01-01T12:00:01Z,app-log,512,INFO,"User logged in","app=web,env=prod" |
POC_TRACES.csv:
|
1 2 3 |
timestamp,trace_id,span_count,avg_span_size_kb,service,notes 2024-01-01T12:00:02Z,abcd1234,5,1.2,web,"sample trace" |
TCO 試算テンプレート（CSV と計算例）
TCO_TEMPLATE.csv（例）:
|
1 2 3 4 5 6 7 8 |
item,unit,quantity,unit_price_month,monthly_cost,notes hosts,count,50,10,500,"例: 管理エージェントのライセンス単価(仮)" metrics_unique,time_series,20000,0.0005,10,"仮: カスタム時系列単価/本" logs_gb,GB,200,0.3,60,"ログインジェスト単価(仮)" traces_spans,spans,1000000,0.00001,10,"トレース単価(仮)" support,monthly,1,1000,1000,"エンタープライズサポート(仮)" monthly_total,,-,-,1580,"月次合計(仮)" |
簡単な計算例（仮の数値）:
月次合計 = ホスト系コスト + メトリクスコスト + ログコスト + トレースコスト + サポート = 1580 USD（仮）
注記：上の単価はサンプルです。実際は各ベンダーの見積りで置き換えてください。
POC チェックリスト（2〜4週間の簡易プラン）
- Week0（準備）：対象アプリ選定、KPI 定義、スクリプト準備、アクセス権設定。
- Week1（導入）：Datadog Agent と Grafana Cloud / OTEL Collector を並列導入。基本ダッシュボードとアラートを構築。
- Week2（負荷検証）：ピークを再現し、クエリ応答・エージェント負荷を測定。高カーディナリティを検証。
- Week3（運用検証）：アラート精度・誤報率を測定し、運用手順を検証。
- Week4（エクスポート・試算）：データエクスポート試験、TCO 算出、最終報告作成。
用語集（スケール系・転送・ログ/トレース関連の定義）
主要用語の短い定義をまとめます。非専門読者が理解しやすい簡潔な説明にしています。
スケール系（Mimir / Thanos）
Mimir や Thanos は Prometheus の長期保存やフェデレーションを支援するコンポーネントです。
これらは大規模環境で時系列データを分散保存・検索するために用いられます。
転送・ルール（remote_write / recording rules）
remote_write は Prometheus が別ストレージへ時系列データを送る設定です。
recording rules は頻出クエリを事前集計し時系列数を削減するための Prometheus のルールです。
ログ/トレース（Loki / Tempo / OpenTelemetry）
Loki はラベル中心でログを管理するシステムです。全文検索とは設計哲学が異なります。
Tempo は分散トレースのストレージで、OpenTelemetry はトレース・メトリクス・ログの共通仕様と Collector を提供します。
セキュリティ・コンプライアンス（検証ポイントと公式ドキュメント）
コンプライアンス要件は契約ごとに範囲が異なります。以下を必ず確認してください。
公式の証明書やドキュメントを取得し、適用範囲を確認した上で判断してください。
主要認証とドキュメント
- SOC 2、ISO 27001、HIPAA 等の証明書が必要かを確定し、ベンダーの該当ドキュメントを確認する。
- Datadog セキュリティ情報: https://www.datadoghq.com/security/
- Grafana Cloud セキュリティ情報: https://grafana.com/docs/grafana-cloud/latest/security/
BYOK / KMS とデータ所在
- BYOK（Bring Your Own Key）や顧客管理の KMS が必要な場合は、契約前にベンダーが対応可能か確認する。
- リージョンやデータ所在の制約（例：国境を越えたデータ転送）がある場合は、その制約を満たすリージョンが提供されるか確認する。
- 主要クラウドの KMS：AWS KMS / GCP KMS / Azure Key Vault をベンダー側でサポートしているかを確認する。
意思決定支援：簡易フローチャートと短縮判定表
短時間で概略判断するための簡易フローチャートをテキストで示します。詳細は必ずPOCで検証してください。
- 運用チームがほとんどいない or 早期導入が最優先 → Datadog（SaaS）を優先候補とする。
- 運用チームがあり Prometheus 互換性や可搬性を重視 → Grafana Cloud を検討。将来的に自前運用へ移行する場合は自己運用を検討。
- 大量データ（ログ/メトリクス/トレース）で長期保存が重要かつ運用体制あり → 自己運用（Mimir/Thanos + オブジェクトストレージ）を評価。
- 規制やBYOKが必須 → データ所在と KMS 対応が明記された選択肢を優先し、営業/法務と合意する。
短縮判定表（組織別推奨）:
- 小規模（〜50ホスト）：Datadog を優先。
- 中規模（50〜500ホスト）：Grafana Cloud を検討し、コスト感を POC で評価。
- 大規模（500+）：自己運用で長期TCOを試算し、必要に応じて混合運用を検討。
FAQ（導入担当者が抱きがちな質問と短い回答）
導入担当者向けの短い Q&A です。
-
両者を併用する意味はあるか？
はい。役割分離（例：メトリクスは Prometheus/Grafana、APM は Datadog）で運用とコストのバランスを取ることが多いです。 -
段階的移行の進め方は？
代表アプリを並行導入し、データ同期とアラート精度を検証後に段階的に切替える方法が安全です。 -
Prometheus の remote_write を Datadog に向けられるか？
技術的には送れるケースがありますが、ラベル設計とネットワーク負荷、コスト影響を事前に評価してください。 -
ログを安価に長期保管する最良策は？
重要フィールドのみをインデックス化し、全文はオブジェクトストレージへアーカイブするのが一般的な手法です。 -
ベンダーロックインをどう評価するか？
使用クエリ、ダッシュボード、API 依存度、データエクスポートの可否と移行工数を定量化してください。
まとめ
本比較は Datadog と Grafana 系の長所とトレードオフを、運用コスト、導入工数、データ可搬性、コンプライアンスの観点で整理しました。
短期判断は 2〜4 週間の POC で「性能・コスト・運用工数」を定量化することを推奨します。
料金・保持・セキュリティは契約やリージョンで変わるため、必ず各社の公式ドキュメントと見積りで最終確認してください。