Skip to content
Optimal Lab

DevOps · interactive

Distributed tracing with OpenTelemetry

One click on Checkout passes through a gateway, auth, the checkout service, a database, a payments service and an external API. A trace records each step as a span with a start time and duration, all sharing one trace id, so you can see where the time went.

trace 4bf92f35… · 7 spans · 147 ms

  • gateway GET /checkout
  • auth verify token
  • checkout load cart
  • postgres SELECT … WHERE id IN (…)
  • payments charge card
  • stripe (external) POST /charges
  • kafka publish OrderPlaced

147 ms end to end. Most of it is the external card charge, which is expected.

Scenario

Step 1 of 4

  1. 1

    Spans nest into a trace

    Each operation is a span with a parent. Together they form a tree for one request.

    Attributes add context: user, route, SQL.

  2. 2

    Context travels with calls

    The trace id rides along in a traceparent header, so spans from different services join up.

    traceparent: 00-4bf92f35…-00f067aa…-01

  3. 3

    Find the long bar

    Waterfalls show slow dependencies, sequential calls that could be parallel, and N+1 queries.

    Link traces to logs by trace id.

  4. 4

    OpenTelemetry is vendor-neutral

    Instrument once with OTel SDKs (much is automatic), then export to Jaeger, Tempo, Honeycomb or Datadog.

    Sample to control volume.

In production

Tools and technologies

OpenTelemetry is the standard for instrumentation.

Not tied to one language — use these names when you search docs or design a system.