PricingLoginStart free
Production Debugging & Incident Response Playbook · Lekcja

Distributed tracing dla wąskich gardeł opóźnień

Dowiedz się, jak używać distributed tracing do śledzenia pojedynczego żądania między usługami, identyfikowania wąskich gardeł opóźnień i korelowania trace'ów z logami podczas debugowania produkcji.

Lekcja 4 z 413 kroki

Distributed tracing dla wąskich gardeł opóźnień to bezpłatna lekcja Production Debugging & Incident Response Playbook na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Production Debugging & Incident Response Playbook, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Production Debugging & Incident Response Playbook zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

Why Distributed Tracing

In a microservice system a single user request can fan out across dozens of services. When it is slow, which service is to blame?

Distributed tracing answers this by attaching a shared trace_id to a request and recording a span for every operation it touches.

  • A trace = the whole request journey
  • A span = one timed unit of work

Anatomy of a Span

Each span carries timing and context so you can reconstruct the call tree.

  • trace_id links all spans of one request
  • span_id identifies the operation
  • parent_id records who called it
  • start/end timestamps give duration
{
  "trace_id": "abc123",
  "span_id": "s2",
  "parent_id": "s1",
  "name": "db.query.users",
  "start_ms": 1042,
  "end_ms": 1310
}

Context Propagation

For spans to join one trace, the trace_id must travel with the request. This is called context propagation.

Most systems inject standard headers like traceparent (W3C Trace Context) into outgoing HTTP calls and message metadata.

If propagation breaks, traces fragment and the call tree falls apart.

GET /orders HTTP/1.1
traceparent: 00-abc123-s1-01

Instrumenting Code

You create spans around the operations you want to measure. Auto-instrumentation covers common libraries; manual spans capture your own logic.

The example below wraps a function in a span using OpenTelemetry conventions.

with tracer.start_as_current_span('charge_card') as span:
    span.set_attribute('amount', 42)
    result = payment.charge(42)
    span.set_attribute('status', result.status)

Reading the Waterfall

Tracing UIs show spans as a waterfall. The widest bar that is NOT just waiting on a child is usually your hotspot.

  • Long bars with no children = local CPU/IO cost
  • Long bars full of children = downstream cost
  • Gaps between spans = queueing or untraced work

Sampling Strategies

Tracing every request is expensive. Sampling keeps volume manageable.

  • Head sampling: decide at the start (e.g. keep 5%)
  • Tail sampling: decide after the trace ends, keeping slow or errored traces

For debugging latency, tail sampling on high duration is invaluable.

Correlating Traces and Logs

A trace tells you where; logs tell you why. Stamp every log line with the active trace_id so you can jump from a slow span straight to its logs.

import logging
logging.info('cache miss', extra={'trace_id': current_trace_id()})

Span Attributes and Events

Attributes are key/value tags on a span (db statement, HTTP status). Events are timestamped points inside a span (retry, lock acquired).

Rich attributes let you filter traces like 'all spans where db.rows > 10000', turning tracing into a query tool.

span.add_event('retry', {'attempt': 2})
span.set_attribute('db.rows', 12044)

Finding the Critical Path

Total latency is not the sum of all spans. Parallel spans overlap. The critical path is the chain of spans that actually determines end-to-end time.

Optimizing a span NOT on the critical path will not make the request faster.

Tracing Async and Queues

Across queues, the consumer runs later than the producer. Propagate the context inside the message so the consumer span links back as a follows-from relationship instead of a parent-child one.

producer:  msg.headers['traceparent'] = inject_context()
consumer:  ctx = extract_context(msg.headers)

A Debugging Workflow

Put it together when an endpoint is slow in production:

  • Filter traces for that endpoint sorted by duration
  • Open the slowest trace and read the waterfall
  • Identify the dominant span on the critical path
  • Jump to that span's logs via trace_id
  • Fix, then re-check the latency distribution

Quick Check

Test your understanding of distributed tracing.

Odpowiedz w interaktywnej lekcji

Recap

You learned how distributed tracing reconstructs a request across services using trace_id, spans, and context propagation.

  • Read waterfalls to find hotspots
  • Focus on the critical path, not total span time
  • Use tail sampling to keep slow traces
  • Correlate spans with logs for the full story
Bezpłatny start

Ucz się Production Debugging & Incident Response Playbook dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy
12
Lekcje
48
Zacznij naukę bezpłatnieWyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Distributed tracing dla wąskich gardeł opóźnień” jest bezpłatna?

Tak — pełny tekst „Distributed tracing dla wąskich gardeł opóźnień” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Production Debugging & Incident Response Playbook, przejdź na CoddyKit PRO. Kurs Production Debugging & Incident Response Playbook zawiera 4 lekcji w sumie.

Co nauczysz się w „Distributed tracing dla wąskich gardeł opóźnień”?

Dowiedz się, jak używać distributed tracing do śledzenia pojedynczego żądania między usługami, identyfikowania wąskich gardeł opóźnień i korelowania trace'ów z logami podczas debugowania produkcji. Ćwiczysz Production Debugging & Incident Response Playbook z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Production Debugging & Incident Response Playbook?

Nie wymagamy żadnego doświadczenia. Production Debugging & Incident Response Playbook w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Distributed tracing dla wąskich gardeł opóźnień”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Production Debugging & Incident Response Playbook?

Tak. Każda lekcja Production Debugging & Incident Response Playbook zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Zdalne debugowanie działających aplikacji
  2. Debugowanie po fakcie za pomocą zrzutów pamięci
  3. Techniki profilowania pamięci i procesora
  4. Distributed tracing dla wąskich gardeł opóźnień
← Powrót do Production Debugging & Incident Response Playbook