Che cosa è il distributed tracing e come funzionano i correlation ID?

Question

Accepted Answer

**Distributed tracing** segue una singola richiesta mentre viaggia attraverso molti servizi, così puoi vedere il percorso end-to-end e trovare dove si verificano latenza o errori. Un **correlation/trace ID** lega insieme tutti gli span di una richiesta.

## Come funziona

Il primo servizio genera un **trace ID**; ogni chiamata downstream lo propaga (insieme a un **span ID** parent) negli header.

```http
GET /checkout HTTP/1.1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
# trace-id ───────────────────────────^   ^── span-id
```

```text
Trace abc123:
  Gateway      ├──────────────────────────────┤ 220ms
   Orders        ├────────────┤ 90ms
    Payments        ├──────┤ 60ms   ← slow span found here
    Inventory       ├──┤ 15ms
```

## Cosa ti dà

- **Latency breakdown** — quale servizio/span è lento.
- **Error localization** — quale hop ha fallito.
- **Dependency map** — cosa effettivamente chiama cosa.

Strumenti: OpenTelemetry (instrumentation), Jaeger / Zipkin (storage + UI).

## Pitfalls

```text
⚠️ If one service drops the trace header, the trace breaks
⚠️ 100% sampling is expensive — sample, but keep errors
⚠️ Logs are useless across services without the correlation ID attached
```

## Perché è importante

Senza tracing, il debug di una richiesta lenta o fallita attraverso una dozzina di servizi è supposizione; con esso, vedi esattamente quale hop è responsabile.

Propagare un correlation ID attraverso ogni linea di log e ogni chiamata è l'investimento di osservabilità con il più alto effetto leva in un sistema microservizi.