Menghubungkan Log dan Jejak

Traces show the request flow; logs show the details. Putting the traceId into every log line lets you jump from a trace to its exact logs - and vice versa.

MDC (Mapped Diagnostic Context) is a per-thread key/value map provided by SLF4J/Logback. Values placed in it can be printed in every log line by the layout pattern.

Micrometer Tracing automatically puts the current traceId and spanId into the MDC, so they are available to the logging framework without manual code.

Reference the MDC keys in your Logback pattern so each line carries the IDs.

Spring Boot can inject the IDs for you. Setting the application name enables the default correlation pattern that prepends [app,traceId,spanId] to logs.

The result looks like this - the bracketed IDs tie the line to a specific trace and span.

With IDs in logs, your log aggregator (ELK, Loki, etc.) can filter by traceId. Copy an id from Zipkin, paste it into the log search, and see every related log line.

You can also surface baggage (e.g. tenant id) in logs by mapping a baggage field into the MDC, enriching every line with business context.

The goal is bidirectional: from a slow span in Zipkin -> open its logs by traceId; from an error log -> open its trace in Zipkin. This dramatically speeds up debugging.

Because IDs come from MDC, they appear only when a trace is active. Background threads without a trace context show empty IDs (%X{traceId:-} renders blank) - which is expected.

For best results emit logs as JSON with traceId/spanId as proper fields, so log tools can index and link them reliably instead of parsing text.

You correlated logs and traces:

• Micrometer puts traceId/spanId into the MDC
• Reference them in the Logback pattern (or use Boot's default)
• Search logs by traceId to jump between traces and logs
• Prefer structured JSON logs for reliable indexing