Распределённая трассировка узких мест задержки
Научитесь использовать распределённую трассировку, чтобы отслеживать один запрос через несколько сервисов, находить узкие места по задержке и сопоставлять трассировки с журналами при отладке рабочей системы.
«Распределённая трассировка узких мест задержки» — бесплатный урок Production Debugging & Incident Response Playbook на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Production Debugging & Incident Response Playbook, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Production Debugging & Incident Response Playbook содержит 4 уроков всего.
Части этого урока еще не переведены и отображаются на английском.
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_idlinks all spans of one requestspan_ididentifies the operationparent_idrecords 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-01Instrumenting 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.
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
Часто задаваемые вопросы
Урок «Распределённая трассировка узких мест задержки» бесплатный?
Да — полный текст урока «Распределённая трассировка узких мест задержки» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Production Debugging & Incident Response Playbook, подпишись на CoddyKit PRO. Курс Production Debugging & Incident Response Playbook содержит 4 уроков всего.
Чему я научусь в уроке «Распределённая трассировка узких мест задержки»?
Научитесь использовать распределённую трассировку, чтобы отслеживать один запрос через несколько сервисов, находить узкие места по задержке и сопоставлять трассировки с журналами при отладке рабочей… Ты практикуешь Production Debugging & Incident Response Playbook с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Production Debugging & Incident Response Playbook?
Предыдущий опыт не требуется. Production Debugging & Incident Response Playbook на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Распределённая трассировка узких мест задержки»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Production Debugging & Incident Response Playbook?
Да. Каждый урок Production Debugging & Incident Response Playbook включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Удаленная отладка работающих приложений
- Посмертная отладка с помощью дампов памяти
- Методы профилирования памяти и CPU
- Распределённая трассировка узких мест задержки