# Prometheus vs Grafana vs Datadog 2026年比較:モニタリングアーキテクチャとDevOps面接対策

> Prometheus、Grafana、Datadogの2026年最新比較。アーキテクチャ、価格、アラート戦略の違いと、DevOps面接で頻出するオブザーバビリティ質問を体系的に解説します。

- Published: 2026-06-20
- Updated: 2026-06-20
- Author: SharpSkill
- Tags: prometheus, grafana, datadog, monitoring, observability, devops, kubernetes, interview
- Reading time: 12 min

---

Prometheus、Grafana、Datadogは、2026年現在のDevOps面接において最も頻出する比較テーマの1つです。各ツールのアーキテクチャ、強み、トレードオフを正確に理解していることは、教科書的な知識ではなく実務経験を示すシグナルとして、採用担当者に高く評価されます。本記事では、prometheus interviewやdevops monitoringの面接で問われるポイントを体系的に整理し、observability interviewに備えるための実践的な知識を提供します。

> **面接で押さえるべき基本区分**
>
> Prometheusはメトリクスの収集・保存エンジンです。Grafanaは可視化・ダッシュボード構築のレイヤーです。DatadogはフルマネージドのオブザーバビリティSaaSプラットフォームです。この3つは異なる課題を解決するものであり、直接的に競合するというよりも、互いに補完し合う関係にあります。

## アーキテクチャとデータモデル:メトリクス処理の根本的な違い

アーキテクチャの違いは、この3つのツールを理解する上で最も基本的な要素です。grafana interview questionsやprometheus interviewでは、この点について深い理解を持っているかが頻繁に問われます。

**Prometheus**はプルベースモデルを採用しています。設定された間隔でHTTPエンドポイント(通常は`/metrics`)をスクレイプし、独自のローカルTSDB(時系列データベース)にデータを保存します。各時系列はメトリクス名とキーバリューラベルの組み合わせで識別されます。2024年11月にリリースされたPrometheus 3.0では、ネイティブヒストグラムがv3.8で安定版に到達し、OTLPインジェストが組み込みで対応され、Remote Write 2.0によりクラスター間のフェデレーションが改善されています。

**Grafana**自体はメトリクスの収集や保存を行いません。Prometheus、Loki、Tempo、InfluxDB、Elasticsearchなど100以上のデータソースに接続し、それらのデータからダッシュボードを描画します。Grafana Labsは、Mimir(長期メトリクスストレージ)、Loki(ログ集約)、Tempo(分散トレーシング)も開発・保守しており、Grafanaと組み合わせてオープンソースの完全なオブザーバビリティスタックを構成しています。2026年5月にリリースされたバージョン13では、Observability-as-Codeツール、ダッシュボードのGit Sync、クロスソースクエリのためのSQL Expressionsが搭載されています。

**Datadog**はプッシュベースのSaaSとして動作します。ホストにインストールされたエージェントがメトリクス、ログ、トレースをDatadogのクラウドバックエンドにプッシュします。インジェスト、ストレージ、クエリ、アラート、ダッシュボードのすべてが単一のマネージドプラットフォームに統合されています。WatchdogのMLエンジンが手動での閾値設定なしに異常検知を自動的に実行する点が特徴的です。

```yaml
# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}
```

このYAMLは、Prometheusのプルモデルを定義しています。Kubernetesのサービスディスカバリを使用してPodを検出し、15秒間隔で`/metrics`エンドポイントをスクレイプします。

## PromQLとDatadogクエリ言語:構文と機能の比較

クエリ言語は、devops monitoringの面接で頻出するトピックです。少なくとも1つの言語に流暢であることを示し、それぞれのトレードオフを説明できることが求められます。

**PromQL**(Prometheus Query Language)は、PrometheusおよびGrafanaエコシステム全体でのメトリクスクエリの標準言語です。インスタントベクタ、レンジベクタ、集約演算子、レコーディングルールをサポートしています。

```promql
# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0
```

**Datadogのクエリ言語**は、関数とスコーピングを中心に構築された異なる構文を使用します。

```text
# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)
```

PromQLはアドホック分析においてより深い表現力を持っています。一方、Datadogのクエリ言語は一部の柔軟性と引き換えに、`anomaly()`や`forecast()`のような組み込みML関数を提供しており、Prometheusスタックでは外部ツールが必要となる機能を標準で利用できます。

## アラート戦略:ルールベース vs ML駆動型検知

アラートの設計哲学は、ツール間で大きく異なります。この違いを理解していることは、observability interviewにおいて運用成熟度を示す重要な指標となります。

**Prometheus Alertmanager**は、固定間隔でルールを評価し、グルーピング、サイレンシング、インヒビションを備えた設定可能なパイプラインを通じてアラートをルーティングします。

```yaml
# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning
```

このアプローチでは、運用者が明示的な閾値を定義する必要があります。利点はすべてのアラートにレビュー可能な式が存在し、完全な透明性が確保される点です。課題は閾値疲労で、静的な値は季節変動に応じた調整が必要になることがあります。

**Grafana Alerting**(Grafana 12以降で統合)は、接続されたあらゆるデータソースのクエリを評価し、通知ポリシーによる多次元アラートをサポートしています。

**Datadog Monitors**は、静的閾値とML駆動の異常検知、外れ値検知、予測モニターを組み合わせています。Watchdogは手動でのルール作成なしにパフォーマンス異常を自動的にフラグ付けします。これにより設定のオーバーヘッドは軽減されますが、検知ロジックの透明性は低下します。

## 2026年の価格体系と総所有コスト比較

価格体系は実際のツール選定における決定要因であり、システム設計面接でも頻繁に取り上げられます。コスト構造を理解していることは、ビジネス視点を持ったエンジニアとしての評価につながります。

| 比較項目 | Prometheus + Grafana | Datadog |
|-----------|---------------------|--------|
| **ライセンス** | 無料 (AGPL / Apache 2.0) | $15-31/ホスト/月 (年間契約) |
| **メトリクスストレージ** | セルフマネージド (Mimir/Thanos) | 含まれる、リテンション課金 |
| **ログ管理** | Loki (セルフホスト) | $0.10/GBインジェスト + インデキシング |
| **APM / トレース** | Tempo (セルフホスト) | $31/ホスト/月 |
| **インフラコスト** | スタック用のコンピュート + ストレージ | なし (SaaS) |
| **運用オーバーヘッド** | 高い (アップグレード、スケーリング、HA) | 最小限 |
| **年間推定コスト (50ホスト)** | $20K-60K (インフラ + エンジニアリング) | $50K-150K |
| **ベンダーロックインリスク** | 低い (OpenTelemetry、PromQL) | 高め (独自クエリ言語) |

オープンソーススタックは表面上はコストが低く見えますが、アップグレード、キャパシティプランニング、高可用性構成に専任のエンジニアリング工数が必要です。Datadogのマネージドモデルは、その負担をベンダーに移転します。インフラストラクチャを運用するエンジニアが5名未満のチームでは、エンジニアリング工数を考慮すると、マネージドソリューションの方が総コストが低くなるケースが多くあります。

## Kubernetesモニタリング:統合の深さの比較

Kubernetesクラスターの80%以上がメトリクス収集にPrometheusを使用しており、コンテナオーケストレーションのモニタリングに関する面接では最も重要なトピックとなっています。

**Prometheus + Grafana**は、[kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) Helmチャートを通じてKubernetesとネイティブに統合されます。このチャートにより、Prometheus Operator、Alertmanager、node-exporter、kube-state-metrics、事前構築済みのGrafanaダッシュボードが単一のインストールでデプロイされます。

```bash
# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi
```

このコマンドにより、永続ストレージと30日間のリテンションを備えた本番グレードのモニタリングスタックがデプロイされます。Prometheus OperatorはCustom Resource Definition(ServiceMonitor、PodMonitor)を使用して、スクレイプターゲットを宣言的に設定します。

**Datadog**はエージェントDaemonSetとCluster Agentをデプロイします。Cluster AgentがAPIサーバーとの通信を一元管理することで、Kubernetes APIへの負荷を軽減します。DatadogのLive Containersビューはpodの状態をリアルタイムで可視化し、Orchestrator ExplorerはDeployment、Service、Pod間の関係をマッピングします。

すでにKubernetesエコシステムに深く投資しているチームにとっては、Prometheusネイティブのアプローチが外部依存を導入しない選択肢となります。一方、運用投資を抑えつつ迅速なセットアップを優先するチームはDatadogを選択する傾向にあります。

## OpenTelemetryとベンダー中立性

OpenTelemetry(OTel)は計装の業界標準となっており、モニタリングツール比較の面接で併せて問われることが増えています。

Prometheus 3.0以降はOTLPメトリクスをネイティブに受け入れ、中間にCollectorを必要としません。Grafana Alloy(Grafana Agentの後継)はOTel CollectorとPrometheusスクレイパーの両方の役割を果たします。DatadogはOTLPインジェストをサポートしていますが、「フル機能へのアクセス」のために独自エージェントを推奨しており、ソフトロックインが発生します。

OTelの採用が重要である理由は、計装とバックエンドの選択を分離できる点にあります。OTel SDKで計装されたアプリケーションコードは、コードの変更なしにPrometheus、Grafana Cloud、Datadog、その他の互換バックエンドにテレメトリを送信できます。この柔軟性は、システム設計面接において長期的なオブザーバビリティ戦略を議論する際の強力な論点となります。

## DevOps面接で問われるモニタリングとオブザーバビリティの質問

以下の質問は、DevOpsおよびSREの面接で頻繁に出題されます。各回答は、面接官がテストしようとしている概念を明確にしています。

**Q: モニタリング、オブザーバビリティ、アラートの違いを説明してください。**

モニタリングは事前定義されたメトリクスを追跡し、既知の障害パターンを検出します。オブザーバビリティはメトリクス、ログ、トレース(「3本の柱」)を通じて未知の障害パターンの調査を可能にします。アラートは、定義された閾値または異常ベースラインを超えた際に通知をトリガーします。モニタリングは「システムは正常か」に回答し、オブザーバビリティは「なぜシステムが異常なのか」に回答します。

**Q: Prometheusがモニタリングに適さないケースはどのような場合ですか。**

Prometheusは耐久性よりも信頼性に最適化されており、モニタリングシステム自体の可用性を優先します。Prometheusが苦手とするシナリオとしては、30日を超える長期ストレージ(Thanos/Mimir/Cortexが必要)、100%の精度が求められるリクエスト単位の課金データ(高負荷時にサンプルがドロップされる可能性がある)、プッシュベースの収集が必要なイベントベースシステム(pushgatewayが回避策として存在)が挙げられます。

**Q: Grafanaの「Big Tent」哲学はオブザーバビリティアーキテクチャにどのような影響を与えますか。**

Grafanaはデータ移行を必要とせずに任意のデータソースに接続できます。これは、Prometheus、Elasticsearch、CloudWatch、Datadogを単一のダッシュボードからクエリできることを意味します。トレードオフは運用の複雑さであり、複数のバックエンドを維持するには単一ベンダーのアプローチよりもインフラストラクチャの専門知識が必要になります。面接官は、候補者がこのトレードオフを明確に表現できるかどうかをテストしています。

**Q: DatadogのHigh-Watermark課金とはどのような仕組みで、なぜ重要ですか。**

Datadogは1時間ごとにホスト数を計測し、上位1%の時間帯を除外して99パーセンタイルのピークで課金します。つまり、一時的なオートスケーリングのスパイク(ブラックフライデーのトラフィックなど)は、インスタンスが終了した後でも月額料金を引き上げます。この点に言及できる候補者は、コスト管理に関する実務経験を持っていることを示しており、SREの職種ではこのスキルがますます求められています。

**Q: PrometheusとDatadogでSLOベースのアラート戦略はどのように異なりますか。**

Prometheusでは、レコーディングルールを使用してエラーバジェットとバーンレートアラートを事前計算します(GoogleのSRE本に記載されたマルチウィンドウ・マルチバーンレート手法)。Datadogは組み込みのSLOウィジェットとモニターでバーンレートを自動的に追跡します。両方のアプローチは同じコンセプトを実装していますが、Prometheusはより多くの手動設定が必要で、Datadogはマネージドワークフローを提供します。回答には、バーンレートウィンドウ(1時間、6時間、3日)とエラーバジェット消費率への言及が期待されます。

モニタリングトピックをより深く対策するには、[DevOps面接対策モジュール](/technologies/devops/interview-questions/monitoring-prometheus)で追加のシナリオと詳細な解説を確認できます。

## 意思決定フレームワーク:最適なスタックの選択

| シナリオ | 推奨スタック | 根拠 |
|----------|------------|------|
| スタートアップ、エンジニア10名未満 | Datadog または Grafana Cloud | 運用オーバーヘッドの最小化 |
| プラットフォームチームを持つ大規模組織 | Prometheus + Grafana + Loki | 完全な制御、スケール時の低単価コスト |
| マルチクラウド / ハイブリッド | Prometheus + Grafana | ベンダー中立、環境間の一貫性 |
| コンプライアンス重視 (金融、医療) | セルフホストの Prometheus + Grafana | データを社内に保持 |
| 急速なスケーリング、予測困難な成長 | Grafana Cloud (マネージドMimir) | インフラ管理なしでスケール |
| ML駆動の異常検知が必要 | Datadog | Watchdogは設定不要 |

最適な選択は、チームの規模、運用成熟度、予算制約の3つの変数に依存します。普遍的に正しい答えは存在せず、面接官は1つのツールを推奨するのではなく、トレードオフを論理的に検討できる能力を期待しています。

## まとめ

- Prometheusは、Kubernetes環境におけるメトリクス収集の標準であり、バージョン3.xではネイティブOTLPサポートと安定したネイティブヒストグラムが2026年に実現されている
- Grafanaはメトリクスデータベースではなく可視化レイヤーであり、Prometheusを含む100以上のデータソースに接続できる。LGTMスタック(Loki、Grafana、Tempo、Mimir)がオープンソースの完全なオブザーバビリティプラットフォームを構成する
- DatadogはML駆動のアラートによるフルスタックオブザーバビリティへの最短経路を提供するが、価格が高くベンダーロックインのリスクがある
- OpenTelemetryの採用により、バックエンドの選択はより柔軟になっている。どのツールがデータを保存・クエリするかに関わらず、計装コードは同一に保てる
- 面接では、1つのツールを推すのではなく、コスト、制御性、複雑さについてトレードオフを論理的に検討する能力を示すことが重要である
- 実践的な対策には[DevOps面接の必須質問集](/blog/devops/essential-devops-interview-questions)を活用し、[CI/CDパイプラインの面接対策](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins)で隣接する知識領域を強化することを推奨する

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/devops/prometheus-vs-grafana-vs-datadog-monitoring-devops-interview