Production Debugging & Incident Response Playbook · レッスン

レイテンシーのボトルネックを見つける分散トレーシング

分散トレーシングで1つのリクエストをサービス間で追跡し、レイテンシーのボトルネックを特定し、本番デバッグ中にトレースとログを関連付ける方法を学びます。

レッスン 4/413 ステップ

「レイテンシーのボトルネックを見つける分散トレーシング」はCoddyKit上の無料Production Debugging & Incident Response Playbookレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これは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_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.

対話的なレッスンで答える

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

無料で開始

AI チューターと学ぶ Production Debugging & Incident Response Playbook — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 12
レッスン: 48

無料で学習を始めるコース全体を表示

よくある質問

「レイテンシーのボトルネックを見つける分散トレーシング」レッスンは無料ですか？

はい。「レイテンシーのボトルネックを見つける分散トレーシング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Production Debugging & Incident Response Playbookコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Production Debugging & Incident Response Playbookコースには全4レッスンが含まれています。

「レイテンシーのボトルネックを見つける分散トレーシング」で何を学びますか？

分散トレーシングで1つのリクエストをサービス間で追跡し、レイテンシーのボトルネックを特定し、本番デバッグ中にトレースとログを関連付ける方法を学びます。ブラウザで直接実行するハンズオンコードでProduction Debugging & Incident Response Playbookを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Production Debugging & Incident Response Playbookを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのProduction Debugging & Incident Response Playbookは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「レイテンシーのボトルネックを見つける分散トレーシング」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このProduction Debugging & Incident Response Playbookレッスンでコードを書いて実行できますか？

はい。すべてのProduction Debugging & Incident Response Playbookレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Production Debugging & Incident Response Playbookに戻る