Questions d'entretien Prometheus 2026 : Prometheus vs Grafana vs Datadog comparés

Les questions d'entretien sur Prometheus reviennent dans presque tous les processus DevOps et SRE, et elles débouchent souvent sur « pourquoi pas Grafana ou Datadog ? ». Le candidat doit expliquer comment Prometheus collecte et stocke les métriques, écrire du PromQL correct et défendre les compromis face à une plateforme managée. Les recruteurs s'en servent pour distinguer une vraie expérience opérationnelle d'un savoir de manuel. Le module d'entretien Prometheus et monitoring reprend les mêmes thèmes sous forme de questions d'entraînement.

Questions d'entretien Prometheus posées en DevOps et SRE

Voici les questions propres à Prometheus qui reviennent le plus souvent, avec la réponse qu'attend le recruteur. Elles supposent Prometheus 3.x : la ligne stable actuelle est la 3.15 (septembre 2026), la 3.16 étant en release candidate.

Q : Pourquoi Prometheus récupère-t-il les métriques en pull plutôt que de recevoir des push ?

Le pull rend la santé des cibles observable : chaque scrape produit une série up, donc une cible morte apparaît comme up == 0 au lieu de disparaître en silence. Le serveur contrôle la fréquence de scrape, ce qui le protège d'un client défaillant, et une cible se vérifie à la main en ouvrant son endpoint /metrics dans un navigateur. La contrepartie : Prometheus doit joindre chaque cible par le réseau. C'est pour cela que les jobs batch de courte durée passent par le Pushgateway et que les architectures multi-réseaux utilisent le remote write.

Q : Quels sont les quatre types de métriques, et quand un summary est-il le mauvais choix ?

Counter (ne fait que croître, repart à zéro au redémarrage), gauge (monte et descend), histogram (observations comptées dans des buckets) et summary (quantiles calculés côté client). Les quantiles d'un summary ne s'agrègent pas : la moyenne des p99 de dix pods ne donne pas le p99 du service. Les histogrammes, eux, s'additionnent d'abord entre instances puis se convertissent en quantile côté serveur, ce qui en fait le choix par défaut pour la latence.

# 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])))

Oublier le dans la clause by de la forme classique est l'erreur PromQL la plus fréquente en live coding : la requête ne renvoie rien d'exploitable.

Q : Quelle différence entre rate(), irate() et increase() ?

rate() renvoie la moyenne par seconde sur toute la fenêtre et gère les remises à zéro des counters. irate() n'utilise que les deux derniers échantillons de la fenêtre : il réagit vite mais reste bruité, ce qui convient à un graphe zoomé et pas à l'alerting. increase() vaut rate() multiplié par la durée de la fenêtre. Comme Prometheus extrapole jusqu'aux bornes de la fenêtre, increase() appliqué à un counter entier peut renvoyer une valeur non entière, et les recruteurs aiment demander pourquoi.

Q : Qu'est-ce que la cardinalité, et comment diagnostiquer une explosion de cardinalité ?

Chaque combinaison unique d'un nom de métrique et de valeurs de labels est une série temporelle distincte gardée en mémoire. Un label comme user_id, email ou un chemin d'URL brut contenant des identifiants multiplie le nombre de séries jusqu'à épuiser la mémoire du serveur. Le diagnostic commence sur la page de statut de la TSDB (/tsdb-status) ou par une requête :

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

La correction se fait à la source : supprimer ou réécrire le label avec metric_relabel_configs, ou fixer un sample_limit sur le job de scrape pour qu'un seul déploiement fautif ne fasse pas tomber le serveur.

Q : À quoi servent les recording rules ?

Elles précalculent une expression coûteuse à chaque intervalle d'évaluation et stockent le résultat dans une nouvelle série. Dashboards et alertes interrogent ensuite cette série précalculée, peu coûteuse. La convention de nommage est level:metric:operations :

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

Q : Que fait la clause for dans une règle d'alerte ?

Une alerte dont l'expression devient vraie passe de inactive à pending, et n'atteint firing qu'une fois la condition maintenue pendant la durée for. Cela filtre les anomalies d'un seul scrape. keep_firing_for fait l'inverse : il maintient l'alerte active un moment après la disparition de la condition, ce qui évite qu'une alerte instable déclenche deux pages.

Q : Comment rendre Prometheus hautement disponible ?

Deux réplicas identiques scrapent les mêmes cibles, chacun avec un external label replica distinct. Les deux envoient leurs alertes à un cluster Alertmanager, qui déduplique les notifications grâce à son protocole gossip. Côté requêtes, Thanos Query ou Mimir déduplique les deux séries en ignorant le label de réplica. Prometheus lui-même n'a pas de clustering : la TSDB locale d'un serveur n'est pas répliquée.

Q : Fédération ou remote write pour une architecture multi-cluster ?

La fédération permet à un Prometheus global de scraper des séries choisies, généralement agrégées, sur l'endpoint /federate du Prometheus de chaque cluster. Elle convient à un petit ensemble d'agrégats. Le remote write envoie chaque échantillon vers un stockage central comme Mimir, Thanos Receive ou un backend éditeur : c'est la réponse standard pour les requêtes globales et la rétention longue.

Q : Comment détecter une cible disparue du service discovery ?

up == 0 ne se déclenche que tant que la cible est encore découverte. Si le pod ou l'entrée de service discovery a disparu, la série cesse d'exister et l'alerte ne se déclenche jamais. absent(up{job="api-server"}) couvre ce cas.

Q : Qu'est-ce qui a changé avec Prometheus 3 ?

Prometheus 3.0 (novembre 2024) a livré une nouvelle interface, autorisé les caractères UTF-8 dans les noms de métriques et de labels, et ajouté un récepteur OTLP intégré sur /api/v1/otlp/v1/metrics, activé avec --web.enable-otlp-receiver. Les histogrammes natifs sont devenus stables en 3.8. Depuis la 3.9, l'ancien feature flag ne fait plus rien et l'ingestion exige scrape_native_histograms: true dans la configuration de scrape ou globale. La 3.15 a stabilisé l'encodage de chunks flottants XOR2 et ajouté le scrape OpenMetrics 2.0.

Architecture et modèle de données comparés

Une fois les fondamentaux de Prometheus couverts, les recruteurs passent en général aux différences d'architecture entre les trois outils.

Prometheus repose sur un modèle pull-based. Le serveur interroge des endpoints HTTP (généralement /metrics) à des intervalles configurables et stocke les données de séries temporelles dans une base de données temporelle locale (TSDB) qui lui est propre. Chaque série temporelle est identifiée par un nom de métrique et un ensemble de labels clé-valeur. La ligne 3.x apporte des histogrammes natifs stables, un récepteur OTLP et Remote Write 2.0 pour envoyer les échantillons vers un stockage central.

Grafana ne collecte ni ne stocke lui-même de métriques. Il se connecte à des sources de données, parmi lesquelles Prometheus, Loki, Tempo, InfluxDB, Elasticsearch et plus de 100 autres, puis génère des dashboards à partir de leurs données. Grafana Labs développe en outre Mimir (stockage de métriques à long terme), Loki (agrégation de logs) et Tempo (tracing distribué), qui forment avec Grafana la stack open-source LGTM. Grafana 13, annoncé à la GrafanaCON d'avril 2026, a rendu Git Sync pour les dashboards généralement disponible, activé les dashboards dynamiques par défaut et supprimé les commandes grafana-cli et grafana-server.

Datadog fonctionne comme un service SaaS push-based. Des agents installés sur les hôtes envoient métriques, logs et traces vers le backend cloud de Datadog. L'ensemble des fonctions, ingestion, stockage, requêtage, alerting et dashboarding, réside au sein d'une plateforme managée unique. Le moteur Watchdog signale automatiquement les anomalies, sans configuration manuelle de seuils.

# 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__

Ce YAML définit le modèle pull de Prometheus : il découvre les pods Kubernetes via le service discovery, ne garde que ceux annotés prometheus.io/scrape: "true", réécrit l'adresse vers le port annoté et scrape /metrics toutes les 15 secondes. La seconde règle joint les deux labels source avec ;, ce qui explique que la regex corresponde à host:port;port.

PromQL vs. langage de requête Datadog

Les langages de requête comptent parmi les sujets techniques les plus fréquents en entretien sur le thème du monitoring. On attend d'un candidat qu'il maîtrise couramment au moins l'un d'eux et qu'il sache expliquer les compromis respectifs.

PromQL (Prometheus Query Language) est le standard dans tout l'écosystème Prometheus et Grafana. Le langage prend en charge les instant vectors, les range vectors, les opérateurs d'agrégation et les recording rules.

# 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

Le langage de requête de Datadog adopte une autre approche, construite autour d'appels de fonctions et de scoping :

# 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 offre une expressivité supérieure pour l'analyse ad-hoc. Le langage de Datadog échange une partie de cette flexibilité contre des fonctions algorithmiques intégrées comme anomalies() (algorithmes basic, agile, robust) et forecast() (linear, seasonal), qui nécessiteraient un tooling externe dans une stack Prometheus.

Stratégies d'alerting : basé sur des règles vs. assisté par ML

La philosophie d'alerting diffère profondément d'un outil à l'autre. Comprendre ces différences signale, en entretien, une maturité opérationnelle.

Prometheus Alertmanager reçoit les alertes issues des règles que Prometheus évalue à intervalles fixes, puis les achemine via un pipeline configurable avec grouping, silencing et inhibition :

# 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

Cette approche exige la définition explicite de seuils. L'avantage réside dans une transparence totale : chaque alerte possède une expression vérifiable. L'inconvénient est ce que l'on nomme la threshold fatigue, car les seuils statiques doivent souvent être ajustés aux variations saisonnières.

Grafana Alerting (le système d'alerting unifié, par défaut depuis Grafana 9) évalue des requêtes sur n'importe quelle source de données connectée et prend en charge des alertes multidimensionnelles avec des notification policies.

Les Monitors de Datadog combinent des seuils statiques avec des monitors d'anomalie, d'outlier et de forecast. Watchdog signale automatiquement les anomalies de performance, sans qu'il soit nécessaire de créer des règles manuelles. Cela réduit l'effort de configuration, au prix d'une moindre transparence sur la logique de détection.

Coûts et coût total de possession (TCO) en 2026

La tarification est, dans la pratique, un facteur décisif dans le choix d'un outil et revient régulièrement dans les entretiens de system design. Les candidats capables de comprendre et d'articuler les structures de coûts démontrent une conscience business. Les montants Datadog ci-dessous sont les prix catalogue en facturation annuelle.

Sur le papier, la stack open-source paraît moins chère, mais elle exige du temps d'ingénierie dédié pour les upgrades, la planification de capacité et la configuration de haute disponibilité. Le modèle managé de Datadog transfère cet effort vers l'éditeur. Pour des équipes de moins de cinq ingénieurs d'infrastructure, les solutions managées ont souvent un coût total inférieur dès lors que l'on intègre le temps d'ingénierie.

Monitoring Kubernetes : profondeur d'intégration comparée

Prometheus est le système de métriques par défaut de l'écosystème Kubernetes, ce qui en fait le sujet dominant des entretiens sur le monitoring de l'orchestration de conteneurs.

Prometheus + Grafana s'intègre nativement via le Helm Chart kube-prometheus-stack. Ce chart déploie Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics et des dashboards Grafana préconfigurés en une seule installation :

# 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

Cette commande déploie une stack de monitoring prête pour la production, avec un stockage persistant et 30 jours de rétention des données. Le Prometheus Operator utilise des Custom Resource Definitions (ServiceMonitor, PodMonitor) pour configurer les scrape targets de manière déclarative. La surcharge des valeurs d'un chart de cette façon est détaillée dans le guide d'entretien sur les charts Helm.

Datadog déploie un DaemonSet d'agents et un Cluster Agent. Le Cluster Agent prend en charge de manière centralisée la communication avec l'API server de Kubernetes et réduit ainsi la charge sur l'API. La vue Live Containers offre une visibilité en temps réel sur l'état des pods, et l'Orchestrator Explorer visualise les relations entre deployments, services et pods.

Pour les équipes déjà investies dans l'écosystème Kubernetes, l'approche Prometheus-native évite d'introduire une dépendance externe. Les équipes qui privilégient une mise en place rapide avec un effort opérationnel réduit penchent plutôt vers Datadog.

OpenTelemetry et neutralité vis-à-vis des éditeurs

OpenTelemetry (OTel) s'est imposé comme le standard industriel pour l'instrumentation des applications. En entretien, la question du rôle d'OTel dans le contexte des comparatifs de monitoring est de plus en plus posée.

Prometheus 3.x accepte directement les métriques OTLP dès que --web.enable-otlp-receiver est activé, sans qu'un Collector soit nécessaire comme intermédiaire. Grafana Alloy, le successeur de Grafana Agent, fait office à la fois d'OTel Collector et de scraper Prometheus. Datadog prend en charge l'ingestion OTLP, mais recommande ses agents propriétaires pour bénéficier de « toutes les fonctionnalités », une forme de vendor lock-in soft.

L'importance d'OTel réside dans le découplage entre l'instrumentation et le choix du backend. Un code applicatif instrumenté avec les SDK OTel peut envoyer des données de télémétrie vers Prometheus, Grafana Cloud, Datadog ou tout autre backend compatible, sans modification de code. Cette flexibilité constitue un argument de poids dans les entretiens de system design, en particulier lorsqu'il est question de stratégie d'observabilité à long terme.

Questions d'entretien sur l'observabilité qui comparent les trois outils

Au-delà de Prometheus lui-même, ces questions vérifient la capacité du candidat à raisonner d'un outil à l'autre. Chaque réponse met en évidence le concept que le recruteur cherche à évaluer.

Q : Quelle est la différence entre monitoring, observabilité et alerting ?

Le monitoring suit des métriques prédéfinies et vérifie des modes de défaillance connus. L'observabilité permet d'investiguer des modes de défaillance inconnus à travers les métriques, les logs et les traces, les fameux « trois piliers ». L'alerting déclenche des notifications lorsque des conditions franchissent des seuils définis ou des baselines d'anomalie. Le monitoring répond à la question « le système est-il en bonne santé ? », tandis que l'observabilité répond à la question « pourquoi le système n'est-il pas en bonne santé ? ».

Q : Dans quels scénarios Prometheus est-il un mauvais choix ?

Prometheus est optimisé pour la fiabilité plutôt que pour la durabilité : la disponibilité du système de monitoring lui-même est prioritaire. Les scénarios où Prometheus atteint ses limites : le stockage à long terme au-delà de 30 jours (nécessite Thanos, Mimir ou Cortex), les données de facturation par requête exigeant une précision de 100 % (une collecte par scrape peut manquer des échantillons) et les systèmes événementiels qui requièrent une collecte push-based (le Pushgateway existe, mais uniquement pour les jobs batch au niveau du service).

Q : Comment la philosophie « Big Tent » de Grafana influence-t-elle l'architecture d'observabilité ?

Grafana se connecte à n'importe quelle source de données sans exiger de migration des données. Les équipes peuvent réunir Prometheus, Elasticsearch, CloudWatch et Datadog dans un dashboard unique. Le compromis réside dans la complexité opérationnelle : maintenir plusieurs backends demande davantage d'expertise infrastructure qu'une approche single-vendor. Les recruteurs vérifient si les candidats savent formuler clairement ce trade-off.

Q : Qu'est-ce que la facturation high-watermark de Datadog, et pourquoi compte-t-elle ?

Datadog mesure le nombre d'hôtes chaque heure, écarte le 1 % supérieur des heures et facture sur le pic au 99e percentile. Des pics d'auto-scaling temporaires, par exemple pendant le trafic du Black Friday, gonflent donc la facture mensuelle même une fois les instances terminées. Un candidat qui mentionne ce point démontre une expérience opérationnelle réelle de la gestion des coûts, de plus en plus attendue sur les postes SRE.

Q : Comment l'alerting basé sur les SLO diffère-t-il entre Prometheus et Datadog ?

Dans Prometheus, l'alerting basé sur les SLO utilise des recording rules pour précalculer les error budgets et les burn-rate alerts, selon l'approche multi-window, multi-burn-rate du SRE Workbook de Google. Datadog propose des widgets SLO et des monitors intégrés qui suivent automatiquement le burn rate. Les deux approches implémentent le même concept, mais Prometheus exige davantage de configuration manuelle, tandis que Datadog fournit un workflow managé. Dans une bonne réponse d'entretien, les fenêtres de burn rate (1h, 6h, 3j) et les taux de consommation de l'error budget devraient être explicitement nommés.

Framework de décision : choisir la bonne stack

Le bon choix dépend de trois variables : la taille de l'équipe, la maturité opérationnelle et les contraintes budgétaires. Il n'existe pas de réponse universellement correcte. Les recruteurs attendent des candidats qu'ils raisonnent systématiquement sur les trade-offs, plutôt que de proclamer un unique gagnant.

Sources

• Releases de Prometheus : la 3.15.0 (septembre 2026) stabilise l'encodage de chunks XOR2, ajoute le scrape OpenMetrics 2.0 et déprécie --log.level
• Spécification des histogrammes natifs de Prometheus : stables depuis la 3.8, scrape_native_histograms obligatoire depuis la 3.9
• Nouveautés de Grafana 13.0 : Git Sync en GA, dashboards dynamiques par défaut, breaking changes
• Prix catalogue Datadog : prix infrastructure, APM et logs utilisés dans le tableau des coûts
• Fonctions algorithmiques Datadog : syntaxe de anomalies() et forecast()

Ce qu'il faut retenir pour un entretien Prometheus ou observabilité

• Prometheus est le standard de la collecte de métriques dans les environnements Kubernetes ; pull vs push, les quatre types de métriques, rate() vs irate(), la cardinalité et la HA doivent être maîtrisés sur le bout des doigts
• Sur Prometheus 3.9 et plus récent, les histogrammes natifs ne sont ingérés que si scrape_native_histograms: true est défini
• Grafana est une couche de visualisation et non une base de données de métriques : il se connecte à plus de 100 sources de données dont Prometheus, et la stack LGTM (Loki, Grafana, Tempo, Mimir) forme une plateforme d'observabilité open-source complète
• Datadog offre la voie la plus rapide vers une observabilité full-stack avec détection d'anomalies intégrée, au prix de coûts plus élevés et d'un vendor lock-in plus marqué
• OpenTelemetry rend le choix du backend moins définitif : l'instrumentation reste la même quel que soit l'outil qui stocke et interroge les données
• En entretien, il s'agit de démontrer la capacité à peser les trade-offs (coût, contrôle, complexité) plutôt que de défendre un outil unique
• Pour une préparation plus large, le guide des questions d'entretien DevOps essentielles couvre les sujets voisins que les recruteurs enchaînent après le monitoring