Correlation IDs: Following One Request or Job Across Log Lines

Graylog

Chapter 4 · Correlation IDs: Following One Request or Job Across Log Lines

A single real user action — one API call, one Flux sync, one job run — almost never produces just one log line. It produces a scattered trail across several services, each logging its own small piece of the story. Correlation IDs are what let you pull that scattered trail back together into one coherent sequence, and different fields correlate at genuinely different scopes.

requestId, restRequestId & messageRequestId — One HTTP Request

These three fields all serve the same real purpose: correlating every log line produced while handling one single HTTP request, regardless of how many internal steps that request triggers. Which specific name shows up depends on which part of the stack wrote the log line.

The core real workflow

Once you've found one relevant log line — say, from a candidate-facing error message — copy its requestId and search on that alone:

requestId:"<id from a candidate message>"

This surfaces every other log line tied to that exact same request, across whichever services touched it — often the fastest real way to go from "one confusing error" to "the full sequence of what actually happened."

correlationId — Cross-Service Job Correlation

correlationId operates one level up from a single HTTP request — it correlates one item or job as it moves through cross-service steps, the real example being a Flux pipeline run that touches several distinct services in sequence. Where requestId ties together the log lines from one request, correlationId ties together the log lines from one whole multi-step job, potentially spanning several requests.

sessionId — User/Session Flow

sessionId correlates at a different scope again — a user's own session, potentially spanning multiple separate requests over time as they interact with a system.

inputId — One Flux Sync Run

inputId is Flux-specific, identifying one particular sync run.

jobRunId — The Scheduler's Own ID

jobRunId is used by the scheduler service specifically.

jobRunId gets forwarded downstream as requestId

A job that originates in the scheduler doesn't keep its own jobRunId name as it propagates into the rest of the system — it's forwarded downstream and shows up there under the name requestId instead. If you're tracing a scheduler-originated job and it seems to "disappear" after the scheduler's own log lines, search for the same ID value under requestId rather than assuming the trail has genuinely gone cold.

Field	Correlates
requestId / restRequestId / messageRequestId	One HTTP request, across every service that touches it
correlationId	One item/job across cross-service steps (e.g. Flux)
sessionId	One user/session flow
inputId	One Flux sync run
jobRunId	One scheduler job — forwarded downstream as requestId

Hands-On Exercises

Exercise 1

You've found one log line for a scheduler job with jobRunId:abc123, but a follow-up search for jobRunId:abc123 only returns that one line, even though you know the job triggered further downstream processing. Using this chapter's own material, explain what to search for next.

📄 View solution

Exercise 2

Explain, using this chapter's own material, the real difference in scope between requestId and correlationId — which one is broader, and what real example does this chapter give for when the broader one is actually needed?

📄 View solution

Exercise 3

Write a query, using this chapter's own real syntax, that finds every log line associated with the request ID 7f2a-91bc.

📄 View solution

Chapter 4 Quick Reference

requestId / restRequestId / messageRequestId — one HTTP request, across services
correlationId — one item/job across cross-service steps (e.g. Flux)
sessionId — one user/session flow
inputId — one Flux sync run
jobRunId — scheduler-specific; forwarded downstream as requestId — search there if the trail seems to end
Next chapter: The HTTP/Koa/Express Field Shape