In sintesi: la fatturazione per host e per GB di Datadog penalizza l'infrastruttura dinamica ed effimera tipica del CloudOps Kubernetes-native. Se i costi di observability crescono più rapidamente dell'infrastruttura, il problema non è la piattaforma che sta pagando: è l'architettura sottostante. Questa guida analizza cinque alternative da valutare nel 2026 — DoiT, SigNoz, Grafana, New Relic e Dynatrace — insieme alle funzionalità più rilevanti per i team CloudOps e alle modalità di migrazione senza interruzioni operative.
La sua bolletta Datadog non è cresciuta perché il team ha aggiunto altri host. È cresciuta perché Kubernetes ha fatto esattamente ciò per cui è stato progettato.
Ogni scale-out di pod, ogni container effimero, ogni nuova dimensione di tag aggiunta dalla pipeline OpenTelemetry: questi eventi moltiplicano la superficie di fatturazione di Datadog in modi che hanno poco a che vedere con la reale complessità delle operazioni. La fatturazione delle custom metrics di Datadog si basa sulla cardinalità: il numero di combinazioni uniche tra il nome di una metrica e i tag associati. Aggiungere un singolo tag con molti valori unici — un pattern comune nell'instrumentation OpenTelemetry — può far esplodere le serie temporali fatturabili, arrivando a rappresentare oltre la metà della spesa Datadog complessiva di un team su larga scala.
È questo il nodo strutturale che alimenta gran parte del dibattito sulle alternative a Datadog nel 2026. Non si tratta di un'observability mediocre da parte di Datadog. Il punto è che la maggior parte delle "alternative a Datadog" è modellata su Datadog: stesso modello di agent per linguaggio, stesso data plane esclusivamente SaaS, stessa matrice di fatturazione per GB, a un prezzo leggermente diverso. Passare dall'una all'altra risolve la bolletta per un anno e ripropone la stessa struttura di costo poco dopo.
Le alternative che cambiano davvero l'equazione affrontano l'observability con un'architettura diversa, un modello di pricing diverso o — nel caso di DoiT — un rapporto completamente diverso con il problema.
Le 5 migliori alternative a Datadog per team CloudOps
Prima di entrare nel merito dei singoli strumenti, vale la pena chiarire cosa significhi "migliore" nello specifico contesto CloudOps. Le classifiche generaliste sull'observability privilegiano l'ampiezza delle integrazioni, la cura dell'UI e la profondità dell'APM. I team CloudOps hanno bisogno di qualcosa di più specifico: una visibilità Kubernetes-native che non penalizzi l'autoscaling, una compatibilità OpenTelemetry che non costringa a re-instrumentare, workflow SLO collegati alla gestione degli incident e un modello di costo che resti prevedibile anche durante i picchi di traffico.
Con questi criteri in mente, ecco come si confrontano le principali alternative.
DoiT
DoiT adotta una posizione radicalmente diversa in questo dibattito. Anziché sostituire Datadog, il modulo Datadog Intelligence di DoiT mappa i volumi di telemetria, la cardinalità delle metriche e i pattern di retention dei log per individuare sprechi, ottimizzare i workloads di observability e attivare la pulizia automatizzata delle metriche non più interrogate. Per i team CloudOps che utilizzano Datadog su larga scala, questa impostazione fa la differenza: non sempre serve migrare per risolvere il problema dei costi.
DoiT Cloud Intelligence si collega all'organizzazione Datadog tramite accesso API in sola lettura e mostra la spesa per prodotto (APM, Logs, Infrastructure), team, ambiente e tag — accanto ai costi dell'infrastruttura cloud, in una vista unificata. Sono inclusi i costi della piattaforma suddivisi per ambiente, i costi per host su cui è installato un agent Datadog, i trend di popolarità dei dashboard per identificare asset inutilizzati e un'anomaly detection che evidenzia pattern di utilizzo anomali prima che impattino sulla bolletta.
La differenza rispetto agli strumenti tradizionali di observability emerge in ciò che accade dopo aver fatto emergere un insight. DoiT Cloud Intelligence rivela sprechi nascosti — Spark job sbilanciati, query non indicizzate, inferenze GPU quasi inattive — e abbina quell'analisi a un team di Forward Deployed Engineers che implementa correzioni concrete, anziché lasciare le raccomandazioni ferme su un dashboard. Per i team che stanno valutando se una migrazione sia davvero necessaria, questa combinazione di insight automatizzati e supporto ingegneristico ridisegna i conti.
Funzionalità principali:
- Visibilità unificata dei costi tra Datadog e infrastruttura cloud in un'unica vista
- Analisi della cardinalità e della retention dei log con raccomandazioni automatizzate per ridurre lo spreco di ingestion
- Allocazione showback e chargeback per team, servizio e ambiente
- Anomaly detection sull'utilizzo di Datadog con interventi correttivi concreti
- Supporto Forward Deployed Engineering per l'esecuzione su Kubernetes, FinOps e CloudOps
Limiti: DoiT non sostituisce le capacità di observability di Datadog: le ottimizza e le governa. I team che puntano a una migrazione completa di piattaforma dovranno valutare una delle alternative descritte di seguito insieme al layer di gestione DoiT.
Ideale per: team CloudOps e FinOps che utilizzano Datadog su larga scala e necessitano di prevedibilità dei costi, visibilità cross-platform e supporto ingegneristico per mettere in pratica le raccomandazioni anziché limitarsi a riceverle.
SigNoz
SigNoz è una piattaforma di observability open source, OpenTelemetry-native, costruita su ClickHouse. Copre log, metriche e tracce in un unico prodotto, senza richiedere backend separati per ciascun segnale — un vantaggio operativo significativo rispetto a stack come la configurazione LGTM di Grafana, che concatena Loki, Tempo e Mimir.
SigNoz è stata progettata fin dalle fondamenta intorno a OpenTelemetry e ne comprende a fondo le convenzioni semantiche e i data model. A differenza dello stack Grafana, offre un'esperienza realmente integrata per tutti e tre i segnali: si passa da metriche a tracce a log senza cambi di contesto né linguaggi di query differenti.
Funzionalità principali:
- Ingestion OTLP nativa, senza layer di traduzione o conversione del data model
- Metriche, log e tracce unificate in un'unica interfaccia di query
- Backend ClickHouse per ingestion e aggregazione rapide su dati ad alta cardinalità
- Opzioni di deployment self-hosted o SaaS con licenza Apache 2.0
- Allineamento attivo con l'ecosistema CNCF e supporto della community
Limiti: gestire internamente lo stack SigNoz significa farsi carico di gestione, scaling e sicurezza — inclusa la dipendenza da ClickHouse, che può essere complessa da operare su larga scala. Essendo una piattaforma più recente, il set di funzionalità e l'UX sono ancora in fase di maturazione rispetto ai player storici sul mercato da un decennio.
Ideale per: team di engineering che vogliono un'observability realmente OTel-native senza vendor lock-in e dispongono della capacità di platform engineering per il self-hosting o la gestione di un deployment SaaS.
Grafana
Grafana Labs ha costruito il layer di visualizzazione utilizzato dalla maggior parte degli stack di monitoring Kubernetes. Lo stack LGTM completo — Loki per i log, Grafana per i dashboard, Tempo per le tracce, Mimir per le metriche — offre ai team un'architettura componibile in cui ogni componente scala ed evolve in modo indipendente. A settembre 2025 Grafana Labs ha superato i 400 milioni di dollari di ARR con 7.000 clienti, e OTel è al centro della strategia di observability della piattaforma: Alloy è la distribuzione Grafana dell'OpenTelemetry Collector e Beyla offre instrumentation zero-code basata su eBPF.
Funzionalità principali:
- Stack LGTM componibile con backend best-of-breed per ciascun tipo di segnale
- Metriche Prometheus-native con PromQL, il linguaggio di riferimento per il monitoring Kubernetes
- Opzione SaaS gestita Grafana Cloud con pricing a consumo
- Adaptive Metrics per il controllo della cardinalità e la gestione dei costi su Grafana Cloud
- Ampia libreria di integrazioni ed ecosistema di plugin della community
Limiti: Grafana richiede di scegliere, distribuire e collegare backend separati per log, metriche e tracce. Tra i punti dolenti più comuni: il costo operativo di gestire lo stack LGTM come quattro sistemi distinti, i limiti di alta cardinalità in Loki, la fragilità delle correlazioni quando le label non si allineano e la complessità del pricing di Grafana Cloud.
Ideale per: team già standardizzati su Prometheus e Grafana per le metriche Kubernetes, che vogliono estendersi a un'observability full-stack senza rinunciare all'investimento già fatto sugli strumenti in uso.
New Relic
Il principale elemento di differenziazione di New Relic rispetto a Datadog è il modello di fatturazione. Il database NRDB di New Relic archivia tutti i tipi di segnale in un unico telemetry database unificato, con gli host come dimensione non fatturabile: host, agent, container, device e funzioni cloud illimitati sono inclusi senza costi aggiuntivi, con un tier gratuito di ingestion di 100 GB/mese che rende la valutazione iniziale praticamente priva di attriti. Per i team CloudOps che gestiscono cluster Kubernetes in cui il numero di nodi varia con l'autoscaling, questa differenza strutturale ha implicazioni reali sui budget.
New Relic compare come Leader nel Gartner Magic Quadrant da 13 anni consecutivi, conferma che ne fa una scelta solida per team mid-market ed enterprise che vogliono un pricing a consumo senza addebiti per host.
Funzionalità principali:
- Pricing basato sugli utenti, senza addebiti per host o container
- Database di telemetria unificato NRDB per metriche, eventi, log e tracce
- 100 GB/mese di ingestion gratuita per la valutazione
- Linguaggio di query NRQL più compatibilità con PromQL
- Ampia copertura di APM, infrastruttura e monitoring della digital experience
Limiti: NRQL ha una curva di apprendimento per i nuovi utenti. La piattaforma sta consolidando molti prodotti in un'unica interfaccia, e alcuni team la trovano dispersiva. I dati ad alta cardinalità e l'ingestion intensiva di log fanno comunque salire i costi, solo attraverso un meter diverso da quello di Datadog.
Ideale per: team mid-market ed enterprise con ambienti Kubernetes estesi, dove la fatturazione per host genera esposizioni di costo imprevedibili e dove un'ampia copertura di APM e infrastruttura conta tanto quanto la prevedibilità della spesa.
Dynatrace
Dynatrace si rivolge ai team enterprise che hanno bisogno di un'observability automatizzata e AI-assisted su larga scala. La sua tecnologia OneAgent rileva e mappa automaticamente tutti i componenti e le dipendenze dell'ambiente senza configurazione manuale dell'instrumentation, e il motore Davis AI correla i segnali per un'analisi automatizzata delle cause radice. Dynatrace Full-Stack Monitoring ha un prezzo di 0,01 dollari per GiB-ora di memoria: il costo scala quindi con il footprint di memoria e il runtime degli host monitorati — un parametro più difficile da prevedere negli ambienti Kubernetes, dove dimensioni dei nodi, allocazione di memoria e densità dei workloads cambiano di frequente.
Funzionalità principali:
- Auto-instrumentation con OneAgent e mapping automatico delle dipendenze
- Davis AI per l'analisi automatizzata delle cause radice in ambienti a microservizi complessi
- Copertura full-stack su infrastruttura, APM, log, digital experience e sicurezza
- Monitoring Kubernetes avanzato, con visibilità profonda su cluster e workloads
- Funzionalità di governance enterprise tra cui RBAC, audit trail e tooling di compliance
Limiti: l'elevato grado di automazione può rendere Dynatrace poco trasparente. Quando l'AI ha ragione, è potente; quando sbaglia, è difficile capire perché. OneAgent è proprietario, il supporto OTel è aggiunto sopra anziché nativo e il pricing è pensato per le grandi aziende, risultando sproporzionato per team cloud-native più piccoli o agili.
Ideale per: grandi team enterprise con ambienti complessi ed eterogenei che vogliono un'automazione AI-assisted per ridurre il carico operativo e sono disposti a investire in una piattaforma gestita premium.
Quali sono le funzionalità chiave da cercare in un'alternativa a Datadog?
Cambiare piattaforma di observability coinvolge ogni team che ha a che fare con la produzione. Definire i criteri di valutazione fin dall'inizio evita mesi di lavoro di migrazione che si concludono su una piattaforma con gli stessi problemi strutturali, solo cambiando vendor.
Ha un'architettura OpenTelemetry-native?
OpenTelemetry è diventato lo standard de facto per l'instrumentation di telemetria vendor-neutral, e la scelta del backend di observability determina se quell'investimento si ripaga o viene assorbito in un data model proprietario.
Le piattaforme in cui OTel è nativo ingeriscono i dati OTLP senza un layer di traduzione. Datadog e Dynatrace supportano l'ingestion OTel, ma il loro valore principale è legato ad agent proprietari. I team che usano dati OTel su queste piattaforme hanno spesso un'esperienza diversa, e spesso peggiore, rispetto a chi usa l'instrumentation nativa.
Per i team CloudOps questo ha un impatto operativo: la re-instrumentation è la parte più costosa di una migrazione di piattaforma. Scegliere un backend che tratta OTel come cittadino di prima classe significa che l'investimento sull'instrumentation sopravvive alle scelte di vendor. Significa anche poter eseguire più backend in parallelo durante una migrazione, senza dover mantenere due configurazioni di agent distinte.
Offre un'observability Kubernetes-first?
Il monitoring tradizionale basato sugli host non regge negli ambienti Kubernetes. I nodi sono effimeri, i pod scalano orizzontalmente e l'unità di fatturazione (l'host) non ha alcuna relazione stabile con il workload che ospita. I team CloudOps hanno bisogno di visibilità a livello di namespace, allocazione dei costi per pod e container, tracciamento del comportamento dell'autoscaler e rilevamento dei noisy neighbor sui cluster condivisi.
DoiT Cloud Intelligence offre gestione avanzata di requests/limits, ottimizzazione dei node pool, tuning dell'autoscaler, analisi di bin-packing e controllo dei noisy neighbor tramite PerfectScale for Kubernetes, collegando il comportamento dei workloads ai risultati di costo anziché trattarli come ambiti separati. È proprio questo legame tra salute operativa e accountability dei costi a distinguere un'observability Kubernetes-first dai dashboard di monitoring generici che includono una semplice vista cluster.
Nella valutazione delle alternative, chieda esplicitamente come la piattaforma gestisce la cardinalità delle metriche generata dalle label Kubernetes. Nomi dei pod, ID dei namespace e hash dei deployment creano combinazioni di label ad alta cardinalità che possono far lievitare drasticamente i costi di storage e di query. Una piattaforma priva di una strategia esplicita per gestire quella cardinalità riprodurrà la struttura di costo di Datadog anche se sulla carta il modello di pricing sembra diverso.
Utilizza un modello di pricing con costi prevedibili?
Cambiare piattaforma significa scambiare un set di costi con un altro. La migrazione richiede dai 6 ai 12 mesi. Si ricostruiscono dashboard, monitor, integrazioni e workflow di team. Quando si finisce, il volume di dati è cresciuto abbastanza da compensare gran parte dei risparmi.
Non è un argomento contro la migrazione: è un argomento a favore della modellazione del quadro di costo completo prima di iniziare. La domanda giusta non è "quale alternativa è la più economica oggi?", bensì "quale modello di pricing resta prevedibile mentre la mia infrastruttura scala?".
Il pricing per host (Datadog, in parte Dynatrace) penalizza l'autoscaling. Il pricing per GB di ingestion (Grafana Cloud, New Relic) penalizza il logging prolisso. Il pricing per utente (il modello a seat di New Relic) penalizza l'accesso esteso alla piattaforma in team numerosi. Capire quale cost driver corrisponde al reale pattern di utilizzo è più importante della tariffa unitaria pubblicizzata.
L'approccio di DoiT aggira questo trade-off per i team che già usano Datadog. Mostrando quali metriche, log e dashboard stanno effettivamente generando i costi — e automatizzando la pulizia di quelli che non lo fanno — DoiT rende Datadog prevedibile nei costi senza richiedere una migrazione di piattaforma.
Come si migra da Datadog senza interruzioni operative?
Il rischio di migrazione si concentra in tre punti: gap di copertura degli alert durante la finestra di transizione, perdita di trace context ai confini dei servizi e complessità di rollback se la nuova piattaforma non regge sotto carico di produzione.
Un approccio di deployment in parallelo affronta tutti e tre i fronti. Esegua entrambe le piattaforme contemporaneamente, partendo da un ambiente non di produzione. Verifichi che la nuova piattaforma catturi gli stessi segnali con la stessa fedeltà e confermi che le condizioni di alert si traducano correttamente prima di dismettere Datadog in qualsiasi contesto di produzione.
Le migrazioni di successo seguono il percorso staging → una region di produzione → servizi critici → flotta, non un "cambiamo tutto venerdì sera". Un approccio per fasi consente di misurare la parità dei dati del nuovo strumento, di intercettare i gap di propagazione delle tracce — soprattutto su ingress proxy, code e flussi asincroni — e di validare le proiezioni di costo rispetto ai volumi reali prima di dismettere Datadog. Pianifichi una finestra di sovrapposizione, in genere tra i 30 e i 90 giorni, in cui entrambi gli strumenti restano attivi e la bolletta sale temporaneamente prima di scendere. I team che saltano la fase di parallel-run per risparmiare sul costo di overlap tendono a tornare indietro dopo sei settimane.
La validazione della parità degli alert merita un workstream dedicato. Non dia per scontato che ricreare le stesse condizioni di alert in una nuova piattaforma produca un comportamento equivalente: differenze nei linguaggi di query, variazioni nei data model e default delle finestre di retention possono generare gap silenziosi di copertura che emergono solo durante un incident.
Per i team che utilizzano pipeline OpenTelemetry, la migrazione ha un vantaggio strutturale: l'OTel Collector può fare dual-ship verso l'endpoint Datadog esistente e il nuovo backend contemporaneamente. Questo permette di validare la parità dei segnali senza mantenere due configurazioni di agent separate e offre un percorso di rollback pulito: basta reindirizzare l'output del collector e si torna alla baseline.
Il team di engineering di DoiT supporta migrazioni di questo tipo nell'ambito del proprio modello di engagement CloudOps, combinando tooling automatizzato e supporto ingegneristico diretto per ridurre il rischio della finestra di transizione.
Come scegliere l'alternativa a Datadog giusta per il proprio ambiente CloudOps?
La risposta onesta: l'alternativa migliore dipende dallo specifico punto di dolore che si sta cercando di risolvere.
Se il problema è il costo — spesa Datadog fuori controllo per cardinalità, ingestion dei log o numero di host — la via più rapida non sempre passa da una migrazione. Il modulo Datadog Intelligence di DoiT espone e automatizza il lavoro di riduzione dello spreco all'interno dell'ambiente Datadog esistente. È una proposta di valore diversa rispetto a qualsiasi delle alternative di piattaforma sopra elencate e, per molti team, è la prima mossa giusta prima di impegnarsi in una migrazione da 6-12 mesi.
Se il problema è il vendor lock-in o la sovranità dei dati — il team vuole un'instrumentation OTel-native che sopravviva ai cambi di vendor, oppure la telemetria deve restare all'interno della VPC — SigNoz o uno stack Grafana self-hosted offrono la massima portabilità. Il trade-off è la responsabilità operativa sui layer di storage e di query.
Se il problema è la fatturazione per host in un ambiente fortemente basato su Kubernetes — l'autoscaling rende la bolletta Datadog imprevedibile — il modello di pricing host-agnostic di New Relic affronta direttamente quella struttura. Dynatrace lo affronta in modo diverso, con operazioni automatizzate via AI che riducono il volume di alert a cui il team deve rispondere, a un livello di prezzo premium allineato ai budget enterprise.
Ciò che i team CloudOps sottovalutano sistematicamente è il costo della migrazione stessa: la re-instrumentation, la ricostruzione dei dashboard, la validazione della parità degli alert e la finestra di sovrapposizione di 30-90 giorni in cui entrambe le piattaforme restano attive. Includere questi elementi nel total cost of ownership cambia spesso l'ordine della classifica in modo significativo.
DoiT la affianca in questa analisi prima di prendere una decisione, collegando i dati di costo dell'observability alla spesa cloud effettiva, modellando l'impatto dei cambi di piattaforma e fornendo il supporto ingegneristico per percorrere la strada scelta. L'obiettivo non è spostare il costo da un'altra parte: è rendere le operazioni cloud davvero prevedibili.
Lavori con DoiT per scegliere un'alternativa a Datadog che riduca realmente la sua spesa cloud, non una che si limiti a spostare il costo altrove. Parli con DoiT.
Domande frequenti sulle alternative a Datadog
Qual è la migliore alternativa gratuita a Datadog? SigNoz è l'opzione gratuita più solida per i team CloudOps: open source con licenza Apache 2.0, supporto OTel nativo e copertura unificata di metriche, log e tracce in un'unica piattaforma self-hosted. Lo stack LGTM di Grafana è gratuito in self-hosting, ma richiede di assemblare e mantenere componenti separati per ciascun tipo di segnale. New Relic include un tier gratuito di ingestion di 100 GB/mese per i team che preferiscono un percorso di valutazione SaaS gestito.
Si può usare OpenTelemetry con le alternative a Datadog? Sì, e la compatibilità OTel è uno dei criteri più importanti per i team CloudOps che valutano alternative. SigNoz e Grafana trattano OTel come nativo: ingeriscono OTLP direttamente, senza traduzione. New Relic e Dynatrace accettano dati OTel ma li instradano attraverso data model proprietari, e questo può influire sul comportamento delle query e sulla parità di funzionalità rispetto all'uso degli agent nativi.
Quanto dura tipicamente una migrazione da Datadog? La maggior parte delle migrazioni in produzione richiede dai 6 ai 12 mesi, considerando deployment in parallelo, validazione della parità degli alert, ricostruzione dei dashboard e cambiamenti nei workflow di team. La finestra di sovrapposizione — durante la quale entrambe le piattaforme restano attive — dura tipicamente dai 30 ai 90 giorni. I team che comprimono questa finestra per ridurre i costi di overlap tendono a incontrare gap di copertura che richiedono un rollback.
Datadog vale la pena per gli ambienti Kubernetes? Datadog offre un'observability Kubernetes approfondita, ma il suo modello di fatturazione può entrare in conflitto con il modo in cui Kubernetes è progettato per funzionare. Gli addebiti per host e la fatturazione basata sulla cardinalità delle custom metric penalizzano il comportamento dell'autoscaling e le label ad alta dimensionalità che gli ambienti Kubernetes instrumentati con OTel generano naturalmente. Prima di migrare, i team CloudOps dovrebbero valutare se l'ottimizzazione dei costi — tramite strumenti come DoiT Datadog Intelligence — possa risolvere il problema senza un cambio di piattaforma.
Cosa dovrebbero cercare i team CloudOps in un'alternativa a Datadog? Le tre capacità più importanti sono: architettura OpenTelemetry-native (per proteggere gli investimenti in instrumentation ed evitare i costi di re-instrumentation nelle migrazioni future), observability Kubernetes-first (visibilità a livello di namespace, allocazione dei costi per pod e gestione della cardinalità) e un modello di pricing prevedibile che si allinei al reale comportamento di scaling anziché penalizzare autoscaling o logging prolisso.