The signals
Traces, metrics, logs, baggage, context propagation across Kafka, profiling, and the semantic conventions that keep them all readable — one signal per chapter, three stacks each.
Traces: auto-instrumentation
One POST /orders request, three ways to get its first end-to-end trace with zero application code: a Java agent, a build-time extension, and a zero-code launcher.
Traces: manual spans
Wrapping the inventory and payment retry loops in spans of their own — the attempt count, the failure reason, and the business status auto-instrumentation can't see.
Metrics
A custom orders_placed_total counter and a fulfillment-duration histogram, two bridge mechanisms getting them from Micrometer to OTLP, and the exemplar that links a histogram bucket straight to its trace.
Logs
Structured logs carrying trace_id and span_id into Loki, and the one resource attribute all four signals must agree on for correlation to work.
Baggage
Propagating business context such as cart.id across service boundaries with W3C Baggage, reading it back as a span attribute, and the cardinality cost of getting that wrong.
Context propagation across Kafka
Why auto-instrumentation does not reliably carry W3C trace context across a Kafka hop, and the PROPAGATE_KAFKA_CONTEXT toggle that contrasts a continued trace against a broken one.
Profiling
Continuous profiling as a runtime signal: attaching the Grafana Pyroscope agent or SDK in each stack, the Quarkus LogManager ordering gotcha, and where OTLP profiles fit in.
Semantic conventions
Resource attributes, HTTP/DB/messaging conventions, and why consistent naming is what makes traces, metrics, logs, and profiles correlate at all.