On 01.03.2016 07:17, Kekane, Abhishek wrote: > Hi Devs, > > Considering return request-id to caller specs [1] is implemented in > python-*client, I would like to begin discussion on how these request-ids > will be logged in cross-projects. In logging work-group meeting > (11-Nov-2015) > [2] there was a discussion about how to log request-id in the log messages. > In same meeting it wass decided to write oslo.log specs but as of now no > specs has been submitted. > > I would like to share our approach to log request-ids and seek suggestions > for the same. We are planning to use request_utils module [3] which was > earlier part of oslo-incubator but removed as no one was using it. > > A typical use case is: Tempest asking Nova to perform some action and Nova > calling Glance internally, then the linkages might look like this: > > RequestID mapping in nova for nova and glance: > --------------------------------------------- > > INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] > Request ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' > -> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43 > > RequestID mapping in tempest for tempest and nova: > ------------------------------------------------- > > INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] > Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' > -> Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4 > > As there is a reference of nova's request-id in tempest and glance's > request-id in nova, operator can easily trace the cause of failure. > > Using request_utils module we can also mention the 'stage' parameter to > divide the entire api cycle with stages, e.g. create server can be > staged as start, get-image can be staged as download-image and active > instance > can be staged as end of the operation. > > Advantages: > ----------- > > With stages provided for API, it's easy for the operator to find out the > failure stage from entire API cycle. > > An example with 'stage' is, > Tempest asking Nova to perform some action and Nova calling Glance > internally, > then the linkages might look like this: > > INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] > Request ID Link: request.link.start > 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' > > INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] > Request ID Link: request.link.image_download > 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> Target='glance' > TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43 > > INFO tempest.tests [req-b0df857fb-18a2-4510-9e85-b9435dh8ye4 admin > admin] Request ID Link: request.link.end > 'req-b0df857fb-18a2-4510-9e85-b9435dh8ye4' > > Concern: > -------- > > As request_utils module is removed from oslo-incubator and this module is > also getting deprecated, I have following options to add it back to > OpenStack. > > Option 1: Add request_utils module in oslo.log (as it is related to logging > request_ids) > Option 2: Add request_utils module in oslo.utils > Option 3: Add link_request_ids method in utils.py of individual projects. > (this will cause code duplication) > > Please let me know your thoughts about the same.
I believe the former option should work good as well. By the way, any plans to track requests down to the root wrappers' shell commands? There is also interesting R&D related to the topic directly [0], see "4. Logging and coordination". Would be nice to reach those people and ask for code snippets or cooperation as well... [0] https://kabru.eecs.umich.edu/papers/publications/2013/socc2013_ju.pdf > > [1] > http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html > [2] > http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html > [3] > http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html > > Thank You, > > Abhishek Kekane > > ______________________________________________________________________ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
