[nginx] Variable $request_id.
SplitIce
mat999 at gmail.com
Wed Apr 27 09:53:38 UTC 2016
I am sure there are many different uses for a variable like this, and many
different properties desired and available.
If we switch to using this variable down the line, I would probably combine
it with something that increments for each request as thats a property that
aids in tracing issues.
On Wed, Apr 27, 2016 at 6:50 PM, ToSHiC <toshic.toshic at gmail.com> wrote:
> Random data string is good: you can easily cut it twice to decrease length
> and it will still be useful and pretty random. For example, twitter zipkin
> works with 64 bit request id. Uuid doesn't have this property.
> 27 Апр 2016 г. 11:41 пользователь "Andrew Hutchings" <ahutchings at nginx.com>
> написал:
>
> Hi,
>>
>> Or you could use UUIDv1 and then it would also give you uniqueness and
>> the ability to have some debugging of IDs if required.
>>
>> Kind Regards
>> Andrew
>>
>> On 27/04/16 06:23, SplitIce wrote:
>>
>>> Hi,
>>>
>>> We have been using something like this for ~2 years.
>>>
>>> For ours we used a random number to start and the Process ID & Process
>>> start time to try and increase uniqueness between reloads (ours is a
>>> 128bit ID). Then applying an increment, with future requests having a
>>> higher id.
>>>
>>> Perhaps that would be better than just 128bit of random data?
>>>
>>> On Wed, Apr 27, 2016 at 12:14 PM, Alexey Ivanov <savetherbtz at gmail.com
>>> <mailto:savetherbtz at gmail.com>> wrote:
>>>
>>> Same here, in our environment we:
>>> * get current request id from a header
>>> * validate it against our guidelines
>>> * if not already present or does not pass validation:
>>> * re-generate using `RAND_bytes()`
>>> * propagate it to the upstream
>>> * echo it back to the downstream
>>> * log it to the access.log
>>>
>>> It would be nice if new nginx code can be used more or less drop-in
>>> replacement for our homegrown lua-stuff.
>>>
>>> We currently use following pseudo-code to
>>> validate/generate/propagate/echo-back request_ids:
>>>
>>> ```
>>> set_by_lua $request_id '
>>> local success, req_id = pcall(request_id.get_hex_or_generate,
>>> ngx.var.http_x_dropbox_request_id)
>>> if not success then
>>> return "-"
>>> end
>>> return req_id
>>> ';
>>> more_set_headers "X-Dropbox-Request-Id: $request_id";
>>> proxy_set_header X-Dropbox-Request-Id $request_id ;
>>> ```
>>>
>>> ```
>>> --[[
>>> Helper function that verifies request_id or generates new one in
>>> case
>>> validation fails.
>>>
>>> @req_id: current request id
>>> --]]
>>> function request_id.get_hex_or_generate(req_id)
>>> ...
>>> end
>>> ```
>>>
>>>
>>> > On Apr 26, 2016, at 9:51 AM, ToSHiC <toshic.toshic at gmail.com
>>> <mailto:toshic.toshic at gmail.com>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > We are using such variable for more than a year, and I suggest to
>>> add ability to extract request_id from header. It's very usefull for
>>> systems with frontend and backend installed on different servers.
>>> >
>>> > On Tue, Apr 26, 2016 at 7:38 PM, Vladimir Homutov <vl at nginx.com
>>> <mailto:vl at nginx.com>> wrote:
>>> > details: http://hg.nginx.org/nginx/rev/59f8f2dd8b31
>>> > branches:
>>> > changeset: 6531:59f8f2dd8b31
>>> > user: Vladimir Homutov <vl at nginx.com <mailto:vl at nginx.com>>
>>> > date: Tue Apr 26 19:31:46 2016 +0300
>>> > description:
>>> > Variable $request_id.
>>> >
>>> > The variable contains text representation based on random data,
>>> usable as
>>> > a unique request identifier.
>>> >
>>> > diffstat:
>>> >
>>> > src/http/ngx_http_variables.c | 47
>>> +++++++++++++++++++++++++++++++++++++++++++
>>> > 1 files changed, 47 insertions(+), 0 deletions(-)
>>> >
>>> > diffs (71 lines):
>>> >
>>> > diff -r 1d0e03db9f8e -r 59f8f2dd8b31 src/http/ngx_http_variables.c
>>> > --- a/src/http/ngx_http_variables.c Fri Dec 18 19:05:27 2015
>>> +0300
>>> > +++ b/src/http/ngx_http_variables.c Tue Apr 26 19:31:46 2016
>>> +0300
>>> > @@ -98,6 +98,8 @@ static ngx_int_t ngx_http_variable_reque
>>> > ngx_http_variable_value_t *v, uintptr_t data);
>>> > static ngx_int_t
>>> ngx_http_variable_request_time(ngx_http_request_t *r,
>>> > ngx_http_variable_value_t *v, uintptr_t data);
>>> > +static ngx_int_t ngx_http_variable_request_id(ngx_http_request_t
>>> *r,
>>> > + ngx_http_variable_value_t *v, uintptr_t data);
>>> > static ngx_int_t ngx_http_variable_status(ngx_http_request_t *r,
>>> > ngx_http_variable_value_t *v, uintptr_t data);
>>> >
>>> > @@ -274,6 +276,10 @@ static ngx_http_variable_t ngx_http_cor
>>> > { ngx_string("request_time"), NULL,
>>> ngx_http_variable_request_time,
>>> > 0, NGX_HTTP_VAR_NOCACHEABLE, 0 },
>>> >
>>> > + { ngx_string("request_id"), NULL,
>>> > + ngx_http_variable_request_id,
>>> > + 0, 0, 0 },
>>> > +
>>> > { ngx_string("status"), NULL,
>>> > ngx_http_variable_status, 0,
>>> > NGX_HTTP_VAR_NOCACHEABLE, 0 },
>>> > @@ -2068,6 +2074,47 @@ ngx_http_variable_request_time(ngx_http_
>>> >
>>> >
>>> > static ngx_int_t
>>> > +ngx_http_variable_request_id(ngx_http_request_t *r,
>>> > + ngx_http_variable_value_t *v, uintptr_t data)
>>> > +{
>>> > + u_char *id;
>>> > +
>>> > +#if (NGX_OPENSSL)
>>> > + u_char random_bytes[16];
>>> > +#endif
>>> > +
>>> > + id = ngx_pnalloc(r->pool, 32);
>>> > + if (id == NULL) {
>>> > + return NGX_ERROR;
>>> > + }
>>> > +
>>> > + v->valid = 1;
>>> > + v->no_cacheable = 0;
>>> > + v->not_found = 0;
>>> > +
>>> > + v->len = 32;
>>> > + v->data = id;
>>> > +
>>> > +#if (NGX_OPENSSL)
>>> > +
>>> > + if (RAND_bytes(random_bytes, 16) == 1) {
>>> > + ngx_hex_dump(id, random_bytes, 16);
>>> > + return NGX_OK;
>>> > + }
>>> > +
>>> > + ngx_ssl_error(NGX_LOG_ERR, r->connection->log, 0,
>>> "RAND_bytes() failed");
>>> > +
>>> > +#endif
>>> > +
>>> > + ngx_sprintf(id, "%08xD%08xD%08xD%08xD",
>>> > + (uint32_t) ngx_random(), (uint32_t) ngx_random(),
>>> > + (uint32_t) ngx_random(), (uint32_t) ngx_random());
>>> > +
>>> > + return NGX_OK;
>>> > +}
>>> > +
>>> > +
>>> > +static ngx_int_t
>>> > ngx_http_variable_connection(ngx_http_request_t *r,
>>> > ngx_http_variable_value_t *v, uintptr_t data)
>>> > {
>>> >
>>> > _______________________________________________
>>> > nginx-devel mailing list
>>> > nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>>> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>> >
>>> > _______________________________________________
>>> > nginx-devel mailing list
>>> > nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>>> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>
>>>
>>> _______________________________________________
>>> nginx-devel mailing list
>>> nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nginx-devel mailing list
>>> nginx-devel at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>
>>>
>> --
>> Andrew Hutchings (LinuxJedi)
>> Technical Product Manager, NGINX Inc.
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160427/fb1e2399/attachment.html>
More information about the nginx-devel
mailing list