How would you add a custom field (e.g. userId or tenantId) to every log line AND propagate it downstream alongside traceId? Contrast MDC vs baggage.

## MDC vs baggage — the core distinction ### MDC (Mapped Diagnostic Context) - A thread-local `Map<String,String>` in SLF4J/Logback. - You add fields yourself: `MDC.put("tenantId", t)` and print with `%X{tenantId}`. - **Scope**: local to the current thread and current process. It does **not** propagate to other threads (thread-local) or to other services (never serialized onto the wire by itself). - Correct usage is try-with-resources so you don't leak into pooled threads: ```java try (MDC.MDCCloseable c = MDC.putCloseable("tenantId", tenantId)) { log.info("processing"); // prints tenantId } // auto-removed ``` ### Baggage (Micrometer Tracing) - **Baggage** = arbitrary user-defined key/value pairs that are part of the *trace context* and are **propagated across service boundaries** in the same headers as the trace (W3C `baggage` header, or B3 with Brave). - Managed via the tracer's baggage API (`Tracer#createBaggageInScope` / `BaggageManager`), not `MDC.put`. - Configured declaratively in Spring Boot: - `management.tracing.baggage.remote-fields: tenantId,userId` — these keys are **propagated over the wire** to downstream services. - `management.tracing.baggage.correlation.fields: tenantId,userId` — these keys are **copied into MDC** so `%X{tenantId}` prints them in logs. - `management.tracing.baggage.enabled` (default true) toggles the feature. - Because it rides the trace context, baggage survives *both* thread hops (when context propagation is set up) *and* service hops (via headers). ## Recipe: userId/tenantId in every service's logs 1. Configure: ```yaml management: tracing: baggage: remote-fields: [tenantId, userId] correlation: fields: [tenantId, userId] ``` 2. Add the keys to your log pattern if you want them explicitly (or rely on structured logging emitting MDC): ```yaml logging: pattern: correlation: "[${spring.application.name:},%X{traceId:-},%X{spanId:-},%X{tenantId:-}] " ``` 3. Set the value once, early (e.g., an interceptor after auth), inside a scope: ```java try (BaggageInScope bag = tracer.createBaggageInScope("tenantId", tenantId)) { chain.doFilter(req, res); // downstream + logs now carry tenantId } ``` From here on, the current service's logs show `tenantId`, the value is injected into outgoing propagation headers, and each downstream service extracts it into its own MDC/logs. ## Gotchas and trade-offs - **Cost**: baggage is copied into *every* propagation header on *every* outbound call and into MDC on every log line. Large or numerous baggage fields inflate every request and log — keep it to a few small identifiers. - **Security**: baggage crosses trust boundaries in plain headers. **Never** put secrets, tokens, or PII you wouldn't expose to downstream services / logs. It's also attacker-influenceable if an untrusted client sets the header — validate/allowlist at the edge. - **MDC leaks**: if you `MDC.put` without removing (no try-with-resources), pooled threads carry the stale value into the next unrelated request. Baggage's scope objects avoid this when closed properly. - **Case/format**: baggage keys are case-sensitive strings; keep naming consistent across services or correlation.fields won't match. - **Propagation must be enabled** for cross-thread flow (see async propagation): baggage in MDC on a worker thread still requires context propagation to be set up. - **Not for high-cardinality bulk data**: baggage is for identifiers to correlate, not for shipping payloads. ## When to use which - **MDC only** — a value relevant to this service's logs and never needed elsewhere (e.g., an internal batch id computed locally). - **Baggage** — a value that must appear in logs/traces of *downstream* services too (tenantId, userId, requestId from the edge). Configure `remote-fields` (wire) + `correlation.fields` (MDC) and set it once at the boundary.