Le due lezioni precedenti hanno costruito la storia dell’orchestrazione: scegli un tool, preferisci il framing asset-oriented dove ha senso, appoggiati alle offerte managed per saltare la tassa delle operazioni di cluster. Una volta che le pipeline girano, la prossima domanda è quella che ogni operatore alla fine si pone alle 03:00 di un martedì: cosa sta succedendo, perché sta succedendo, e chi è responsabile. Quella domanda è osservabilità, e una piattaforma dati senza buone risposte è una piattaforma dati che ogni tanto produce numeri sbagliati e te ne accorgi solo da un messaggio Slack alla fine del trimestre.
Il mondo dei web service si è standardizzato anni fa sui tre pilastri dell’osservabilità: log, metriche, trace. Sono stati scritti libri, organizzate conferenze, costruiti vendor. Il mondo dei dati eredita tutti e tre e ne aggiunge un quarto di cui i web service non hanno bisogno: il lineage. Sapere come una richiesta è scorsa attraverso i tuoi servizi è la versione web service. Sapere come un numero è scorso attraverso le tue tabelle è la versione dati. Sono problemi diversi con tool diversi, e una piattaforma dati seria ha bisogno di entrambi.
Questa lezione passa in rassegna i quattro pilastri, gli standard (OpenTelemetry, OpenLineage) che hanno iniziato a unificarli, i vendor (Datadog, Honeycomb, lo stack Grafana), e i tool specifici per il lineage (Marquez, DataHub, Atlan, Monte Carlo). L’obiettivo è il quadro che ti serve prima delle lezioni del Modulo 8 sull’affidabilità, che dipendono dalla capacità di vedere su cosa sei affidabile.
I tre pilastri (l’eredità dei web service)
Il framing dei tre pilastri viene dalla community dell’osservabilità verso il 2017 e ha retto bene. Ogni pilastro risponde a una domanda diversa su un sistema in esecuzione.
I log sono record testuali con timestamp di eventi. Rispondono al “cosa è successo” con il massimo di contesto. Una linea di log potrebbe dire “l’utente 1234 ha tentato di fare login alle 14:32:15.412 ed è fallito perché la password non corrispondeva”, che è preciso e leggibile dagli umani. I log sono facili da scrivere (ogni linguaggio ha un logger), i log strutturati con campi key-value sono ormai standard, e il tooling per cercarli è maturo.
Il costo dei log è il volume. Un servizio impegnato produce gigabyte al giorno. Conservarli è economico; interrogarli su lunghi range temporali no. I log sono anche difficili da aggregare: contare i “tentativi di login falliti nell’ultima ora” facendo lo scan di log testuali è lento se ne hai un miliardo. I tool standard gestiscono questo con log store indicizzati: ELK (Elasticsearch, Logstash, Kibana), Datadog Logs, Splunk, Grafana Loki. Ciascuno fa trade-off diversi tra velocità di query, costo dello storage, e complessità operativa. Loki e Splunk stanno agli estremi (economico-e-semplice contro costoso-e-potente); il resto vive nel mezzo.
Le metriche sono serie temporali numeriche. Rispondono a “quanto, quanto spesso, quanto in fretta”. Numero di richieste al secondo, p99 di latenza, error rate, profondità della coda, uso CPU del pod. Le metriche sono estremamente economiche da conservare (una metrica sono pochi byte per sample) e veloci da interrogare (i database time-series sono costruiti per questo). Il vincolo è la cardinalità: ogni combinazione unica di label (region, service, user_id) crea una serie temporale separata, e label ad alta cardinalità (qualunque cosa per-utente) fanno esplodere il costo di storage e di query. La disciplina delle metriche è “quali dimensioni contano, quali no, tieni la cardinalità bassa”.
Il tooling dominante per le metriche: Prometheus (open-source, lo standard de facto per le metriche Kubernetes-native), Datadog Metrics (managed, costoso, facile), CloudWatch (AWS-native, meno potente ma adeguato). Grafana sta sopra a tutti come layer di visualizzazione; nel 2026 la maggior parte dei team usa Grafana anche quando il backend è qualcos’altro.
I trace sono record end-to-end di come una singola richiesta si muove attraverso un sistema. Una richiesta arriva all’API gateway, si dirama su tre servizi, ciascuno dei quali interroga un database, e infine torna all’utente. Un trace cuce tutto questo insieme: il contributo di ciascun servizio è uno span, gli span si collegano per relazioni parent-child, e l’albero risultante mostra dove è stato speso il tempo.
I trace sono la risposta a “dov’è la latenza?” in un sistema distribuito. Sono anche la risposta a “cosa ha fatto davvero questa richiesta?” quando il bug non è in un singolo servizio ma nell’interazione tra diversi. Il tooling: Jaeger (open-source, semplice), Zipkin (più vecchio, ancora in giro), Datadog APM (managed, full-featured), Honeycomb (managed, con un focus particolare sulle query ad alta cardinalità), Lightstep (ora parte di ServiceNow, nicchia simile), Grafana Tempo (open-source, si integra con il resto dello stack Grafana).
Il framing dei pilastri viene a volte attaccato per essere troppo rigido (log, metriche, trace non sono sempre puliti e separati, e i tool moderni sfumano i confini), ma come categorizzazione di partenza resta utile. Un team che ha tutti e tre i pilastri coperti con retention ragionevole e velocità di query ragionevoli ha le basi sotto controllo.
OpenTelemetry: lo standard che li unifica
Per gran parte degli anni 2010, strumentare un servizio voleva dire scegliere un vendor e usare il suo SDK. New Relic aveva il suo agent, Datadog aveva il suo, Splunk il suo, Honeycomb il suo. Cambiare vendor voleva dire strappare lo SDK e metterne uno nuovo. Il lock-in di strumentazione era reale e costoso.
OpenTelemetry, nato dalla fusione di OpenCensus e OpenTracing nel 2019, è la risposta. È una specifica vendor-neutral (e un set di SDK) per emettere dati di telemetria: trace, metriche, e log in un formato unificato. Strumenti il tuo codice con OpenTelemetry una volta sola. Il collector OpenTelemetry riceve i dati e li inoltra a qualunque backend tu scelga: Datadog, Honeycomb, un Jaeger self-hosted, tutti e tre insieme. Cambiare backend è un cambio di config nel collector, non un cambio di codice in ogni servizio.
Per il 2026 OpenTelemetry è il default. Ogni vendor moderno di osservabilità accetta OTLP (l’OpenTelemetry Protocol). La maggior parte dei tool cloud-native si auto-strumenta con OpenTelemetry. Il problema del lock-in è in gran parte risolto per i progetti nuovi; i servizi legacy con agent vendor-specific stanno migrando gradualmente.
Per una piattaforma dati questo conta perché i tool dati (Spark, Flink, Airflow, dbt) emettono sempre più telemetria compatibile con OpenTelemetry. Le metriche a livello di job di uno Spark job, i tempi di checkpoint di un job streaming Flink, il runtime di un task Airflow: tutto questo può scorrere attraverso lo stesso collector e dentro lo stesso backend del resto dello stack applicativo. Il mondo dei dati smette di essere un’isola.
Il twist data-engineering: il lineage
I tre pilastri coprono bene la storia di osservabilità a runtime. Non coprono la domanda che definisce le specifiche failure mode di una piattaforma dati: da dove arriva questo numero?
La failure mode di un web service è “questa richiesta ha tornato 500” o “questa richiesta è stata lenta”. Log, metriche, trace ti dicono perché.
La failure mode di una piattaforma dati è “questo numero è sbagliato”. Log, metriche, trace ti dicono se la pipeline è girata. Non ti dicono se la pipeline ha calcolato la cosa giusta, da dove arriva l’input, quali altre tabelle downstream contengono ora il numero sbagliato, o chi sta leggendo quelle tabelle downstream e prendendo decisioni su di esse. Quello è il problema del lineage, ed è il quarto pilastro.
Il lineage risponde a quattro domande a cui i tre pilastri non possono:
- Quali tabelle upstream hanno prodotto questa colonna?
- Quale job ha toccato per ultimo questa colonna, e quando?
- Quali tabelle e dashboard downstream dipendono da questa colonna?
- Chi consuma questo dataset?
Le prime due sono forensi: quando qualcosa è sbagliato, cammini all’indietro attraverso il lineage per trovare la sorgente. Le ultime due sono operative: quando vuoi deprecare una tabella o cambiare una colonna, cammini in avanti attraverso il lineage per trovare tutti i colpiti.
Senza lineage, entrambe le direzioni sono archeologia manuale: grep sulla codebase, chiedi in giro su Slack, spera che l’autore originale lavori ancora in azienda. Con il lineage, entrambe le direzioni sono un click.
I tool di lineage
L’ecosistema del lineage nel 2026 è maturato attorno a un piccolo set di standard e attori.
OpenLineage è l’analogo di OpenTelemetry per il lineage. È una specifica vendor-neutral per emettere eventi di lineage: “questo job è partito”, “questo job ha letto da queste tabelle”, “questo job ha scritto a queste tabelle”, “questo job è finito”. I tool che producono dati emettono eventi OpenLineage; i tool che consumano lineage (cataloghi, piattaforme di osservabilità) li ricevono. Per il 2026 i principali orchestrator (Airflow, Dagster, Prefect) e i tool di trasformazione (dbt, Spark, Flink) emettono OpenLineage nativamente, sia direttamente che tramite piccoli adapter.
Marquez è l’implementazione di riferimento di un backend OpenLineage. È open-source, ingerisce eventi OpenLineage, ed espone una UI a grafo di job e dataset. La maggior parte delle shop non fa girare Marquez direttamente; fa girare un catalogo di livello più alto che usa OpenLineage come protocollo di ingestione.
DataHub è il catalogo dati open-source più diffuso nel 2026. Originato a LinkedIn, open-sourcato nel 2020. Ingerisce metadata da database, dashboard, orchestrator e pipeline, costruisce un grafo unificato, ed espone ricerca, navigazione del lineage, e informazioni di ownership. Self-hostare DataHub è non banale (ha il suo Kafka, Elasticsearch, MySQL, GraphQL API), ma per le shop abbastanza grandi da averne bisogno, il costo operativo è ammortizzato dal valore esteso a tutta la piattaforma.
Atlan, Monte Carlo, Lightup sono gli attori managed. Atlan si concentra sul catalogo e sull’angolazione di collaborazione; Monte Carlo sull’osservabilità del dato e il rilevamento di anomalie (pensa: alert appresi via machine learning su row count e freschezza); Lightup su territorio simile. Il mercato è competitivo nel 2026 e i confini sfumano. Il pattern è simile tra di loro: ingerisci metadata e lineage dal tuo stack, esponi una UI, manda alert sulle anomalie.
dbt merita una menzione separata. Il grafo dei modelli dbt è esso stesso un grafo di lineage, e dbt lo emette nativamente sin dall’inizio del progetto. L’integrazione con i cataloghi downstream (DataHub, Atlan, Monte Carlo) è ben battuta: ogni run dbt produce un manifest che il catalogo ingerisce, e i modelli dbt appaiono nel catalogo accanto alle tabelle del warehouse che materializzano. Per le shop che si sono standardizzate su dbt per le trasformazioni, la storia del lineage in gran parte si scrive da sola; per quelle che non l’hanno fatto, il costo di strumentazione manuale è più alto.
Un piccolo sistema dati osservabile
Mettendo insieme i quattro pilastri, ecco com’è fatto un sistema dati ragionevolmente strumentato nel 2026:
flowchart LR
subgraph services[Services and pipelines]
AF[Airflow]
DBT[dbt]
SPARK[Spark jobs]
FLINK[Flink streaming]
APP[Application services]
end
subgraph telemetry[Telemetry pipeline]
OTEL[OpenTelemetry collector]
OL[OpenLineage events]
end
subgraph backends[Observability backends]
LOGS[(Logs<br/>Loki/Datadog)]
METRICS[(Metrics<br/>Prometheus)]
TRACES[(Traces<br/>Tempo/Honeycomb)]
CAT[(Catalogue<br/>DataHub)]
end
subgraph ui[UI layer]
GRAF[Grafana]
DH[DataHub UI]
end
AF -->|logs, traces, metrics| OTEL
DBT -->|logs, OpenLineage| OTEL
DBT -->|OpenLineage| OL
SPARK -->|logs, metrics| OTEL
FLINK -->|logs, metrics, traces| OTEL
APP -->|logs, metrics, traces| OTEL
AF -->|OpenLineage| OL
OTEL --> LOGS
OTEL --> METRICS
OTEL --> TRACES
OL --> CAT
LOGS --> GRAF
METRICS --> GRAF
TRACES --> GRAF
CAT --> DHDiagramma da creare: una versione rifinita del diagramma di strumentazione a quattro pilastri. Il punto visivo è che la telemetria scorre attraverso due canali paralleli (OpenTelemetry per i tre pilastri runtime, OpenLineage per il pilastro del lineage dati), ciascuno atterra nel suo backend, e il livello UI sta sopra. Gli standard convergono la strumentazione; backend e UI sono preoccupazioni separate.
La forma generalizza. La maggior parte delle piattaforme dati moderne ha qualcosa così: una pipeline di telemetria per l’osservabilità a runtime, una per il lineage, entrambe che alimentano backend che il team interroga attraverso un piccolo numero di UI.
Come tutto questo si compone alle 03:00
Il test di uno stack di osservabilità è cosa succede quando qualcosa va storto. Prendi un fallimento concreto. L’asset customer_clv è sbagliato sulla dashboard del martedì mattina.
L’operatore della pipeline apre DataHub, trova l’asset customer_clv, e cammina all’indietro attraverso il lineage. L’asset dipende da customer_features, che dipende da sessionized_events, che dipende da raw_events. Due ore upstream, il job di ingestione raw_events ha avuto un errore Spark: un fallimento out-of-memory sul pod executor che il cluster ha riavviato, ma con una scrittura parziale che le computazioni downstream hanno consumato senza accorgersi che fosse incompleta.
Ecco tutti e quattro i pilastri al lavoro. Il lineage ha puntato al job upstream giusto. I log (dal pod del driver Spark) hanno mostrato il fallimento dell’executor. Le metriche (uso memoria dell’executor nel tempo) hanno confermato che era OOM. I trace (il trace del task dell’orchestrator che ha eseguito il job) hanno mostrato il fallimento che affiorava come task downstream riuscito quando avrebbe dovuto fallire. Senza uno qualsiasi di loro, la diagnosi richiede più tempo; con tutti e quattro, richiede minuti.
Questa è la tesi di “non puoi gestire ciò che non puoi vedere” in termini operativi. L’osservabilità non è un lusso che imbulloni dopo che la piattaforma gira; è la precondizione per una piattaforma su cui qualcuno voglia essere reperibile. Una pipeline che non puoi vedere è una pipeline che si rompe in silenzio e viene beccata dagli utenti invece che dagli operatori.
Cosa allestisce questa lezione per il resto del Modulo 8
Le prossime lezioni del Modulo 8 costruiscono su questa fondazione. Le pratiche di affidabilità (SLO per i dati, rotazioni on-call, postmortem, risposta agli incidenti) assumono tutte che il team possa vedere cosa sta succedendo. Senza osservabilità, una SLO è aspirazionale; con essa, la SLO è un numero che puoi misurare e un grafico che puoi mostrare agli stakeholder.
Lo stesso vale per la storia della qualità del dato (che sta accanto ma non è esattamente osservabilità): tool come Great Expectations, dbt test, e il rilevamento di anomalie di Monte Carlo assumono che ci sia un posto a cui mandare i risultati dei test e un percorso di alert che fa affiorare i fallimenti. Lo stack di osservabilità è quel posto e quel percorso.
Per il 2026 le raccomandazioni pragmatiche: strumenta con OpenTelemetry dal primo giorno. Scegli un backend di log/metriche/trace che si adatti alla tua scala (stack Grafana per team attenti ai costi, Datadog o Honeycomb per team disposti a pagare per l’ergonomia, lo stack nativo del cloud provider per team già profondi in un solo cloud). Emetti OpenLineage dal tuo orchestrator e dai tuoi tool di trasformazione. Scegli un catalogo (DataHub se self-hosti, Atlan o Monte Carlo se vuoi managed). Connettili. Aspettati che il lavoro di connessione sia più fastidioso di quello che la documentazione suggerisce, e che il payoff arrivi la prima volta che qualcuno chiede “da dove arriva questo numero” e ottiene una risposta in trenta secondi invece che in tre giorni.
Riferimenti e approfondimenti
- OpenTelemetry documentation,
https://opentelemetry.io/docs/(consultato 2026-05-01). Lo standard vendor-neutral per trace, metriche, e (sempre più) log. La sezione “concepts” è il giusto punto di partenza. - OpenLineage documentation,
https://openlineage.io/docs/(consultato 2026-05-01). L’analogo per il lineage, con una lista di produttori (Airflow, Spark, dbt, Dagster, Flink) e consumatori (Marquez, DataHub). - Cindy Sridharan, “Distributed Systems Observability” (O’Reilly, 2018). Il libro che ha cristallizzato il framing dei tre pilastri per la community più ampia.
- Charity Majors, Liz Fong-Jones, George Miranda, “Observability Engineering” (O’Reilly, 2022). La prospettiva di Honeycomb sull’osservabilità come disciplina, con l’argomento anti-tre-pilastri che vale la pena leggere per equilibrio.
- DataHub documentation,
https://datahubproject.io/docs/(consultato 2026-05-01). Il catalogo su cui la maggior parte degli stack di lineage self-hosted atterra entro il 2026. - Datadog and Honeycomb engineering blogs,
https://www.datadoghq.com/blog/ehttps://www.honeycomb.io/blog/(consultato 2026-05-01). Utili per la prospettiva vendor su dove sta andando l’osservabilità e su come OpenTelemetry sta rimodellando il mercato.