Domande di colloquio su Prometheus 2026: Prometheus vs Grafana vs Datadog a confronto

Le domande su Prometheus ricorrono in quasi tutti i colloqui DevOps e SRE, di solito seguite da "perché non Grafana o Datadog?". Il candidato deve spiegare come Prometheus raccoglie e archivia le metriche, scrivere PromQL corretto e argomentare i compromessi rispetto a una piattaforma gestita. Gli intervistatori usano questo tema per distinguere l'esperienza operativa reale dalla conoscenza da manuale. Il modulo di colloquio su Prometheus e monitoring propone gli stessi argomenti sotto forma di domande di esercitazione.

Domande su Prometheus nei colloqui DevOps e SRE

Queste sono le domande specifiche su Prometheus che compaiono più spesso, con la risposta che dà un candidato sicuro di sé. Presuppongono Prometheus 3.x: la linea stabile corrente è la 3.15 (settembre 2026), con la 3.16 in release candidate.

D: Perché Prometheus preleva le metriche invece di riceverle in push?

Il pull rende osservabile lo stato dei target: ogni scrape produce una serie up, quindi un target fermo appare come up == 0 invece che come silenzio. È il server a controllare la frequenza di scrape, il che lo protegge da un client che si comporta male, e un target si può verificare a mano aprendo il suo endpoint /metrics nel browser. Il costo è che Prometheus deve raggiungere ogni target via rete: per questo i job batch di breve durata richiedono il Pushgateway e le configurazioni tra reti diverse usano il remote write.

D: Quali sono i quattro tipi di metrica, e quando un summary è la scelta sbagliata?

Counter (cresce soltanto, si azzera al riavvio), gauge (sale e scende), histogram (osservazioni contate in bucket) e summary (quantili calcolati nel client). I quantili di un summary non sono aggregabili: la media del p99 di dieci pod non dà il p99 del servizio. Gli histogram si possono prima sommare tra istanze e poi trasformare in quantile lato server, ed è per questo che sono la scelta predefinita per la latenza.

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

Dimenticare le nella clausola by della forma classica è l'errore PromQL più comune nei round di live coding: la query non restituisce nulla di utilizzabile.

D: Qual è la differenza tra rate(), irate() e increase()?

rate() restituisce la media al secondo sull'intero intervallo e gestisce gli azzeramenti dei counter. irate() usa solo gli ultimi due campioni dell'intervallo: reagisce in fretta ma è rumorosa, quindi va bene per un grafico ingrandito ed è sbagliata per l'alerting. increase() è rate() moltiplicata per la durata dell'intervallo. Poiché Prometheus estrapola fino ai bordi della finestra, increase() su un counter intero può restituire un valore non intero, e agli intervistatori piace chiederne il motivo.

D: Che cos'è la cardinalità, e come si diagnostica un'esplosione di cardinalità?

Ogni combinazione unica di nome metrica e valori delle label è una serie temporale separata tenuta in memoria. Una label come user_id, email o un path URL grezzo contenente ID moltiplica il numero di serie finché il server esaurisce la memoria. La diagnosi parte dalla pagina di stato del TSDB (/tsdb-status) o da una query:

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

La correzione va fatta alla fonte: eliminare o riscrivere la label con metric_relabel_configs, oppure impostare sample_limit sul job di scrape, così che un singolo deployment difettoso non possa mettere fuori uso il server.

D: A cosa servono le recording rules?

Precalcolano un'espressione costosa a ogni intervallo di valutazione e ne salvano il risultato come nuova serie. Dashboard e alert interrogano poi la serie precalcolata, che costa poco. La convenzione di nomenclatura è level:metric:operations:

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

D: Cosa fa la clausola for in una regola di alerting?

Un alert la cui espressione diventa vera passa da inactive a pending, e raggiunge firing solo quando la condizione è rimasta vera per la durata indicata in for. Questo filtra i picchi di un singolo scrape. keep_firing_for fa l'opposto: mantiene l'alert attivo per un certo tempo dopo che la condizione è rientrata, il che evita che un alert instabile mandi due pagine.

D: Come si rende Prometheus altamente disponibile?

Si eseguono due repliche identiche che fanno scrape degli stessi target, ciascuna con una external label replica distinta. Entrambe inviano gli alert a un cluster Alertmanager, che deduplica le notifiche tramite il suo protocollo gossip. Per le query, Thanos Query o Mimir deduplicano le due serie ignorando la label della replica. Prometheus non ha clustering: il TSDB locale di un singolo server non viene replicato.

D: Federation o remote write per le configurazioni multi-cluster?

La federation permette a un Prometheus globale di fare scrape di serie selezionate, di solito aggregate, dall'endpoint /federate del Prometheus di ogni cluster. Si adatta a un piccolo insieme di aggregazioni. Il remote write invia in streaming ogni campione a uno storage centrale come Mimir, Thanos Receive o un backend di un vendor, ed è la risposta standard per le query globali e la retention a lungo termine.

D: Come si rileva un target scomparso dalla service discovery?

up == 0 scatta solo finché il target è ancora scoperto. Se il pod o la voce di service discovery non esiste più, la serie smette di esistere e l'alert non scatta mai. absent(up{job="api-server"}) copre questo caso.

D: Cosa è cambiato in Prometheus 3?

Prometheus 3.0 (novembre 2024) ha introdotto una nuova UI, ha ammesso caratteri UTF-8 nei nomi di metriche e label e ha aggiunto un receiver OTLP integrato su /api/v1/otlp/v1/metrics, attivato con --web.enable-otlp-receiver. Gli istogrammi nativi sono diventati stabili nella 3.8. Dalla 3.9 il vecchio feature flag non ha più effetto e l'ingestione richiede scrape_native_histograms: true nella configurazione di scrape o globale. La 3.15 ha reso stabile la codifica dei chunk float XOR2 e ha aggiunto lo scraping OpenMetrics 2.0.

Architettura e modello dati: come ciascuno strumento gestisce le metriche

Una volta coperti i fondamenti di Prometheus, gli intervistatori passano di solito alle differenze architetturali tra i tre strumenti.

Prometheus si basa su un modello pull-based. Il server interroga endpoint HTTP (tipicamente /metrics) a intervalli configurati, archiviando le serie temporali in un database TSDB locale ottimizzato per dati temporali. Ogni serie temporale viene identificata univocamente da un nome metrica e un insieme di label chiave-valore. La linea 3.x aggiunge istogrammi nativi stabili, un receiver OTLP e Remote Write 2.0 per inviare i campioni a uno storage centrale.

Grafana non raccoglie né archivia metriche in modo autonomo. Si connette a data source esterni, come Prometheus, Loki, Tempo, InfluxDB, Elasticsearch e oltre 100 altri, per costruire dashboard dai dati disponibili. Grafana Labs mantiene inoltre Mimir (storage metriche a lungo termine), Loki (aggregazione log) e Tempo (tracing distribuito), componenti che insieme a Grafana formano lo stack di observability open-source LGTM. Grafana 13, annunciato alla GrafanaCON di aprile 2026, ha reso generalmente disponibile Git Sync per le dashboard, ha attivato di default le dashboard dinamiche e ha rimosso i comandi grafana-cli e grafana-server.

Datadog opera come piattaforma SaaS push-based. Gli agenti installati sugli host inviano metriche, log e tracce al backend cloud proprietario. Ingestione, archiviazione, querying, alerting e dashboard risiedono all'interno di un'unica piattaforma gestita. Il motore Watchdog segnala automaticamente le anomalie senza che sia necessaria la configurazione manuale delle soglie.

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

Questa configurazione YAML esemplifica il modello pull di Prometheus: il server scopre i pod Kubernetes tramite service discovery, mantiene solo quelli con l'annotation prometheus.io/scrape: "true", riscrive l'indirizzo sulla porta indicata nell'annotation e interroga /metrics ogni 15 secondi. La seconda regola unisce le due label sorgente con ;, ed è per questo che la regex corrisponde a host:port;port.

PromQL vs Datadog Query Language: sintassi e capacità espressive

I linguaggi di query rappresentano un argomento ricorrente nei colloqui tecnici. Il candidato deve dimostrare padronanza operativa di almeno uno dei due e saper articolare i compromessi tra le diverse sintassi e le rispettive capacità.

PromQL (Prometheus Query Language) è lo standard consolidato per le query metriche nell'ecosistema Prometheus e Grafana. Supporta vettori istantanei, vettori di intervallo (range vectors), operatori di aggregazione e recording rules per la pre-computazione di espressioni complesse.

# 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

Il linguaggio di query Datadog adotta una sintassi differente, costruita su funzioni e 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 garantisce maggiore espressività per l'analisi ad-hoc. Il linguaggio Datadog sacrifica una parte di questa flessibilità in favore di funzioni algoritmiche integrate come anomalies() (algoritmi basic, agile, robust) e forecast() (linear, seasonal), che in uno stack Prometheus richiederebbero strumenti esterni.

Strategie di alerting: regole deterministiche vs rilevamento automatico delle anomalie

La filosofia di alerting diverge in modo sostanziale tra gli strumenti esaminati. Comprendere e saper comunicare queste differenze costituisce un indicatore di maturità operativa apprezzato dagli intervistatori.

Prometheus Alertmanager riceve gli alert generati dalle regole che Prometheus valuta a intervalli fissi e li instrada attraverso una pipeline configurabile che supporta raggruppamento, silenziamento e inibizione:

# 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

Questo approccio richiede la definizione esplicita delle soglie da parte degli operatori. Il vantaggio principale risiede nella trasparenza completa: ogni alert corrisponde a un'espressione verificabile. Lo svantaggio si manifesta nella cosiddetta "threshold fatigue": i valori statici necessitano spesso di aggiustamenti stagionali.

Grafana Alerting (il sistema di alerting unificato, predefinito da Grafana 9) valuta query attraverso qualsiasi data source connessa e supporta alert multi-dimensionali con policy di notifica.

Datadog Monitors combinano soglie statiche con monitor per anomalie, outlier e previsioni. Watchdog segnala automaticamente anomalie di performance senza creazione manuale di regole. Questo riduce il carico di configurazione al costo di una minore trasparenza nella logica di rilevamento.

Pricing e costo totale di possesso nel 2026

Il modello di pricing è un fattore determinante nella scelta reale degli strumenti di monitoring e compare frequentemente nelle discussioni di system design. Dimostrare consapevolezza dei costi segnala attenzione alle esigenze di business. I valori Datadog riportati sotto sono prezzi di listino con fatturazione annuale.

Lo stack open-source appare meno oneroso sulla carta, ma richiede tempo engineering dedicato per aggiornamenti, capacity planning e configurazione dell'alta disponibilità. Il modello gestito di Datadog trasferisce questo onere al vendor. Per team con meno di 5 ingegneri dedicati all'infrastruttura, le soluzioni gestite presentano spesso un costo totale inferiore quando si contabilizza il tempo engineering.

Monitoring Kubernetes: profondità di integrazione a confronto

Prometheus è il sistema di metriche predefinito dell'ecosistema Kubernetes, il che rende questo tema dominante nei colloqui sul monitoring degli ambienti containerizzati.

Prometheus + Grafana si integra nativamente con Kubernetes attraverso il chart Helm kube-prometheus-stack, che distribuisce Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics e dashboard Grafana pre-configurate in un'unica installazione:

# 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

Questo comando distribuisce uno stack di monitoring production-grade con storage persistente e retention di 30 giorni. Il Prometheus Operator utilizza Custom Resource Definitions (ServiceMonitor, PodMonitor) per configurare in modo dichiarativo i target di scraping. La personalizzazione dei valori di un chart in questo modo è trattata più a fondo nella guida ai colloqui sugli Helm chart.

Datadog distribuisce un agent DaemonSet e un Cluster Agent. Quest'ultimo gestisce centralmente la comunicazione con l'API server di Kubernetes, riducendo il carico sulle API del cluster. La vista Live Containers offre visibilità in tempo reale sugli stati dei pod, mentre l'Orchestrator Explorer mappa le relazioni tra deployment, service e pod.

Per i team già inseriti nell'ecosistema Kubernetes, l'approccio nativo con Prometheus evita l'introduzione di una dipendenza esterna. I team che privilegiano la rapidità di setup con un investimento operativo contenuto tendono verso Datadog.

OpenTelemetry e neutralità verso il vendor

OpenTelemetry (OTel) si è consolidato come standard industriale per l'instrumentazione del software. Gli intervistatori pongono domande su questo framework con frequenza crescente, spesso in connessione con il confronto tra strumenti di monitoring.

Prometheus 3.x accetta direttamente metriche OTLP una volta impostato --web.enable-otlp-receiver, quindi non è più necessario interporre un Collector. Grafana Alloy (successore di Grafana Agent) funge contemporaneamente da OTel Collector e da Prometheus scraper. Datadog supporta l'ingestione OTLP ma raccomanda l'uso dei propri agenti proprietari per garantire "l'accesso completo alle funzionalità", generando un soft lock-in.

L'adozione di OTel conta perché disaccoppia l'instrumentazione dalla scelta del backend. Il codice applicativo instrumentato con gli SDK OTel può inviare telemetria a Prometheus, Grafana Cloud, Datadog o qualsiasi backend compatibile senza modifiche al codice. Questa flessibilità costituisce un argomento di forte impatto nelle discussioni di system design, quando si affronta la strategia di observability nel lungo periodo.

Domande di colloquio sull'observability che confrontano i tre strumenti

Oltre a Prometheus in sé, queste domande verificano se il candidato sa ragionare tra strumenti diversi. Ogni risposta mette in evidenza il concetto che l'intervistatore intende verificare.

D: Qual è la differenza tra monitoring, observability e alerting?

Il monitoring traccia metriche predefinite e verifica modalità di guasto conosciute. L'observability consente l'investigazione di modalità di guasto sconosciute attraverso metriche, log e tracce (i cosiddetti "tre pilastri"). L'alerting attiva notifiche quando le condizioni superano soglie definite o baseline di anomalia. In sintesi, il monitoring risponde alla domanda "il sistema funziona?", l'observability risponde a "perché il sistema non funziona?".

D: In quali scenari Prometheus non rappresenta la scelta ottimale?

Prometheus privilegia l'affidabilità rispetto alla durabilità: la priorità è garantire la disponibilità del sistema di monitoring stesso. Le situazioni in cui Prometheus mostra limitazioni comprendono: storage a lungo termine oltre i 30 giorni (dove servono Thanos, Mimir o Cortex), dati di fatturazione per-request che richiedono accuratezza al 100% (la raccolta basata su scrape può perdere campioni) e sistemi event-based che necessitano di raccolta push-based (il Pushgateway esiste, ma solo per i job batch a livello di servizio).

D: Come la filosofia "Big Tent" di Grafana influenza l'architettura di observability?

Grafana si connette a qualsiasi data source senza richiedere la migrazione dei dati. I team possono interrogare Prometheus, Elasticsearch, CloudWatch e Datadog da un'unica dashboard. Il compromesso si manifesta nella complessità operativa: la manutenzione di backend multipli richiede competenze infrastrutturali superiori rispetto a un approccio single-vendor. Gli intervistatori valutano se il candidato sa articolare questo trade-off in modo chiaro.

D: Come funziona la fatturazione high-watermark di Datadog e perché è rilevante?

Datadog misura il conteggio degli host su base oraria, scarta l'1% superiore delle ore e fattura al picco del 99esimo percentile. Di conseguenza, picchi temporanei di auto-scaling (come quelli del Black Friday) gonfiano la fattura mensile anche dopo la terminazione delle istanze. Menzionare questo meccanismo dimostra esperienza operativa concreta nella gestione dei costi, una competenza sempre più richiesta nei ruoli SRE.

D: Come si differenzia una strategia di alerting basata su SLO tra Prometheus e Datadog?

In Prometheus, l'alerting basato su SLO utilizza recording rules per pre-computare error budget e alert di burn rate secondo l'approccio multi-window, multi-burn-rate descritto nel workbook SRE di Google. Datadog offre widget SLO e monitor integrati che tracciano il burn rate automaticamente. Entrambi gli approcci implementano lo stesso concetto, ma Prometheus richiede una configurazione manuale più articolata, mentre Datadog fornisce un workflow gestito. I candidati dovrebbero citare le finestre di burn rate (1h, 6h, 3d) e i tassi di consumo dell'error budget nelle loro risposte.

Framework decisionale: scegliere lo stack appropriato

La scelta corretta dipende da tre variabili: dimensione del team, maturità operativa e vincoli di budget. Non esiste una risposta universalmente valida, e gli intervistatori si aspettano che il candidato ragioni attraverso i trade-off piuttosto che indicare un vincitore.

Fonti

• Release di Prometheus: la 3.15.0 (settembre 2026) stabilizza la codifica dei chunk XOR2, aggiunge lo scraping OpenMetrics 2.0 e depreca --log.level
• Specifica degli istogrammi nativi di Prometheus: stabili dalla 3.8, scrape_native_histograms obbligatorio dalla 3.9
• Novità di Grafana 13.0: Git Sync GA, dashboard dinamiche di default, breaking change
• Listino prezzi Datadog: prezzi di infrastructure, APM e log usati nella tabella dei costi
• Funzioni algoritmiche di Datadog: sintassi di anomalies() e forecast()

Cosa ricordare per un colloquio su Prometheus o sull'observability

• Prometheus è lo standard per la raccolta metriche negli ambienti Kubernetes; pull vs push, i quattro tipi di metrica, rate() vs irate(), cardinalità e HA vanno conosciuti a memoria
• Da Prometheus 3.9 in poi, gli istogrammi nativi vengono ingeriti solo se è impostato scrape_native_histograms: true
• Grafana opera come layer di visualizzazione, non come database metriche: si connette a oltre 100 data source, tra cui Prometheus, e lo stack LGTM (Loki, Grafana, Tempo, Mimir) costituisce una piattaforma di observability open-source completa
• Datadog offre il percorso più rapido verso l'observability full-stack con rilevamento delle anomalie integrato, al costo di un pricing superiore e del vendor lock-in
• L'adozione di OpenTelemetry rende la scelta del backend meno vincolante: l'instrumentazione rimane identica indipendentemente dallo strumento che archivia e interroga i dati
• Nei colloqui, dimostrare la capacità di ragionare sui trade-off (costi, controllo, complessità) risulta più efficace che sostenere un singolo strumento
• Per una preparazione più ampia, la guida alle domande essenziali per colloqui DevOps copre gli argomenti adiacenti che gli intervistatori collegano al monitoring