A citizen portal UI calls a back-end that then invokes the Meraki API. On-call staff cannot join those hops when troubleshooting. Which logging-design choice fixes that?
Select an answer to reveal the explanation.
Short Explanation
A correlation id is the claim ticket that follows a package from counter to truck to door. Without it, UI, back-end, and Meraki attempts are three strangers in the log pile.
Full Explanation
A single correlation or request id stamped on every hop the application owns lets operators join UI, back-end, and outbound Meraki or DNA Center calls into one trace. When a citizen-facing action fails mid-path, that id is the join key across otherwise unrelated log lines and metrics, which shortens mean time to isolate the failing hop. Emitting isolated per-process lines with no shared identifier leaves three disconnected piles and forces brittle wall-clock guessing across replicas under load. Disabling back-end logging whenever the Meraki call succeeds removes the evidence needed to prove which hop worked and hides partial failures in adjacent components that still affect the citizen outcome. Relying only on wall-clock ordering without a request-scoped stamp breaks under concurrency, batching, and clock skew between nodes. Exam caveat: propagate the id into outbound HTTP headers and partner-facing logs where you control the client, but never embed secrets or raw personal data inside the correlation value itself. Operational check: drive one end-to-end municipal request, capture the correlation id at the edge, and confirm the same id appears in API logs and in the outbound integration attempt records for that transaction.