Co to jest rozproszone śledzenie (distributed tracing) i jak działają identyfikatory korelacji (correlation IDs)?

Question

Accepted Answer

**Rozproszone śledzenie** śledzi pojedyncze żądanie w miarę jak przechodzi przez wiele serwisów, dzięki czemu możesz zobaczyć kompleksową ścieżkę i znaleźć, gdzie występuje opóźnienie lub błędy. **Identyfikator korelacji/śledzenia** wiąże wszystkie zakresy (spans) jednego żądania razem.

## Jak to działa

Pierwszy serwis generuje **identyfikator śledzenia** (trace ID); każde wywołanie w dół propaguje go (i nadrzędny **identyfikator zakresu** (span ID)) w nagłówkach.

```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
```

## Co to daje

- **Rozbicie opóźnień** — który serwis/zakres jest wolny.
- **Lokalizacja błędów** — który przeskok się nie powiódł.
- **Mapa zależności** — co faktycznie wywołuje co.

Narzędzia: OpenTelemetry (instrumentacja), Jaeger / Zipkin (przechowywanie + UI).

## Pułapki

```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
```

## Dlaczego to ważne

Bez śledzenia debugowanie wolnego lub niedziałającego żądania w wielu serwisach to zgadywanie; dzięki niemu widzisz dokładnie, który przeskok jest winny.

Propagowanie identyfikatora korelacji przez każdą linię logu i każde wywołanie to najwyższa inwestycja w observability w systemach mikrousług.