OpenTelemetry를 사용한 분산 추적

In a system spread across services and processes, one user request touches many components. Plain logs cannot show how they connect. Distributed tracing stitches the whole journey into one timeline.

A trace represents one end-to-end request. It is made of spans — timed units of work like a DB query or an HTTP call. Spans nest to form a tree.

OpenTelemetry (OTel) is a vendor-neutral standard for traces, metrics, and logs. Elixir has first-class support via the opentelemetry packages, exporting to Jaeger, Honeycomb, Datadog, and more.

Add the API, SDK, and an exporter to your deps.

The opentelemetry_phoenix package hooks into Telemetry events so each request becomes a trace automatically. Set it up in your application start.

For custom work, wrap it in a span with Tracer.with_span/2. It records start and end times automatically.

Attributes attach searchable context to a span, like the user id or order total.

When something fails, mark the span so it stands out in your tracing UI.

The magic of tracing is context propagation: the trace id travels with the request across service boundaries via HTTP headers, so spans from different services join the same trace.

Configure an exporter to ship spans to your observability backend over OTLP.

In a tracing UI you see a waterfall of spans. Long bars reveal slow steps; gaps reveal waiting. This pinpoints latency far faster than scanning logs.

You learned distributed tracing with OpenTelemetry:

• Traces are built from nested spans
• Auto-instrument Phoenix and Ecto via Telemetry
• Create manual spans with with_span and add attributes
• Record errors on spans for visibility
• Context propagation connects spans across services

Tracing turns multi-service requests into one readable timeline.