+111 from me. <div>This would make a lot easier extracting info from logs and correlating events in different logs. In the long run these association might also be used by metering/billing applications.</div><div><br></div>
<div>This is probably out of scope, but I was wondering whether we can also add a concept of "parent request", so that for each request in a given transaction we would be immediately able to know which request generated it. </div>
<div><br></div><div>Salvatore<br><br><div class="gmail_quote">On 13 June 2012 18:23, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 06/13/2012 01:21 PM, Gabe Westmaas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 6/12/12 12:32 PM, "Jay Pipes"<<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>  wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/12/2012 01:27 AM, Gabe Westmaas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In nova we use a request ID to to help in finding all logs associated<br>
with<br>
a particular request, and this has proven to be extremely useful when<br>
debugging issues.  This should be taken a bit further, in two different<br>
directions.<br>
<br>
First, I'd like to see the request ID stored along with the any faults<br>
that are registered, and I'd like to see that request ID returned in the<br>
fault data.  Returning it in the fault data can start as an extension<br>
for<br>
now, and that should be able to move forward into the API pretty easily.<br>
</blockquote>
<br>
This is a no-brainer. ++<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Second, I'd like to figure out how we can extend this concept to all the<br>
openstack services.  I see two competing desires here.  First, we want<br>
to<br>
know about a particular request to a given service and second we want to<br>
know about an overall transaction across all services.  So, for<br>
example, a<br>
single create server request may cause multiple requests to glance, and<br>
depending on the issue, it would be great to both tie those together or<br>
investigate separately.  To this end, I'd like to see both a request ID<br>
and a transaction ID.  I'd like to see both these items in log, and I'd<br>
like all OpenStack services to obey the rule that if the transaction ID<br>
is<br>
set, don't reset it to anything else, but always add a request ID.<br>
</blockquote>
<br>
OK, so the request ID would be specific to a service (e.g. Nova, Glance,<br>
but not nova-api and nova-compute) and the transaction ID would be<br>
across all services?<br>
<br>
Or would the request ID change from nova-api to nova-scheduler to<br>
nova-compute?<br>
</blockquote>
<br>
I was definitely thinking the first of these two options, but I suppose we<br>
should talk that out a little bit.  Seems like a likely line is when a new<br>
HTTP call is made, the request-id is reset.  This allows us to disallow<br>
passing in a request-id for all web services, which would lend itself well<br>
to a common middleware.  That is to say, users of an API can pass in a<br>
transaction ID (which means the transaction ID could originate from the<br>
customer, if that's helpful to them) and the request id would always get<br>
set to a random UUID any time it passed through this middleware.<br>
<br>
Thus the request ID is the same from nova api to scheduler to compute to<br>
network.  However, glance api and glance registry would each have unique<br>
request IDs, but a common transaction ID.<br>
</blockquote>
<br></div></div>
OK, I could definitely go along with this.<div class="HOEnZb"><div class="h5"><br>
<br>
-jay<br>
<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/<u></u>ListHelp</a><br>
</div></div></blockquote></div><br></div>