Watch a Trace Join and Break

This lab runs on real OpenTelemetry

Inside the VM, an OTel Collector, Jaeger, and two services that call each other are actually running. Requests flow, spans are created, pass through the Collector, and accumulate in Jaeger.

The tracing labs in the earlier module ran on a fake cluster. Because no requests flowed, the phenomenon of propagation breaking never happened at all. Even though that is the spot OTCA asks about most.

You do not install an SDK. The services build OTLP/HTTP directly with the standard library. Since what OTCA asks about is the shape of traceparent and the form of OTLP, building them by hand is actually closer to the exam scope.

It takes about 4 minutes to come up the first time.

What is prepared

frontend   http://127.0.0.1:30080   backend 를 부릅니다
backend    obs 네임스페이스 안
컬렉터     설정은 /etc/otelcol/config.yaml
Jaeger     http://127.0.0.1:30686
질의 도구  traces frontend

The Korean text in this code block says, in order, that frontend calls backend, that backend runs inside the obs namespace, that the Collector configuration is at the path shown, and that the query tool is used as traces frontend.

Steps

1. Send one request through and capture how the spans connect in /root/otca/flow.txt.
2. Dissect traceparent and capture it in /root/otca/traceparent.txt.
3. Confirm what was sent over OTLP and capture it in /root/otca/otlp.txt.
4. Add processors to the Collector pipeline and capture in /root/otca/pipeline.txt that the order is the processing order.
5. Break propagation and capture in /root/otca/broken.txt that the trace splits in two.
6. Capture the resource attributes and semantic conventions in /root/otca/semconv.txt.
7. Apply sampling and capture in /root/otca/sampling.txt what gets discarded.
8. In /root/otca/report.md, write the three lines services=, broken_traces=, and pipeline_order=, plus an explanation.

Notes

• Use traces frontend to see recent traces. Try filtering with | jq.
• After editing the Collector configuration, apply it with apply_col. The Collector has no way to reload its configuration, so a new Pod is started.
• Common mistake: spans arrive but do not show up on the screen. Check the timestamp. If you put in a small number, it is indexed as 1970.
• Common mistake: not giving the Jaeger query API a time range. An empty result comes back.

What a single request leaves behind

Send one request through and capture how the spans connect in /root/otca/flow.txt.

Compare the traceId in the response across the two services.

The shape of one header line

Dissect traceparent and capture it in /root/otca/traceparent.txt.

It is four segments in the form 00-<32자리>-<16자리>-<2자리> (the placeholders are digit counts: 32, 16, and 2 digits).

OTLP is a protocol, not a store

Confirm what was sent over OTLP and capture it in /root/otca/otlp.txt.

The Collector's debug exporter log prints the number of spans received.

Processor order is processing order

Add processors to the Collector pipeline and capture in /root/otca/pipeline.txt that the order is the processing order.

memory_limiter is first and batch is last. Think about why.

What you see when propagation breaks

Break propagation and capture in /root/otca/broken.txt that the trace splits in two.

Both spans remain. They just do not connect into one.

Why you must not name things freely

Capture the resource attributes and semantic conventions in /root/otca/semconv.txt.

service.name is a resource attribute, and http.request.method is a span attribute.

What will you discard?

Apply sampling and capture in /root/otca/sampling.txt what gets discarded.

Head decides at the very front and cannot be undone. Tail gathers everything and chooses later.

What did you learn?

In /root/otca/report.md, write the three lines services=, broken_traces=, and pipeline_order=, plus an explanation.

Write the three lines services=, broken_traces=, and pipeline_order=, plus an explanation.