Prometheus vs Grafana vs Datadog nel 2026: Confronto Monitoring e Domande Colloquio DevOps

Il confronto tra Prometheus, Grafana e Datadog costituisce uno dei temi centrali nei colloqui DevOps del 2026. Saper illustrare le differenze architetturali, i compromessi operativi e i modelli di costo di ciascuno strumento comunica ai responsabili delle assunzioni un'esperienza maturata sul campo, ben oltre la semplice preparazione teorica. Con la diffusione capillare di Kubernetes e il consolidamento di OpenTelemetry come standard per l'instrumentazione, la scelta dello stack di monitoring incide direttamente sull'affidabilita dei sistemi, sulla rapidita di risoluzione degli incidenti e sul budget operativo.

Questo articolo esamina ciascun componente dal punto di vista tecnico e strategico, fornendo esempi di configurazione e le risposte strutturate necessarie per affrontare le domande su monitoring e observability nei colloqui per ruoli DevOps, SRE e Platform Engineering.

Architettura e modello dati: come ciascuno strumento gestisce le metriche

Le differenze architetturali tra Prometheus, Grafana e Datadog sono sostanziali. Gli intervistatori le utilizzano come cartina di tornasole per valutare la profondita di comprensione del candidato in materia di raccolta e gestione delle metriche.

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. Con Prometheus 3.0 (rilasciato a novembre 2024), gli istogrammi nativi hanno raggiunto la stabilita nella versione 3.8, l'ingestione OTLP nativa elimina la necessita di un Collector come intermediario, e Remote Write 2.0 migliora sensibilmente la federazione tra cluster.

Grafana non raccoglie ne archivia metriche in modo autonomo. Si connette a data source esterni -- 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 formano lo stack di observability open-source LGTM. La versione 13, rilasciata a maggio 2026, introduce strumenti di observability-as-code, Git Sync per le dashboard e SQL Expressions per query cross-source.

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 di machine learning Watchdog esegue il rilevamento automatico delle 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'
    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}

Questa configurazione YAML esemplifica il modello pull di Prometheus: il server scopre automaticamente i pod Kubernetes tramite service discovery e interroga i loro endpoint /metrics ogni 15 secondi. Le direttive relabel_configs filtrano i pod sulla base di annotation specifiche, garantendo un controllo granulare su quali servizi vengono monitorati senza necessita di modificare il codice applicativo.

PromQL vs Datadog Query Language: sintassi e capacita 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 capacita.

PromQL (Prometheus Query Language) e 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

La funzione rate() calcola la velocita di variazione per secondo su un intervallo, ed e fondamentale per le metriche di tipo counter. histogram_quantile() estrae percentili dagli istogrammi nativi, mentre predict_linear() applica la regressione lineare per effettuare previsioni temporali, ad esempio per anticipare l'esaurimento dello spazio disco entro un orizzonte definito.

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 (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 garantisce maggiore espressivita per l'analisi ad-hoc e la composizione di query articolate. Il linguaggio Datadog sacrifica una parte di questa flessibilita in favore di funzioni ML integrate come anomaly() e forecast(), che nell'ecosistema Prometheus richiederebbero strumenti aggiuntivi o recording rules personalizzate. In sede di colloquio, saper evidenziare questo compromesso tra potenza espressiva e funzionalita out-of-the-box dimostra maturita nella valutazione degli strumenti.

Strategie di alerting: regole deterministiche vs rilevamento basato su ML

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

Prometheus Alertmanager valuta le regole a intervalli fissi e instrada gli alert 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 PromQL verificabile, versionabile in Git e soggetta a code review. Lo svantaggio si manifesta nella cosiddetta "threshold fatigue": i valori statici necessitano spesso di aggiustamenti stagionali o legati a variazioni del pattern di carico.

Grafana Alerting (unificato a partire dalla versione 12) valuta query attraverso qualsiasi data source connessa e supporta alert multi-dimensionali con policy di notifica flessibili. La possibilita di definire alert su metriche provenienti da backend differenti (Prometheus, Loki, CloudWatch) in un'unica interfaccia semplifica la gestione operativa rispetto a configurazioni separate.

Datadog Monitors combinano soglie statiche con monitor basati su ML 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. In sede di colloquio, saper articolare questo compromesso dimostra capacita di valutazione critica degli strumenti.

Pricing e costo totale di possesso nel 2026

Il modello di pricing e 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, una qualita valorizzata nei ruoli senior.

| Dimensione | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Licenza | Gratuita (AGPL / Apache 2.0) | $15-31/host/mese (annuale) | | Storage metriche | Self-managed (Mimir/Thanos) | Incluso, pricing basato su retention | | Gestione log | Loki (self-hosted) | $0.10/GB ingeriti + indicizzazione | | APM / Tracce | Tempo (self-hosted) | $31/host/mese | | Costo infrastruttura | Compute + storage per lo stack | Nessuno (SaaS) | | Overhead operativo | Elevato (upgrade, scaling, HA) | Minimo | | Costo annuale tipico (50 host) | $20K-60K (infra + engineering) | $50K-150K | | Rischio vendor lock-in | Basso (OpenTelemetry, PromQL) | Elevato (linguaggio proprietario) |

Lo stack open-source appare meno oneroso sulla carta, ma richiede tempo engineering dedicato per aggiornamenti, capacity planning e configurazione dell'alta disponibilita. Il modello gestito di Datadog trasferisce questo onere al vendor. Per team con meno di 5 ingegneri dedicati all'infrastruttura, le soluzioni gestite presentano frequentemente un costo totale inferiore quando si contabilizza il tempo engineering. In un colloquio, ragionare su questo compromesso piuttosto che dichiarare una scelta universalmente corretta rappresenta un segnale di maturita professionale.

Monitoring Kubernetes: profondita di integrazione a confronto

Oltre l'80% dei cluster Kubernetes utilizza Prometheus per la raccolta metriche. Questo dato rende il tema dominante nelle domande colloquio DevOps relative al monitoring di 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 coerente:

# 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, integrandosi con i paradigmi GitOps per la gestione dell'infrastruttura come codice.

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 visibilita in tempo reale sugli stati dei pod, mentre l'Orchestrator Explorer visualizza le relazioni tra deployment, service e pod in modo grafico.

Per i team gia profondamente inseriti nell'ecosistema Kubernetes, l'approccio nativo con Prometheus evita l'introduzione di dipendenze esterne. I team che privilegiano la rapidita di setup con un investimento operativo contenuto tendono verso Datadog. La scelta va sempre contestualizzata in base alle competenze disponibili e alla strategia infrastrutturale complessiva dell'organizzazione.

OpenTelemetry e neutralita verso il vendor

OpenTelemetry (OTel) si e 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.0+ accetta metriche OTLP nativamente, senza necessita di interporre un Collector. Grafana Alloy (successore di Grafana Agent) funge contemporaneamente da OTel Collector e da Prometheus scraper, unificando i due paradigmi di raccolta dati. Datadog supporta l'ingestione OTLP ma raccomanda l'uso dei propri agenti proprietari per garantire "l'accesso completo alle funzionalita", generando un soft lock-in che limita la portabilita futura.

L'adozione di OTel riveste importanza strategica perche disaccoppia l'instrumentazione dalla scelta del backend. Il codice applicativo instrumentato con gli SDK OTel puo inviare telemetria a Prometheus, Grafana Cloud, Datadog o qualsiasi backend compatibile senza modifiche al codice sorgente. Questa flessibilita costituisce un argomento di forte impatto nelle discussioni di system design, quando si affronta la definizione di una strategia di observability sostenibile nel lungo periodo.

Domande colloquio DevOps su monitoring e observability

Le seguenti domande compaiono con regolarita nei colloqui per ruoli DevOps e SRE. Ogni risposta mette in evidenza i concetti che gli intervistatori intendono verificare.

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

Il monitoring traccia metriche predefinite e verifica modalita di guasto conosciute. L'observability consente l'investigazione di modalita 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 "perche il sistema non funziona?".

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

Prometheus privilegia l'affidabilita rispetto alla durabilita: la priorita e garantire la disponibilita 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% (Prometheus puo perdere campioni sotto carico elevato), e sistemi event-based che necessitano di raccolta push-based (il pushgateway esiste come soluzione parziale ma con le proprie limitazioni).

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 complessita 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 e contestualizzato.

D: Come funziona la fatturazione high-watermark di Datadog e perche e 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 generati durante il Black Friday o eventi promozionali) gonfiano la fattura mensile anche dopo la terminazione delle istanze. Menzionare questo meccanismo dimostra esperienza operativa concreta nella gestione dei costi, una competenza sempre piu richiesta nei ruoli SRE e Platform Engineering.

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 libro 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 piu articolata, mentre Datadog fornisce un workflow gestito con minor flessibilita. I candidati dovrebbero citare le finestre di burn rate (1h, 6h, 3d) e i tassi di consumo dell'error budget nelle loro risposte.

Per una preparazione strutturata sulle tematiche di monitoring, il modulo domande colloquio su Prometheus e monitoring copre scenari aggiuntivi con spiegazioni dettagliate.

Framework decisionale: scegliere lo stack appropriato

| Scenario | Stack consigliato | Motivazione | |----------|------------------|-------------| | Startup con meno di 10 ingegneri | Datadog o Grafana Cloud | Minimizzare l'overhead operativo | | Grande organizzazione con platform team | Prometheus + Grafana + Loki | Controllo completo, costo unitario inferiore su larga scala | | Multi-cloud / ambienti ibridi | Prometheus + Grafana | Vendor-neutral, coerente tra ambienti diversi | | Compliance stringente (finanza, sanita) | Prometheus + Grafana self-hosted | I dati rimangono nel perimetro aziendale | | Scaling rapido e crescita imprevedibile | Grafana Cloud (Mimir gestito) | Scala senza gestione infrastrutturale diretta | | Necessita di anomaly detection ML-driven | Datadog | Watchdog opera senza configurazione manuale |

La scelta corretta dipende da tre variabili: dimensione del team, maturita operativa e vincoli di budget. Non esiste una risposta universalmente valida. Gli intervistatori si aspettano che il candidato ragioni attraverso i trade-off piuttosto che indicare un vincitore assoluto. Dimostrare la capacita di adattare la raccomandazione al contesto specifico rappresenta un segnale di seniority apprezzato.

Conclusione

• Prometheus rappresenta lo standard de facto per la raccolta metriche in ambienti Kubernetes; la versione 3.x introduce supporto OTLP nativo e istogrammi nativi stabili nel 2026
• Grafana opera come layer di visualizzazione, non come database metriche: si connette a oltre 100 data source, e lo stack LGTM (Loki, Grafana, Tempo, Mimir) costituisce una piattaforma di observability open-source completa
• Datadog offre il percorso piu rapido verso l'observability full-stack con alerting potenziato dal machine learning, al costo di un pricing superiore e un rischio di vendor lock-in piu elevato
• L'adozione di OpenTelemetry rende la scelta del backend meno vincolante nel lungo periodo: l'instrumentazione rimane identica indipendentemente dallo strumento che archivia e interroga i dati
• Nei colloqui, dimostrare la capacita di ragionare sui trade-off (costi, controllo, complessita) risulta piu efficace rispetto a sostenere la superiorita di un singolo strumento
• Per una preparazione approfondita, il modulo domande colloquio DevOps e i concetti pipeline CI/CD rafforzano le competenze su aree complementari al monitoring