+111 from me. 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.
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. Salvatore On 13 June 2012 18:23, Jay Pipes <jaypi...@gmail.com> wrote: > On 06/13/2012 01:21 PM, Gabe Westmaas wrote: > >> >> >> On 6/12/12 12:32 PM, "Jay Pipes"<jaypi...@gmail.com> wrote: >> >> On 06/12/2012 01:27 AM, Gabe Westmaas wrote: >>> >>>> In nova we use a request ID to to help in finding all logs associated >>>> with >>>> a particular request, and this has proven to be extremely useful when >>>> debugging issues. This should be taken a bit further, in two different >>>> directions. >>>> >>>> First, I'd like to see the request ID stored along with the any faults >>>> that are registered, and I'd like to see that request ID returned in the >>>> fault data. Returning it in the fault data can start as an extension >>>> for >>>> now, and that should be able to move forward into the API pretty easily. >>>> >>> >>> This is a no-brainer. ++ >>> >>> Second, I'd like to figure out how we can extend this concept to all the >>>> openstack services. I see two competing desires here. First, we want >>>> to >>>> know about a particular request to a given service and second we want to >>>> know about an overall transaction across all services. So, for >>>> example, a >>>> single create server request may cause multiple requests to glance, and >>>> depending on the issue, it would be great to both tie those together or >>>> investigate separately. To this end, I'd like to see both a request ID >>>> and a transaction ID. I'd like to see both these items in log, and I'd >>>> like all OpenStack services to obey the rule that if the transaction ID >>>> is >>>> set, don't reset it to anything else, but always add a request ID. >>>> >>> >>> OK, so the request ID would be specific to a service (e.g. Nova, Glance, >>> but not nova-api and nova-compute) and the transaction ID would be >>> across all services? >>> >>> Or would the request ID change from nova-api to nova-scheduler to >>> nova-compute? >>> >> >> I was definitely thinking the first of these two options, but I suppose we >> should talk that out a little bit. Seems like a likely line is when a new >> HTTP call is made, the request-id is reset. This allows us to disallow >> passing in a request-id for all web services, which would lend itself well >> to a common middleware. That is to say, users of an API can pass in a >> transaction ID (which means the transaction ID could originate from the >> customer, if that's helpful to them) and the request id would always get >> set to a random UUID any time it passed through this middleware. >> >> Thus the request ID is the same from nova api to scheduler to compute to >> network. However, glance api and glance registry would each have unique >> request IDs, but a common transaction ID. >> > > OK, I could definitely go along with this. > > > -jay > > > ______________________________**_________________ > Mailing list: > https://launchpad.net/~**openstack<https://launchpad.net/~openstack> > Post to : openstack@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~**openstack<https://launchpad.net/~openstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
