How to store a Correlation ID (X-Correlation-ID) in the application that is responsible for generating it

user_5135929 0
Viewed 6232

I'm implementing a correlation ID within my applications and would like some feedback on the design for it. The primary concern is that the correlation ID should be available for all logs.

Lets say I have a web (front-end) application which is serving pages to my users. It talks with two API's which provide data. The API's are not exposed to the user, and so all requests 'begin' in the front-end app.

The API's job is simple, they consume the correlation ID as provided in all headers from the front-end app (X-Correlation-ID) and print it in any logs.

The front-end app has to generate the ID, add it to the headers for outgoing requests, but it must also consume the ID.

My question is this: How does the front-end app store the correlation ID? My first thought was that it would modify the incoming request and add the header if it did not exist, however this would make the incoming request somewhat 'unreliable' as it is now modified. Another thought is perhaps it is stored as some kind of application global that is cleared per request.

soa request http-headers
2 Answers

Correlation ids i.e. ids typically attached to headers like Request-ID, X-Request-ID, X-Trace-ID, X-Correlation-ID are typically issued per request.

You seem to want to store it locally on the client though. What you describe sounds more like a “session id” that gets reset when the client “restarts”. If that is the case, then you simply use local/session storage or cookies to store and clear it when needed.

Do keep in mind that first sentence above though. Correlation ids are typically used per request. What I usually do:

  1. Generate an id on the client per request
  2. Pass it to the API via one of the aforementioned headers
  3. Whoever gets the request first (some API gateway, HA Proxy etc) checks for the existence of the header and proxies it further downstream. So do any services calling other services. This is usually provided as a service:tool to most services/teams so that they don’t forget to do it.
  4. Profit?

That’s what heroku does for example. Same for many other services / companies.

Goes without saying, you can combine the two ids, the “session” one you refer to plus the ones generated per request to get a better view of what is going on in logs etc

user_9899910

As per my design, I'd suggest to always check (intercept using middlewares/filters on backend) each request from the client at the first point of contact at the backend (load balancer/ gateway / controller) and check for the Trace-ID/Correlation-ID at the request header, if present then forward the request as it is, if not present (because this is the first call from that new client), then generate the random ID (as Trace-ID) and attach that newly generated random ID to the Request Header and reroute/pass on the request further down the application. One more thing, while sending back the response, make sure to again add this ID generated earlier to the Response Header, so that the client can receive this unqiue ID and save it on localstorage/cookie for further calls so that the client could easily be traced using that trace ID.

As you requested for logs, now since you have that correlation ID/trace ID, you can log them anywhere you want and you can easily determine the complete flow of the client's request in case of any issues using this unique ID.

Steps:

  1. Check for the Correlation ID in the Request Header (at Backend)
  2. If already present, allow the request to pass through to the required service. If not present, generate a unique random ID and add a custom Header in the Request Header.
  3. Again, before sending the response, again add this custom Header to the Response header for client.

I hope that answers your query.

user_49458700
Related