🟢 Junior Level

Distributed tracing — це відстеження одного запиту через усі мікросервіси, через які він проходить.

Запит: GET /orders/123

Trace ID: abc-123
  Span 1: API Gateway (10ms)
    Span 2: Order Service (50ms)
      Span 3: User Service (20ms)
      Span 4: Payment Service (30ms)

Навіщо: Зрозуміти де виникає проблема (латентність, помилка) в ланцюжку сервісів.

Trace ID propagates через HTTP-заголовки (W3C Trace Context: traceparent) або через message headers (Kafka headers). Кожен сервіс додає свій span ID.

---

🟡 Middle Level

Trace, Span, TraceId

Trace — увесь шлях запиту (traceId: abc-123)
Span — один виклик у ланцюжку (spanId: span-1, span-2...)
TraceId — ідентифікатор всього трейсу
ParentSpanId — посилання на попередній span

Jaeger / Zipkin

// Spring Cloud Sleuth + Zipkin
// ⚠️ Spring Cloud Sleuth deprecated в Spring Boot 3.0+.
// Використовуйте Micrometer Tracing з backend (Zipkin, Jaeger).
// Автоматично додає traceId у логи та заголовки

@RestController
public class OrderController {
    private final RestTemplate restTemplate;

    @GetMapping("/orders/{id}")
    public Order getOrder(@PathVariable Long id) {
        // Trace ID автоматично доданий у HTTP-заголовок `traceparent` (W3C Trace Context).
        return restTemplate.getForObject(
            "http://order-service/orders/" + id, Order.class);
    }
}

Типові помилки

1. Втрата traceId:

   Async call → traceId не передається
   Рішення: використовувати trace context propagation
   

---

Коли distributed tracing НЕ потрібен

• 2-3 сервіси — достатньо логів з correlation ID
• 100% sampling допустимий при малому трафіку — немає необхідності в sampling

---

🔴 Senior Level

OpenTelemetry

// OpenTelemetry — стандарт для tracing
Tracer tracer = GlobalOpenTelemetry.getTracer("my-service");

Span span = tracer.spanBuilder("processOrder")
    .setSpanKind(SpanKind.SERVER)
    .startSpan();

try (Scope scope = span.makeCurrent()) {
    span.setAttribute("order.id", orderId);
    processOrder(orderId);
    span.setStatus(StatusCode.OK);
} catch (Exception e) {
    span.setStatus(StatusCode.ERROR);
    span.recordException(e);
    throw e;
} finally {
    span.end();
}

Production Experience

Log correlation:

Логи з traceId:
[traceId=abc-123] [spanId=span-1] OrderService - Processing order 123
[traceId=abc-123] [spanId=span-2] UserService - Fetching user 456
[traceId=abc-123] [spanId=span-3] PaymentService - Charging payment

Best Practices

✅ TraceId в усіх логах
✅ Sampling для high-traffic
✅ Span для всіх зовнішніх викликів
✅ Tags для бізнес-метрик

❌ Без tracing у production
❌ 100% sampling для high-traffic
❌ Без traceId в логах

---

🎯 Шпаргалка для співбесіди

Обов’язково знати:

• Distributed tracing — відстеження одного запиту через усі мікросервіси
• Trace = увесь шлях запиту (traceId), Span = один виклик у ланцюжку (spanId)
• TraceId propagates через HTTP-заголовки (W3C Trace Context: traceparent) або message headers
• Jaeger / Zipkin — backend для зберігання та візуалізації трейсів
• OpenTelemetry — стандарт для tracing, замінив OpenTracing/OpenCensus
• Sampling для high-traffic (не 100%!) — економить storage
• Log correlation: traceId в кожному лозі — пов’язує логи з трейсами
• НЕ потрібен для 2-3 сервісів — достатньо логів з correlation ID

Часті уточнюючі питання:

• Trace vs Span? Trace = увесь шлях запиту через усі сервіси, Span = один виклик (один сервіс) всередині трейсу.
• Навіщо sampling? 100% sampling для high-traffic = терабайти даних. 1-10% достатньо для аналізу.
• Spring Cloud Sleuth status? Deprecated в Spring Boot 3.0+ — використовуйте Micrometer Tracing.
• Що таке trace context propagation? Передача traceId/spanId через HTTP-заголовки або message headers між сервісами.

Червоні прапорці (НЕ говорити):

• “100% sampling для production” — ні, терабайти даних при high-traffic
• “Tracing = логування” — ні, tracing = структура запиту, логи = деталі
• “TraceId не потрібен в логах” — без нього неможливо пов’язати логи з трейсами
• “Distributed tracing потрібен завжди” — ні, для 2-3 сервісів вистачить correlation ID

Пов’язані теми:

• [[21. Як моніторити розподілену систему мікросервісів]]
• [[15. Як організувати комунікацію між мікросервісами]]
• [[1. Що таке патерн Saga і коли його використовувати]]
• [[3. Як реалізувати розподілені транзакції в мікросервісах]]
• [[7. Що таке Service Discovery і навіщо він потрібен]]