# Per-Request Unique Identifier (Log Correlation)

**URL:** <https://www.ruby-forum.com/t/per-request-unique-identifier-log-correlation/198678>\
**Category:** NGINX\
**Created:** [November 5, 2010, 7:33am UTC](https://www.ruby-forum.com/t/per-request-unique-identifier-log-correlation/198678 "2010-11-05T07:33:19Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![okkezSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/85f322/32.png) [@okkezSS](https://www.ruby-forum.com/u/okkezSS)\
**Post date:** [November 5, 2010, 7:33am UTC](https://www.ruby-forum.com/t/per-request-unique-identifier-log-correlation/198678/1 "2010-11-05T07:33:19Z")

</div>

There is information available to log by the fastcgi backend which is  
not available to nginx, and vice versa (e.g., $body\_bytes\_sent). I need  
some way to match these two logs together after the fact. This  
necessarily implies a quasi-GUID guaranteed to be unique to each  
request. Preferably it should be something generated by nginx and fed  
to backend through a fastcgi\_param (or for those using proxy, through a  
request header).

One idea is to combine these:

(a) nginx worker $pid  
(b) a timestamp (\<=1s res.)  
(c) a request counter internal to each nginx worker process.

Together, these _should_ together fulfill all the foregoing requirements  
in real-world practice. (Information leakage is not a concern, since  
this will only be used internally. Efficiency is obviously paramount.)  
However as far as I can tell, there is no such thing as (c), nor  
anything else which can be used to uniquely identify each request.

(Yes there is other stuff which should be added to _theoretically_  
guarantee uniqueness. I am aware of the difficulty of finding a  
portable high-performance solution for that, e.g. from maildir  
discussions.)

Any chance to get a monotonically increasing counter of requests since  
worker process start? I am guessing this would take about 6 lines of  
code; but like the old legend about Tesla, the trick is knowing where to  
put those 6 lines! I expect many people could use this to sync logs  
across nginx frontend and fastcgi or proxy backend.

Performance impact of initializing unsigned long long (\>= 64-bit)  
counter on worker start, ++ on each request, and keeping 8 more bytes in  
memory per process is negligible to both cycles and processor cache  
usage (unless there are any internal thread issues I don’t know about).  
I don’t know the impact of exposing that as a $worker\_request\_counter  
variable; but I assume nginx handles config variables with very high  
efficiency. For a worker serving 1,000 req./s, uint64\_t or equivalent  
would overflow after about 584 million years; I think most people reload  
their nginx workers more often than that.

Obviously all of the above is kind of a kludge, and any theoretically  
elegant solution would be best.

Thanks,

helen

Posted at Nginx Forum:

> **[Per-Request Unique Identifier (Log Correlation)](https://forum.nginx.org/read.php?2,147866,147866#msg-147866)**
>
> There is information available to log by the fastcgi backend which is not available to nginx, and vice versa (e.g., $body\_bytes\_sent). I need some way to match these two logs together after the fact. This necessarily implies a quasi-GUID guaranteed...