Narcis Miclaus

11 min de citit

Arhitectura datelor și a sistemelor, de la zero Lecția 59 / 80

Observabilitate pentru date: loguri, metrici, trace-uri, lineage

Cei trei piloni plus lineage. OpenTelemetry, Datadog, Honeycomb. Unelte de lineage (Marquez, OpenLineage, DataHub).

Lecțiile anterioare au construit povestea orchestrării: alege o unealtă, preferă încadrarea orientată pe asset-uri acolo unde se potrivește, sprijină-te pe ofertele gestionate ca să eviți taxa de cluster-ops. Odată ce pipeline-urile rulează, următoarea întrebare este cea pe care orice operator o pune într-un final marți la 03:00: ce se întâmplă, de ce se întâmplă și care lucru e responsabil. Acea întrebare este observabilitatea, iar o platformă de date fără răspunsuri bune la ea este o platformă de date care produce ocazional numere greșite și afli abia dintr-un mesaj de Slack la sfârșitul trimestrului.

Lumea web services s-a standardizat acum ani pe trei piloni ai observabilității: loguri, metrici, trace-uri. S-au scris cărți, s-au organizat conferințe, s-au construit furnizori. Lumea de date moștenește toți trei și adaugă un al patrulea de care web services nu au nevoie: lineage. Să știi cum a curs un request prin serviciile tale este versiunea web services. Să știi cum a curs un număr prin tabelele tale este versiunea de date. Sunt probleme diferite cu unelte diferite, iar o platformă de date serioasă are nevoie de ambele.

Lecția aceasta parcurge cei patru piloni, standardele (OpenTelemetry, OpenLineage) care au început să-i unifice, furnizorii (Datadog, Honeycomb, stack-ul Grafana) și uneltele specifice de lineage (Marquez, DataHub, Atlan, Monte Carlo). Scopul este imaginea de care ai nevoie înainte de lecțiile de fiabilitate din Modulul 8, care depind de a putea vedea pentru ce ești fiabil.

Cei trei piloni (moștenirea web services)

Încadrarea celor trei piloni vine din comunitatea de observabilitate de prin 2017 și a rezistat bine. Fiecare pilon răspunde la o întrebare diferită despre un sistem care rulează.

Logurile sunt înregistrări text cu timestamp ale evenimentelor. Răspund la „ce s-a întâmplat” cu cel mai mult context. O linie de log ar putea spune „utilizatorul 1234 a încercat să se logheze la 14:32:15.412 și a eșuat pentru că parola nu s-a potrivit”, care este precis și lizibil de om. Logurile sunt ușor de scris (orice limbaj are un logger), logurile structurate cu câmpuri cheie-valoare sunt acum standard, iar tooling-ul pentru a le căuta e matur.

Costul logurilor este volumul. Un serviciu ocupat produce gigaocteți pe zi. Stocarea lor e ieftină; interogarea peste intervale lungi nu este. Logurile sunt și greu de agregat: numărarea „încercărilor de login eșuate în ultima oră” prin scanarea logurilor text e lentă dacă ai un miliard. Uneltele standard rezolvă asta cu store-uri de loguri indexate: ELK (Elasticsearch, Logstash, Kibana), Datadog Logs, Splunk, Grafana Loki. Fiecare face compromisuri diferite între viteza query-urilor, costul de stocare și complexitatea operațională. Loki și Splunk sunt la extreme (ieftin-și-simplu vs scump-și-puternic); restul trăiesc între ele.

Metricile sunt serii temporale numerice. Răspund la „cât, cât de des, cât de rapid”. Numărul de cereri pe secundă, latența p99, rata de eroare, adâncimea cozii, utilizarea CPU a pod-ului. Metricile sunt extrem de ieftin de stocat (o metrică e câțiva octeți per sample) și rapid de interogat (bazele de date de serii temporale sunt construite pentru asta). Constrângerea este cardinalitatea: fiecare combinație unică de label-uri (region, service, user_id) creează o serie temporală separată, iar label-urile cu cardinalitate mare (orice per-utilizator) explodează costul de stocare și interogare. Disciplina metricilor este „ce dimensiuni contează, ce dimensiuni nu, ține cardinalitatea mică”.

Tooling-ul dominant pentru metrici: Prometheus (open-source, standardul de facto pentru metrici Kubernetes-native), Datadog Metrics (gestionat, scump, ușor), CloudWatch (AWS-native, mai puțin puternic, dar adecvat). Grafana stă deasupra tuturor ca strat de vizualizare; în 2026 majoritatea echipelor folosesc Grafana chiar și când backend-ul lor e altceva.

Trace-urile sunt înregistrări cap-coadă ale modului în care un singur request se mișcă printr-un sistem. Un request intră în API gateway, se distribuie către trei servicii, fiecare interoghează o bază de date și în final se întoarce la utilizator. Un trace coase toate astea împreună: contribuția fiecărui serviciu este un span, span-urile se leagă prin relații părinte-copil, iar arborele rezultat arată unde s-a petrecut timpul.

Trace-urile sunt răspunsul la „unde este latența?” într-un sistem distribuit. Sunt și răspunsul la „ce a făcut efectiv acest request?” când bug-ul nu e în niciun serviciu individual, ci în interacțiunea dintre mai multe. Tooling-ul: Jaeger (open-source, simplu), Zipkin (mai vechi, încă prin preajmă), Datadog APM (gestionat, complet), Honeycomb (gestionat, cu un focus particular pe interogarea cu cardinalitate mare), Lightstep (acum parte din ServiceNow, nișă similară), Grafana Tempo (open-source, se integrează cu restul stack-ului Grafana).

Încadrarea pe piloni este uneori atacată ca fiind prea rigidă (logurile, metricile, trace-urile nu sunt întotdeauna clar separate, iar uneltele moderne estompează granițele), dar ca o categorisire de început rămâne utilă. O echipă care are toți trei pilonii acoperiți cu retenție rezonabilă și viteze de interogare rezonabile are bazele rezolvate.

OpenTelemetry: standardul care le unifică

Pentru cea mai mare parte a anilor 2010, instrumentarea unui serviciu însemna să alegi un furnizor și să folosești SDK-ul lui. New Relic avea agentul lui, Datadog avea agentul lui, Splunk avea al lui, Honeycomb avea al lui. Schimbarea furnizorului însemna să smulgi SDK-ul și să pui altul în loc. Lock-in-ul de instrumentare era real și costisitor.

OpenTelemetry, născut din fuziunea OpenCensus și OpenTracing în 2019, este răspunsul. Este o specificație neutră față de furnizor (și un set de SDK-uri) pentru emiterea datelor de telemetrie: trace-uri, metrici și loguri într-un format unificat. Îți instrumentezi codul cu OpenTelemetry o singură dată. Colectorul OpenTelemetry primește datele și le redirecționează către orice backend-uri alegi: Datadog, Honeycomb, un Jaeger self-hosted, toate trei deodată. Schimbarea backend-urilor este o schimbare de configurație în colector, nu o schimbare de cod în fiecare serviciu.

Până în 2026 OpenTelemetry este implicit. Orice furnizor modern de observabilitate acceptă OTLP (Protocolul OpenTelemetry). Majoritatea uneltelor cloud-native se instrumentează automat cu OpenTelemetry. Problema lock-in-ului este în mare parte rezolvată pentru proiecte noi; serviciile legacy cu agenți specifici furnizorilor migrează treptat.

Pentru o platformă de date, asta contează pentru că uneltele de date (Spark, Flink, Airflow, dbt) emit din ce în ce mai mult telemetrie compatibilă cu OpenTelemetry. Metricile la nivel de job ale unui job Spark, timing-urile de checkpoint ale unui job de streaming Flink, runtime-ul unui task Airflow: toate pot curge prin același colector și în același backend ca restul stack-ului aplicației. Lumea de date încetează să fie o insulă.

Răsucirea data-engineering: lineage

Cei trei piloni acoperă bine povestea de observabilitate la runtime. Nu acoperă întrebarea care definește modurile specifice de eșec ale unei platforme de date: de unde a venit acest număr?

Modul de eșec al unui web service este „acest request a returnat 500” sau „acest request a fost lent”. Logurile, metricile, trace-urile îți spun de ce.

Modul de eșec al unei platforme de date este „acest număr este greșit”. Logurile, metricile, trace-urile îți spun dacă pipeline-ul a rulat. Nu îți spun dacă pipeline-ul a calculat lucrul corect, de unde a venit input-ul, ce alte tabele din aval conțin acum numărul greșit sau cine citește acele tabele din aval și ia decizii pe baza lor. Aceasta este problema lineage, și este al patrulea pilon.

Lineage-ul răspunde la patru întrebări la care cei trei piloni nu pot:

  • Care tabele din amonte au produs această coloană?
  • Care job a atins ultima oară această coloană și când?
  • Ce tabele și dashboard-uri din aval depind de această coloană?
  • Cine consumă acest dataset?

Primele două sunt forensice: când ceva e greșit, mergi înapoi prin lineage să găsești sursa. Ultimele două sunt operaționale: când vrei să deprecizi un tabel sau să schimbi o coloană, mergi înainte prin lineage să găsești pe toți cei afectați.

Fără lineage, ambele direcții sunt arheologie manuală: grep prin codebase, întreabă în Slack, speră că autorul original încă lucrează la companie. Cu lineage, ambele direcții sunt un click.

Uneltele de lineage

Ecosistemul de lineage în 2026 a maturizat în jurul unui mic set de standarde și jucători.

OpenLineage este analogul OpenTelemetry pentru lineage. Este o specificație neutră față de furnizor pentru emiterea evenimentelor de lineage: „acest job a început”, „acest job a citit din aceste tabele”, „acest job a scris în aceste tabele”, „acest job s-a terminat”. Uneltele care produc date emit evenimente OpenLineage; uneltele care consumă lineage (cataloage, platforme de observabilitate) le primesc. Până în 2026 orchestratoarele majore (Airflow, Dagster, Prefect) și uneltele de transformare (dbt, Spark, Flink) emit OpenLineage nativ, fie direct, fie prin adaptoare mici.

Marquez este implementarea de referință a unui backend OpenLineage. Este open-source, ingerează evenimente OpenLineage și expune un UI grafic de joburi și dataset-uri. Majoritatea magazinelor nu rulează Marquez direct; rulează un catalog de nivel mai înalt care folosește OpenLineage ca protocol de ingestie.

DataHub este cel mai larg deployat catalog de date open-source în 2026. Originar de la LinkedIn, open-sourced în 2020. Ingerează metadate din baze de date, dashboard-uri, orchestratoare și pipeline-uri, construiește un graf unificat și expune căutare, navigare lineage și informații de ownership. Self-hosting DataHub nu e trivial (are propriul Kafka, Elasticsearch, MySQL, GraphQL API), dar pentru magazinele suficient de mari încât să aibă nevoie de el, costul operațional este amortizat de valoarea la nivel de platformă.

Atlan, Monte Carlo, Lightup sunt jucătorii gestionați. Atlan se concentrează pe unghiul de catalog și colaborare; Monte Carlo pe observabilitate de date și detecție de anomalii (gen: alerte învățate de mașini pe row counts și freshness); Lightup pe teritoriu similar. Piața este competitivă în 2026 și granițele se estompează. Pattern-ul e similar la toți: ingerează metadate și lineage din stack-ul tău, expune un UI, alertează la anomalii.

dbt merită o mențiune separată. Graful de modele dbt este el însuși un graf de lineage, iar dbt îl emite nativ de la începutul proiectului. Integrarea cu cataloagele din aval (DataHub, Atlan, Monte Carlo) este bătătorită: fiecare rulare dbt produce un manifest pe care catalogul îl ingerează, iar modelele dbt apar în catalog alături de tabelele de warehouse pe care le materializează. Pentru magazinele care s-au standardizat pe dbt pentru transformări, povestea de lineage se scrie în mare parte singură; pentru magazinele care nu, costul de instrumentare manuală este mai mare.

Un mic sistem de date observabil

Strângând cei patru piloni laolaltă, iată cum arată un sistem de date rezonabil instrumentat în 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 --> DH

Diagramă de creat: o versiune polisată a diagramei de instrumentare cu patru piloni. Punctul vizual este că telemetria curge prin două canale paralele (OpenTelemetry pentru cei trei piloni de runtime, OpenLineage pentru pilonul de lineage al datelor), fiecare aterizează în propriul backend, iar stratul de UI stă deasupra. Standardele converg instrumentarea; backend-urile și UI-urile sunt preocupări separate.

Forma se generalizează. Majoritatea platformelor de date moderne au ceva ca asta: un pipeline de telemetrie pentru observabilitate la runtime, unul pentru lineage, ambele alimentând în backend-uri pe care echipa le interoghează printr-un număr mic de UI-uri.

Cum se pune asta cap la cap la 03:00

Testul unui stack de observabilitate este ce se întâmplă când ceva e greșit. Ia o eroare concretă. Asset-ul customer_clv este greșit pe dashboard-ul de marți dimineața.

Operatorul de pipeline deschide DataHub, găsește asset-ul customer_clv și merge înapoi prin lineage. Asset-ul depinde de customer_features, care depinde de sessionized_events, care depinde de raw_events. Cu două ore mai în amonte, jobul de ingestie raw_events a avut o eroare Spark: o eroare out-of-memory pe pod-ul de executor pe care clusterul l-a restart, dar cu o scriere parțială pe care calculele din aval au consumat-o fără să-și dea seama că era incompletă.

Aceia sunt toți cei patru piloni la lucru. Lineage-ul a indicat jobul corect din amonte. Logurile (de la pod-ul driver Spark) au arătat eroarea executorului. Metricile (utilizarea memoriei executorului în timp) au confirmat că era OOM. Trace-urile (trace-ul task-ului orchestratorului care a rulat jobul) au arătat eroarea apărând ca un task din aval care reușește când ar fi trebuit să eșueze. Fără oricare dintre ele, diagnosticul durează mai mult; cu toți patru, durează minute.

Aceasta este teza „nu poți gestiona ce nu poți vedea” în termeni operaționali. Observabilitatea nu este un lux pe care îl adaugi după ce platforma rulează; este precondiția pentru o platformă pentru care cineva vrea să fie de gardă. Un pipeline pe care nu îl poți vedea este un pipeline care se rupe în tăcere și e prins de utilizatori în loc de operatori.

Ce pregătește această lecție pentru restul Modulului 8

Lecțiile următoare din Modulul 8 construiesc pe această fundație. Practicile de fiabilitate (SLO-uri pentru date, rotații on-call, postmortem-uri, răspuns la incidente) presupun toate că echipa poate vedea ce se întâmplă. Fără observabilitate, un SLO este aspirațional; cu ea, SLO-ul este un număr pe care îl poți măsura și un grafic pe care îl poți arăta stakeholderilor.

Același lucru e adevărat pentru povestea calității datelor (care stă adiacent observabilității, dar nu este exact observabilitate): unelte ca Great Expectations, dbt tests și detecția de anomalii Monte Carlo presupun că există un loc unde să trimiți rezultatele testelor și un drum de alertă care ridică erorile. Stack-ul de observabilitate este acel loc și acel drum.

Pentru 2026 recomandările pragmatice: instrumentează cu OpenTelemetry de la prima zi. Alege un backend de loguri/metrici/trace-uri care se potrivește scării tale (stack-ul Grafana pentru echipele atente la cost, Datadog sau Honeycomb pentru echipele dispuse să plătească pentru ergonomie, stack-ul nativ al furnizorului de cloud pentru echipele deja adânc într-un cloud). Emite OpenLineage din orchestratorul tău și uneltele de transformare. Alege un catalog (DataHub dacă te self-hostezi, Atlan sau Monte Carlo dacă vrei gestionat). Conectează-le. Așteaptă-te ca munca de conectare să fie mai enervantă decât sugerează documentația și ca răsplata să sosească prima dată când cineva întreabă „de unde a venit acest număr” și primește un răspuns în treizeci de secunde în loc de trei zile.

Citate și lecturi suplimentare

  • Documentația OpenTelemetry, https://opentelemetry.io/docs/ (consultat 2026-05-01). Standardul neutru față de furnizor pentru trace-uri, metrici și (din ce în ce mai mult) loguri. Secțiunea „concepts” este punctul de plecare potrivit.
  • Documentația OpenLineage, https://openlineage.io/docs/ (consultat 2026-05-01). Analogul de lineage, cu o listă de producători (Airflow, Spark, dbt, Dagster, Flink) și consumatori (Marquez, DataHub).
  • Cindy Sridharan, „Distributed Systems Observability” (O’Reilly, 2018). Cartea care a cristalizat încadrarea celor trei piloni pentru comunitatea mai largă.
  • Charity Majors, Liz Fong-Jones, George Miranda, „Observability Engineering” (O’Reilly, 2022). Perspectiva Honeycomb asupra observabilității ca disciplină, cu argumentul anti-trei-piloni care merită citit pentru echilibru.
  • Documentația DataHub, https://datahubproject.io/docs/ (consultat 2026-05-01). Catalogul pe care aterizează majoritatea stack-urilor de lineage self-hosted până în 2026.
  • Blogurile de inginerie Datadog și Honeycomb, https://www.datadoghq.com/blog/ și https://www.honeycomb.io/blog/ (consultat 2026-05-01). Utile pentru perspectiva de furnizor asupra direcției observabilității și a felului în care OpenTelemetry remodelează piața.
Caută