NGINX / ingress
  -> JAX-RS request filter
  -> resource method
  -> service layer
  -> PostgreSQL via JDBC/MyBatis/JPA
  -> Redis
  -> Kafka/RabbitMQ publish
  -> downstream HTTP call
  -> background worker
  -> Camunda/workflow

Order submission failed
Database timeout
Message published
Retry scheduled

correlation_id=corr-abc trace_id=trace-123 order_id=O-91821 tenant_id=T-7 actor_id=A-44

Log ini milik request apa?
Log ini milik trace apa?
Log ini milik tenant/customer mana?
Log ini terkait actor/user mana?
Log ini terkait business entity apa?
Log ini terjadi pada operation apa?
Log ini bagian dari causal chain mana?

Request masuk
  -> filter membaca/generate correlation_id
  -> context dimasukkan ke MDC
  -> semua log di thread tersebut otomatis membawa field MDC
  -> request selesai
  -> MDC dibersihkan

{
  "timestamp": "2026-07-11T15:20:31.123Z",
  "level": "INFO",
  "service": "order-service",
  "event": "order.submission.completed",
  "message": "Order submission completed",
  "correlation_id": "corr-20260711-9918",
  "trace_id": "7f1d0b1c9f1e4b5d98c7",
  "span_id": "a93b12f9d441",
  "request_id": "req-771",
  "tenant_id": "tenant-123",
  "actor_id": "actor-456",
  "order_id": "O-91821"
}

import org.slf4j.MDC;

MDC.put("correlation_id", correlationId);
MDC.put("tenant_id", tenantId);
MDC.put("actor_id", actorId);

log.info("order submission started order_id={}", orderId);

MDC.clear();

%X{correlation_id} %X{tenant_id} %X{actor_id} %msg%n

{
  "correlation_id": "corr-abc",
  "tenant_id": "tenant-123",
  "actor_id": "actor-456",
  "message": "order submission started"
}

String tenantId = MDC.get("tenant_id");
repository.findOrders(tenantId);

OrderContext context = requestContext.getOrderContext();
repository.findOrders(context.tenantId());

Thread A MDC: correlation_id=corr-1
Thread B MDC: correlation_id=corr-2

Request 1 sets tenant_id=T1
Request 1 selesai tetapi MDC tidak clear
Request 2 diproses di thread yang sama
Request 2 log membawa tenant_id=T1 secara salah

Every MDC put at request/job boundary must have deterministic cleanup.

user_id       -> berguna, tetapi privacy-sensitive
customer_id   -> berguna, tetapi tenancy/commercial sensitive
tenant_id     -> berguna, tetapi high cardinality jika jadi metric label
order_id      -> berguna di log, buruk sebagai metric label
request_id    -> berguna di log, buruk sebagai metric label
session_id    -> sering sensitive; prefer hash atau jangan log
ip_address    -> privacy-sensitive; cek policy
authorization -> jangan log
cookie        -> jangan log

Context field boleh bagus untuk log query, tetapi belum tentu aman untuk metric label.

@Provider
@Priority(Priorities.AUTHENTICATION)
public class RequestContextFilter implements ContainerRequestFilter, ContainerResponseFilter {

    @Override
    public void filter(ContainerRequestContext requestContext) {
        String correlationId = getOrCreateCorrelationId(requestContext);
        String requestId = UUID.randomUUID().toString();

        MDC.put("correlation_id", correlationId);
        MDC.put("request_id", requestId);
        MDC.put("http_method", requestContext.getMethod());
        MDC.put("http_path", requestContext.getUriInfo().getPath());

        requestContext.setProperty("correlation_id", correlationId);
        requestContext.setProperty("request_id", requestId);
    }

    @Override
    public void filter(ContainerRequestContext requestContext,
                       ContainerResponseContext responseContext) {
        try {
            // optional response-end logging can happen here
        } finally {
            MDC.clear();
        }
    }
}

public class MdcServletFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request,
                         ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {
        try {
            setupMdc((HttpServletRequest) request);
            chain.doFilter(request, response);
        } finally {
            MDC.clear();
        }
    }
}

/orders/O-91821/items/123

/orders/{orderId}/items/{itemId}

[ ] Apakah ada JAX-RS/Servlet filter untuk setup MDC?
[ ] Apakah MDC cleanup dijamin dengan finally?
[ ] Apakah exception path tetap cleanup?
[ ] Apakah correlation_id dibuat jika header tidak ada?
[ ] Apakah incoming correlation_id divalidasi/sanitized?
[ ] Apakah request_id baru dibuat per request?
[ ] Apakah route template tersedia, bukan hanya raw path?
[ ] Apakah sensitive header/body tidak masuk MDC?

Incoming HTTP header
Generated at edge/gateway
Generated by application if missing
Propagated from message header
Generated by scheduler/job for job execution

X-Correlation-ID
X-Request-ID
traceparent

private String getOrCreateCorrelationId(ContainerRequestContext ctx) {
    String incoming = ctx.getHeaderString("X-Correlation-ID");
    if (isValidCorrelationId(incoming)) {
        return incoming;
    }
    return UUID.randomUUID().toString();
}

max length: 128
allowed chars: alphanumeric, dash, underscore, dot
no newline/control chars

correlation_id -> business/operational flow identifier, often propagated by app/gateway
tace_id        -> distributed tracing identifier, managed by tracing system

correlation_id=corr-abc
trace_id=7f1d0b1c9f1e4b5d98c7

{
  "level": "ERROR",
  "message": "dependency call failed",
  "trace_id": "7f1d0b1c9f1e4b5d98c7",
  "span_id": "a93b12f9d441",
  "correlation_id": "corr-8891"
}

Span currentSpan = Span.current();
SpanContext spanContext = currentSpan.getSpanContext();

if (spanContext.isValid()) {
    MDC.put("trace_id", spanContext.getTraceId());
    MDC.put("span_id", spanContext.getSpanId());
}

trace_id missing di log karena log bridge belum dikonfigurasi
trace_id berbeda dari correlation_id dan engineer bingung
span_id stale karena MDC tidak diperbarui ketika span berubah
manual MDC trace_id conflict dengan auto instrumentation

[ ] Apakah logs mengandung trace_id dan span_id?
[ ] Apakah trace_id bisa dipakai membuka trace backend?
[ ] Apakah correlation_id juga ada?
[ ] Apakah trace/span injection otomatis atau manual?
[ ] Apakah manual MDC tidak konflik dengan OTel log correlation?
[ ] Apakah async spans tetap muncul benar di log?

Tenant mana yang terdampak?
Apakah incident isolated ke tenant tertentu?
Apakah latency spike hanya terjadi pada tenant besar?
Apakah data/config tenant tertentu menyebabkan failure?

Siapa yang melakukan action?
Apakah action dilakukan user, system, integration, atau job?
Apakah actor punya permission?
Apakah ada impersonation/delegation?

MDC.put("user_email", user.email());
MDC.put("user_name", user.fullName());

MDC.put("actor_id", user.id());
MDC.put("actor_type", "user");

MDC.put("actor_hash", hash(user.id()));

[ ] Apakah tenant_id boleh masuk application log?
[ ] Apakah actor_id boleh masuk application log?
[ ] Apakah email/name dilarang atau dimasking?
[ ] Apakah service-to-service actor dibedakan dari human actor?
[ ] Apakah impersonation/delegation context tersedia?
[ ] Apakah tenant_id tidak dipakai sembarangan sebagai metric label?

quote_id
order_id
customer/account id jika allowed
process_instance_id
approval_id
fulfillment_request_id
fallout_id
amendment_id
cancellation_id
reconciliation_batch_id

{"business_key": "O-91821"}

{"order_id": "O-91821"}

MDC.put("order_id", orderId);
log.info("order submission started");

try (MdcScope ignored = MdcScope.put("order_id", orderId)) {
    log.info("order validation started");
    validate(order);
}

[ ] Apakah quote_id/order_id masuk log pada lifecycle event penting?
[ ] Apakah business key tidak bocor antar entity dalam thread yang sama?
[ ] Apakah business key policy sesuai privacy/security requirement?
[ ] Apakah process_instance_id tersedia untuk workflow debugging?
[ ] Apakah event_id/message_id tersedia untuk messaging debugging?
[ ] Apakah idempotency_key boleh masuk log atau harus di-hash?

If you set MDC at a boundary, you must clear/restore MDC at the same boundary.

try {
    setupMdc(request);
    chain.doFilter(request, response);
} finally {
    MDC.clear();
}

String previous = MDC.get("order_id");
try {
    MDC.put("order_id", orderId);
    processOrder(orderId);
} finally {
    if (previous == null) {
        MDC.remove("order_id");
    } else {
        MDC.put("order_id", previous);
    }
}

public final class MdcScope implements AutoCloseable {
    private final String key;
    private final String previous;

    private MdcScope(String key, String value) {
        this.key = key;
        this.previous = MDC.get(key);
        MDC.put(key, value);
    }

    public static MdcScope put(String key, String value) {
        return new MdcScope(key, value);
    }

    @Override
    public void close() {
        if (previous == null) {
            MDC.remove(key);
        } else {
            MDC.put(key, previous);
        }
    }
}

try (MdcScope ignored = MdcScope.put("order_id", orderId)) {
    log.info("order enrichment started");
}

[ ] Apakah MDC.clear() dipanggil di finally pada boundary request/job/message?
[ ] Apakah temporary MDC fields di-restore, bukan hanya ditimpa?
[ ] Apakah test membuktikan context tidak bocor antar request?
[ ] Apakah exception path tetap cleanup?
[ ] Apakah framework async behavior tidak melewati cleanup?

MDC.put("correlation_id", correlationId);

CompletableFuture.runAsync(() -> {
    log.info("async work started"); // correlation_id mungkin hilang
});

public class MdcPropagatingRunnable implements Runnable {
    private final Runnable delegate;
    private final Map<String, String> contextMap;

    public MdcPropagatingRunnable(Runnable delegate) {
        this.delegate = delegate;
        this.contextMap = MDC.getCopyOfContextMap();
    }

    @Override
    public void run() {
        Map<String, String> previous = MDC.getCopyOfContextMap();
        try {
            if (contextMap != null) {
                MDC.setContextMap(contextMap);
            } else {
                MDC.clear();
            }
            delegate.run();
        } finally {
            if (previous != null) {
                MDC.setContextMap(previous);
            } else {
                MDC.clear();
            }
        }
    }
}

executor.submit(new MdcPropagatingRunnable(() -> {
    log.info("async enrichment completed");
}));

[ ] Apakah CompletableFuture/task executor mempertahankan MDC?
[ ] Apakah executor wrapper digunakan konsisten?
[ ] Apakah OTel context juga ikut, bukan hanya MDC?
[ ] Apakah cleanup terjadi di worker thread?
[ ] Apakah async task punya correlation_id saat log?
[ ] Apakah context lama tidak bocor dari worker thread pool?

Task A set correlation_id=corr-A
Task A selesai tanpa cleanup
Task B jalan di thread sama
Task B log membawa corr-A

String jobRunId = UUID.randomUUID().toString();
MDC.put("correlation_id", "job-" + jobRunId);
MDC.put("job_name", "order-reconciliation");
MDC.put("job_run_id", jobRunId);

[ ] Apakah semua custom executor punya MDC/OTel propagation strategy?
[ ] Apakah scheduled jobs membuat context baru?
[ ] Apakah job_run_id tersedia?
[ ] Apakah worker thread cleanup selalu terjadi?
[ ] Apakah ada test concurrent untuk context leak?

[ ] Apakah aplikasi memakai virtual threads?
[ ] Apakah logging framework/MDC compatible dengan mode tersebut?
[ ] Apakah MDC hanya berisi string kecil?
[ ] Apakah cleanup tetap dilakukan?
[ ] Apakah context propagation behavior sudah diuji?

Satu logical request bisa berpindah antar thread.
Satu thread bisa memproses banyak logical request.
ThreadLocal tidak mewakili logical context.

Reactive Context -> MDC only during log emission -> clear immediately

[ ] Apakah service menggunakan async JAX-RS response?
[ ] Apakah streaming response digunakan?
[ ] Apakah reactive library digunakan?
[ ] Apakah MDC tetap benar setelah thread switch?
[ ] Apakah context bridge tersedia?
[ ] Apakah trace context lebih reliable daripada MDC manual?

Read MDC/context
Add correlation_id to message headers
Add traceparent if tracing enabled
Add causation/event id if convention exists
Log publish outcome

headers.add("correlation_id", MDC.get("correlation_id"));
headers.add("traceparent", currentTraceParent());
headers.add("event_id", eventId);

Read correlation_id from message header
Create new request/message processing context
Put correlation_id/event_id/message_id/topic/queue into MDC
Process message
Cleanup MDC

try {
    MDC.put("correlation_id", headerCorrelationId(message));
    MDC.put("event_id", message.eventId());
    MDC.put("message_source", topic);

    log.info("message processing started event_id={} event_type={}",
            message.eventId(),
            message.eventType());

    process(message);
} finally {
    MDC.clear();
}

attempt
redelivery_count
dlq_topic/dlq_queue
consumer_group
partition
offset
queue
routing_key

[ ] Apakah Kafka/RabbitMQ producer menulis correlation_id header?
[ ] Apakah traceparent propagated di headers?
[ ] Apakah consumer membuat MDC dari message headers?
[ ] Apakah consumer cleanup MDC setelah setiap message?
[ ] Apakah batch consumer tidak mencampur context antar message?
[ ] Apakah DLQ logs membawa original correlation_id/event_id?
[ ] Apakah message header convention diverifikasi internal?

correlation_id/job_run_id
job_name
job_type
scheduler_name
batch_id
reconciliation_id
trigger_type
triggered_by
attempt

public void runReconciliationJob() {
    String jobRunId = UUID.randomUUID().toString();
    try {
        MDC.put("correlation_id", "job-" + jobRunId);
        MDC.put("job_name", "order-reconciliation");
        MDC.put("job_run_id", jobRunId);

        log.info("background job started");
        reconciliationService.run(jobRunId);
        log.info("background job completed");
    } catch (Exception ex) {
        log.error("background job failed", ex);
        throw ex;
    } finally {
        MDC.clear();
    }
}

pod_name
namespace
cronjob_name
job_name
image_version

[ ] Apakah setiap job run punya job_run_id?
[ ] Apakah job logs bisa dikelompokkan per execution?
[ ] Apakah batch/reconciliation ID tersedia?
[ ] Apakah job failure log membawa context cukup?
[ ] Apakah Kubernetes CronJob metadata masuk logs/resource attributes?
[ ] Apakah cleanup dilakukan setelah job selesai/gagal?

MDC is for local logging context.
Baggage is for explicit cross-service context propagation.

[ ] Apakah baggage digunakan?
[ ] Field apa yang boleh masuk baggage?
[ ] Apakah tenant/actor propagation punya policy?
[ ] Apakah baggage size dibatasi?
[ ] Apakah baggage tidak menjadi channel data sensitif?
[ ] Apakah MDC dan baggage tidak dicampur otomatis tanpa review?

Allowed from external client:
- correlation/request ID, after validation

Must come from trusted auth/session/service context:
- actor_id
- tenant_id
- role
- permissions
- impersonation context

MDC.put("tenant_id", request.getHeader("X-Tenant-ID"));

TenantContext tenant = authenticatedContext.resolveTenant();
MDC.put("tenant_id", tenant.id());

[ ] Apakah incoming correlation_id divalidasi?
[ ] Apakah tenant_id tidak dipercaya dari untrusted header?
[ ] Apakah actor_id berasal dari authenticated principal?
[ ] Apakah internal headers dibersihkan/ditimpa di edge/gateway?
[ ] Apakah log injection via newline/control chars dicegah?
[ ] Apakah spoofed traceparent/correlation behavior disepakati?

correlation_id = "abc\nERROR fake log"

private boolean isValidContextValue(String value) {
    if (value == null || value.length() > 128) {
        return false;
    }
    return value.matches("[A-Za-z0-9._:-]+"); // example only; verify against internal standard
}

correlation_id
trace_id
span_id
request_id
tenant_id
actor_id
operation
route
quote_id
order_id
job_run_id
event_id

Application code sets MDC
Logging framework includes MDC in layout/encoder
Log collector preserves JSON fields
Backend indexes fields as expected
Dashboard/query uses those fields

MDC ada di local console pattern, tetapi tidak ada di JSON production output.
MDC fields nested sebagai map tetapi backend tidak index nested field.
MDC field name berbeda antara services.
trace_id muncul sebagai traceId di satu service dan trace_id di service lain.

[ ] Apakah MDC fields muncul di JSON production log?
[ ] Apakah field names konsisten snake_case/camelCase sesuai standard?
[ ] Apakah log collector mempertahankan fields?
[ ] Apakah backend mengindex correlation_id/trace_id?
[ ] Apakah query contoh berhasil menemukan semua log satu request?
[ ] Apakah field name sama antar services?

@Test
void filterClearsMdcAfterRequest() {
    filter.doFilter(request, response, chain);
    assertThat(MDC.getCopyOfContextMap()).isNullOrEmpty();
}

Send HTTP request with X-Correlation-ID=corr-test-1
Call endpoint that logs service-layer event
Assert captured logs contain correlation_id=corr-test-1
Assert response propagates correlation_id if expected

Set correlation_id
Submit async task
Assert async task log contains same correlation_id
Assert next task does not inherit stale context

Publish event with correlation_id header
Consumer processes event
Assert consumer log contains same correlation_id and event_id

[ ] Apakah ada test untuk request MDC setup?
[ ] Apakah ada test untuk MDC cleanup?
[ ] Apakah ada test untuk async propagation?
[ ] Apakah ada test untuk messaging header propagation?
[ ] Apakah ada test bahwa sensitive headers tidak masuk MDC?
[ ] Apakah captured structured logs bisa diassert?

Log ada, tetapi tidak bisa dikelompokkan per request/incident.

query logs where correlation_id missing by service/endpoint/version

Request tenant A muncul dengan tenant_id B.
Correlation ID tidak cocok dengan access log.

concurrent tests
impossible tenant/request combinations
logs after request completed still carry old context

logs with correlation_id but trace_id missing
trace backend has trace but logs cannot link

unexpected tenant_id from external traffic
invalid chars/long values in correlation_id
security review findings

1. Tentukan log berasal dari request, async task, message consumer, atau job.
2. Cek apakah boundary tersebut punya context setup.
3. Cek apakah log terjadi sebelum setup atau setelah cleanup.
4. Cek apakah execution pindah thread.
5. Cek apakah MDC di-set tetapi encoder tidak mengeluarkan field.
6. Cek apakah collector/backend menghapus atau rename field.
7. Cek apakah field name berbeda dari query.
8. Cek recent deployment/config change.

- cek Servlet/JAX-RS filter ordering
- cek ExceptionMapper path
- cek async response path
- cek dependency injection lifecycle
- cek logs saat startup vs request runtime

- cek producer headers
- cek broker/header preservation
- cek consumer extraction
- cek batch processing
- cek retry/DLQ propagation

A log event must never claim to belong to a request/tenant/actor/business entity that it does not belong to.

batch_id at job level
order_id only when processing individual order scope

MDC field should be small, stable, and few.

[ ] Berapa jumlah field MDC default?
[ ] Apakah value MDC pendek?
[ ] Apakah context map dicopy di high-frequency task?
[ ] Apakah executor propagation overhead pernah diuji?
[ ] Apakah logging allocation terlihat di profiler?

Authorization header
Cookie
session token
password
API key
raw request body
raw SQL parameter
credit/payment data
email/name jika policy melarang
IP address jika policy butuh masking dan belum dimasking

[ ] Apakah daftar allowed MDC fields terdokumentasi?
[ ] Apakah sensitive headers tidak masuk MDC?
[ ] Apakah tenant/actor policy disetujui security/privacy?
[ ] Apakah field high sensitivity di-hash/mask?
[ ] Apakah baggage tidak membawa PII?
[ ] Apakah log access control sesuai sensitivitas context?

correlation_id -> almost always worth it
trace_id/span_id -> worth it for log-trace correlation
tenant_id -> useful but policy/cardinality sensitive
actor_id -> useful but privacy sensitive
order_id/quote_id -> useful on business events, not necessarily every low-level log
large custom metadata -> usually not worth it

Global MDC: request/trace/correlation/tenant/actor basics.
Event-specific fields: order_id, quote_id, dependency, error_code, attempt, latency.

[ ] Apakah context field yang ditambahkan benar-benar dibutuhkan?
[ ] Apakah field aman dari sisi privacy/security?
[ ] Apakah field value divalidasi dan dibatasi panjangnya?
[ ] Apakah field cocok sebagai global MDC atau event-specific field?
[ ] Apakah setup terjadi di boundary yang tepat?
[ ] Apakah cleanup dilakukan di finally?
[ ] Apakah temporary field di-restore setelah scope selesai?
[ ] Apakah async/thread pool propagation ditangani?
[ ] Apakah messaging producer menulis context ke header?
[ ] Apakah messaging consumer membaca context dari header?
[ ] Apakah background job membuat context baru?
[ ] Apakah trace_id/span_id konsisten dengan OpenTelemetry?
[ ] Apakah log encoder benar-benar mengeluarkan MDC field?
[ ] Apakah tests mencakup cleanup dan propagation?
[ ] Apakah field tidak akan menyebabkan log cost tidak perlu?

[ ] Apa header correlation ID standar internal?
[ ] Apakah request ID dan correlation ID dibedakan?
[ ] Apakah traceparent digunakan?
[ ] Apakah logs memiliki trace_id/span_id?
[ ] Apakah MDC setup dilakukan di Servlet filter, JAX-RS filter, atau framework lain?
[ ] Apakah cleanup dijamin di finally?
[ ] Apakah ExceptionMapper path mempertahankan context?
[ ] Apakah executor/CompletableFuture/context async memakai propagation wrapper?
[ ] Apakah Kafka/RabbitMQ headers membawa correlation_id/traceparent?
[ ] Apakah consumer cleanup context per message?
[ ] Apakah background jobs punya job_run_id/correlation_id?
[ ] Apakah tenant_id/actor_id allowed di logs?
[ ] Apakah email/name/session/token dilarang di MDC?
[ ] Apakah route template tersedia di logs?
[ ] Apakah log collector/backend mengindex correlation_id dan trace_id?
[ ] Apakah ada test untuk context leak antar request?
[ ] Apakah incident notes pernah menyebut missing correlation ID?
[ ] Apakah dashboard/log query menggunakan field context yang konsisten?

context loss
context leak
wrong tenant/actor attribution
async propagation failure
privacy leakage
cost increase
conflict with tracing instrumentation

Every important log must be attributable to the correct request, trace, tenant, actor, business entity, job, or message flow.

No context may leak across unrelated execution scopes.