The crew of viewer 1, with the IDs a trace is made of. We open a span, start one inside another, filter the logs by trace ID, and follow a failed search from Jaeger to its log lines.
Trace terms in this viewer
- Trace: one run of the crew. Its trace ID is 16 random bytes, written as 32 hex digits.
- Span: one piece of work in the run, with a name, a start, a duration and attributes.
- Its span ID is 8 random bytes; its parent span ID is the span it ran inside.
- The root span has no parent.
- Context: where the program keeps the current span. A new span and a log line take their IDs from it.
- Status: a span that failed is marked
ERROR, and
Jaeger finds it with error=true.
OpenTelemetry and Jaeger
A trace is OpenTelemetry's; Jaeger is one place to store and read it.
- OpenTelemetry: the open standard for traces, metrics and logs.
- Its SDK runs inside our service: it makes the spans and gives them their IDs.
- It sends each finished span out in OpenTelemetry's format, OTLP.
- Jaeger: a separate program that receives the spans, stores them and shows them.
- It joins the spans that share a trace ID into one trace.
- Its UI is what this viewer draws: the search, and a trace's time line.
- It is open source, started at Uber, and a CNCF project. Grafana Tempo does the same job.
Reading the drawing
- The crew, top: as in viewer 1. In scene 2, its bottom row shows each run's current span.
- Logs, bottom left: each line carries
trace_id and span_id. - Traces, bottom right: Jaeger's search over one trace.
- A dot is one trace: when it started, and how long it took.
- The colored chips are span IDs; the dashed chip after each is its parent's ID.
- A click on a span opens it and lights its log lines; a click on a trace or a trace ID shows that trace.
- Gaps, the bottom row: viewer 1's gaps; this viewer fills the logs' gap.