Prometheus面接質問 2026:Prometheus vs Grafana vs Datadogのモニタリング比較

PrometheusはDevOpsやSREの面接でほぼ必ず取り上げられるテーマで、多くの場合「なぜGrafanaやDatadogではないのか」という質問が続きます。候補者には、Prometheusがメトリクスをどのようにスクレイプして保存するかを説明し、正しいPromQLを書き、マネージドプラットフォームとのトレードオフを論じることが求められます。面接官はこのテーマを通じて、実際の運用経験と教科書的な知識を見分けます。同じトピックはPrometheusとモニタリングの面接モジュールで演習問題として用意されています。

DevOps・SRE面接で問われるPrometheusの質問

Prometheus固有の質問のうち出題頻度の高いものを、自信のある候補者が返す回答とともにまとめます。前提はPrometheus 3.xで、現在の安定版は3.15(2026年9月)、3.16はリリース候補の段階です。

Q: Prometheusがプッシュを受け取るのではなく、メトリクスをプルするのはなぜですか。

プル方式ではターゲットの状態が観測可能になります。スクレイプのたびにup系列が生成されるため、停止したターゲットは沈黙ではなくup == 0として現れます。スクレイプ頻度はサーバー側が制御するので、異常な挙動のクライアントからサーバーを守れます。また、ターゲットの/metricsエンドポイントをブラウザで開けば手作業で確認できます。代償として、Prometheusはネットワーク越しにすべてのターゲットへ到達できなければなりません。短命なバッチジョブにPushgatewayが必要になり、ネットワークをまたぐ構成でremote writeが使われるのはこのためです。

Q: 4つのメトリクスタイプは何ですか。また、サマリーが誤った選択になるのはどのような場合ですか。

カウンター(増加のみ、再起動でリセット)、ゲージ(増減する)、ヒストグラム(観測値をバケットごとに数える)、サマリー(クライアント側で分位数を計算する)の4つです。サマリーの分位数は集約できません。10個のPodのp99を平均しても、サービス全体のp99にはなりません。ヒストグラムはまずインスタンス間で合算し、その後サーバー側で分位数に変換できるため、レイテンシ計測ではヒストグラムが標準です。

# Classic histogram: aggregate the buckets, keep the le label
histogram_quantile(0.99,
  sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

# Native histogram: no _bucket suffix, no le label
histogram_quantile(0.99,
  sum by (job) (rate(http_request_duration_seconds[5m])))

古典的な形式でby句にleを入れ忘れるのは、ライブコーディングで最も多いPromQLの誤りです。クエリは使い物になる結果を返しません。

Q: rate()、irate()、increase()の違いは何ですか。

rate()はレンジ全体の1秒あたり平均を返し、カウンターのリセットにも対応します。irate()はレンジ内の最後の2サンプルだけを使うため反応は速いもののノイズが多く、拡大表示したグラフには向いていますが、アラートには向きません。increase()はrate()にレンジの長さを掛けたものです。Prometheusはウィンドウの境界まで外挿するため、整数のカウンターに対するincrease()が整数以外の値を返すことがあり、面接官はその理由をよく尋ねます。

Q: カーディナリティとは何ですか。カーディナリティ爆発はどのように診断しますか。

メトリクス名とラベル値の組み合わせごとに、別々の時系列がメモリ上に保持されます。user_id、email、IDを含む生のURLパスのようなラベルは系列数を増やし続け、最終的にサーバーのメモリを使い果たします。診断はTSDBステータスページ(/tsdb-status)か、次のクエリから始めます。

# Top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

対処はソース側で行います。metric_relabel_configsでラベルを削除または書き換えるか、スクレイプジョブにsample_limitを設定して、1つの不具合のあるデプロイでサーバー全体が停止しないようにします。

Q: レコーディングルールは何のためにありますか。

コストの高い式を評価間隔ごとに事前計算し、その結果を新しい系列として保存します。ダッシュボードやアラートは、事前計算された軽い系列をクエリします。命名規則はlevel:metric:operationsです。

groups:
  - name: api-recording-rules
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

Q: アラートルールのfor句は何をしますか。

式が真になったアラートはinactiveからpendingに移り、条件がforの期間ずっと成立した場合にだけfiringに達します。これにより、1回のスクレイプだけで終わる一時的な変動が除外されます。keep_firing_forはその逆で、条件が解消した後もしばらくアラートを発火状態に保ち、フラッピングするアラートで2回呼び出されるのを防ぎます。

Q: Prometheusを高可用性にするにはどうしますか。

同じターゲットをスクレイプする同一構成のレプリカを2台動かし、それぞれに異なるreplica外部ラベルを付けます。両方がAlertmanagerクラスターにアラートを送り、Alertmanagerはゴシッププロトコルで通知を重複排除します。クエリについては、Thanos QueryまたはMimirがreplicaラベルを無視して2つの系列を重複排除します。Prometheus自体にクラスタリング機能はなく、単一サーバーのローカルTSDBはレプリケーションされません。

Q: マルチクラスター構成ではフェデレーションとremote writeのどちらを使いますか。

フェデレーションでは、グローバルなPrometheusが各クラスターのPrometheusの/federateエンドポイントから、選択した系列(通常は集約済みの系列)をスクレイプします。少数のロールアップに向いています。remote writeはすべてのサンプルをMimir、Thanos Receive、ベンダーのバックエンドなどの中央ストアにストリーミングする方式で、グローバルなクエリと長期保存における標準的な答えです。

Q: サービスディスカバリから消えたターゲットはどのように検知しますか。

up == 0が発火するのは、ターゲットがまだディスカバリされている間だけです。Podやサービスディスカバリのエントリがなくなると系列そのものが存在しなくなり、アラートは発火しません。このケースはabsent(up{job="api-server"})で検知します。

Q: Prometheus 3で何が変わりましたか。

Prometheus 3.0(2024年11月)では新しいUIが導入され、メトリクス名とラベル名にUTF-8文字が使えるようになり、/api/v1/otlp/v1/metricsに組み込みのOTLPレシーバーが追加されました(--web.enable-otlp-receiverで有効化)。ネイティブヒストグラムは3.8で安定版になりました。3.9以降は従来のフィーチャーフラグが何の効果も持たず、取り込みにはスクレイプ設定またはグローバル設定でscrape_native_histograms: trueが必要です。3.15ではXOR2のfloatチャンクエンコーディングが安定版になり、OpenMetrics 2.0のスクレイプが追加されました。

アーキテクチャとデータモデル:各ツールのメトリクスの扱い方

Prometheusの基礎を確認した後、面接官は通常、3つのツールのアーキテクチャ上の違いに話を移します。

Prometheusはプルベースモデルを採用しています。設定された間隔でHTTPエンドポイント(通常は/metrics)をスクレイプし、独自のローカルTSDB(時系列データベース)にデータを保存します。各時系列はメトリクス名とキーバリューラベルの組み合わせで識別されます。3.x系では、安定版のネイティブヒストグラム、OTLPレシーバー、中央ストレージにサンプルを送るためのRemote Write 2.0が加わっています。

Grafana自体はメトリクスの収集や保存を行いません。Prometheus、Loki、Tempo、InfluxDB、Elasticsearchなど100以上のデータソースに接続し、それらのデータからダッシュボードを描画します。Grafana Labsは、Mimir(長期メトリクスストレージ)、Loki(ログ集約)、Tempo(分散トレーシング)も開発・保守しており、これらとGrafanaでオープンソースのLGTMスタックを構成しています。2026年4月のGrafanaCONで発表されたGrafana 13では、ダッシュボードのGit Syncが一般提供(GA)となり、動的ダッシュボードがデフォルトで有効になり、grafana-cliとgrafana-serverコマンドが削除されました。

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

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

scrape_configs:
  - job_name: 'api-server'
    scrape_native_histograms: true
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

このYAMLは、Prometheusのプルモデルを定義しています。Kubernetesのサービスディスカバリを使用してPodを検出し、prometheus.io/scrape: "true"アノテーションが付いたPodだけを残し、アドレスをアノテーションで指定されたポートに書き換えたうえで、15秒間隔で/metricsをスクレイプします。2つ目のルールは2つのソースラベルを;で連結するため、正規表現はhost:port;portにマッチする形になっています。

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

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

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

# 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のクエリ言語は、関数とスコーピングを中心に構築された異なる構文を使用します。

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

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

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

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

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

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

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

# 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 9以降のデフォルト)は、接続されたあらゆるデータソースのクエリを評価し、通知ポリシーによる多次元アラートをサポートしています。

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

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

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

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

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

PrometheusはKubernetesエコシステムにおけるデフォルトのメトリクスシステムであり、コンテナオーケストレーションのモニタリングに関する面接では最も中心的なトピックとなっています。

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

# 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)を使用して、スクレイプターゲットを宣言的に設定します。このようにチャートの値を上書きする方法は、Helmチャートの面接ガイドで詳しく扱っています。

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.xは--web.enable-otlp-receiverを設定すればOTLPメトリクスを直接受け入れるため、中間のCollectorはもはや必須ではありません。Grafana Alloy(Grafana Agentの後継)はOTel CollectorとPrometheusスクレイパーの両方の役割を果たします。DatadogはOTLPインジェストをサポートしていますが、「フル機能へのアクセス」のために独自エージェントを推奨しており、ソフトロックインが発生します。

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

3つのツールを比較するオブザーバビリティの面接質問

Prometheus単体の質問に加えて、以下の質問では複数のツールにまたがって推論できるかどうかが試されます。各回答は、面接官が確認しようとしている概念を明確にしています。

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日)とエラーバジェット消費率への言及が期待されます。

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

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

出典

• Prometheus releases:3.15.0(2026年9月)でXOR2チャンクエンコーディングが安定版となり、OpenMetrics 2.0のスクレイプが追加され、--log.levelが非推奨になりました
• Prometheus native histograms specification:3.8から安定版、3.9からscrape_native_histogramsが必須です
• What's new in Grafana 13.0:Git SyncのGA、動的ダッシュボードのデフォルト化、破壊的変更
• Datadog list pricing:コスト表で使用したインフラ、APM、ログの価格
• Datadog algorithmic functions:anomalies()とforecast()の構文

Prometheusとオブザーバビリティの面接で押さえておくべきこと

• PrometheusはKubernetes環境におけるメトリクス収集の標準です。プルとプッシュの違い、4つのメトリクスタイプ、rate()とirate()の違い、カーディナリティ、高可用性は確実に説明できるようにしておきます
• Prometheus 3.9以降では、scrape_native_histograms: trueを設定しない限りネイティブヒストグラムは取り込まれません
• Grafanaはメトリクスデータベースではなく可視化レイヤーであり、Prometheusを含む100以上のデータソースに接続できます。LGTMスタック(Loki、Grafana、Tempo、Mimir)がオープンソースの完全なオブザーバビリティプラットフォームを構成します
• Datadogは組み込みの異常検知を備え、フルスタックオブザーバビリティへの最短経路を提供しますが、価格が高くベンダーロックインのリスクがあります
• OpenTelemetryの採用により、バックエンドの選択はより柔軟になっています。どのツールがデータを保存・クエリするかに関わらず、計装コードは同一に保てます
• 面接では、1つのツールを推すのではなく、コスト、制御性、複雑さについてトレードオフを論理的に検討する能力を示すことが重要です
• 幅広い対策には、面接官がモニタリングに続けて問う隣接トピックを扱ったDevOps面接の必須質問集が役立ちます