Skip to main content

Correlation and tracing

There is one id per user request.

  1. The client may send X-Request-Id. Kong accepts it when it matches [A-Za-z0-9._:-]{1,64}, otherwise Kong generates one.
  2. Kong echoes the header on the response.
  3. The service copies it to MDC traceId.
  4. ApiErrorResponse.traceId returns it to the client.
  5. Outbox insert copies it to trace_id. The relay puts it on IntegrationEventEnvelope.traceId.
  6. The consumer stores it on inbox_messages.trace_id and logs it again.

A failed push ten seconds later is still findable from the id the app showed the user.

Grafana dashboard Trace Explorer (splick-trace-explorer) and Logs (splick-logs). LogQL shape:

{service="auth-service"} | json | traceId="<id>"

Replace the service label with the process you mean. If the id appears at Kong and not in the service, the upstream never logged. If it appears in the service and not in the consumer, the outbox row was not relayed or the consumer group is stuck.

This is correlation, not a full OpenTelemetry trace tree. Spans are a later addition. Do not invent a second header.