<div dir="ltr"><div><span style="font-size:12.8px">Joshua, </span></div><span style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">I believe that was one of the original complaints/questions, is that<br></span><span style="font-size:12.8px">with osprofiler there is now 2 trace like headers<br></span><span style="font-size:12.8px">(</span><a href="https://github.com/openstack/osprofiler/blob/master/osprofiler/web.py#L36" rel="noreferrer" style="font-size:12.8px" target="_blank">https://github.com/openstack/osprofiler/blob/master/osprofiler/web.py#L36</a><span style="font-size:12.8px">)<br></span><span style="font-size:12.8px">and such being sent around, should we nail that down now and put that<br></span><span style="font-size:12.8px">complaint/question to bed?</span></blockquote><div><br></div><div>The nature of traces and logs is quite different. </div><div><br></div><div>In case of logs you are interested just in fetching all logs related to some request. </div><div>And you have only one UUID per LOG messages. </div><div><br></div><div>In case of tracing we are interested in getting tree structure (nested points) which requires</div><div>actually 3 UUIDs.</div><div><br></div><div>Putting 3 UUIDs in each log message seems to me very expensive and in case of logs not </div><div>so useful. </div><div><br></div><div>So I believe that we should keep those things separated from each other. At least for now. </div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 8:37 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">+1 from me (although I've already contributed to osprofiler so my vote<br>
might not count, ha). Anyway, people can poke me as well if they have<br>
any questions about osprofiler and boris isn't around. I'm happy to<br>
answer any questions as well...<br>
<br>
Thanks boris for getting this rolling again...<br>
<br>
Another question, do we need to talk with the people doing the<br>
request_id integration into clients to make sure that the trace_id (or<br>
whatever its called) is returned to clients...<br>
<br>
I believe that was one of the original complaints/questions, is that<br>
with osprofiler there is now 2 trace like headers<br>
(<a href="https://github.com/openstack/osprofiler/blob/master/osprofiler/web.py#L36" rel="noreferrer" target="_blank">https://github.com/openstack/osprofiler/blob/master/osprofiler/web.py#L36</a>)<br>
and such being sent around, should we nail that down now and put that<br>
complaint/question to bed?<br>
<br>
-Josh<br>
<br>
On Mon, Nov 9, 2015, at 02:57 AM, Boris Pavlovic wrote:<br>
</span><div class="HOEnZb"><div class="h5">> Hi stackers,<br>
><br>
> Intro<br>
> -------<br>
><br>
> It's not a big secret that OpenStack is huge and complicated ecosystem of different<br>
> services that are working together to implement OpenStack API. <br>
><br>
> For example booting VM is going through many projects and services: nova-api, nova-scheduler, nova-compute, glance-api, glance-registry, keystone, cinder-api, neutron-api... and many others. <br>
><br>
> The question is how to understand what part of the request takes the most of the time and should be improved. It's especially interested to get such data under the load. <br>
><br>
> To make it simple, I wrote OSProfiler which is tiny library that should be added to all OpenStack <br>
> projects to create cross project/service tracer/profiler. <br>
><br>
> Demo (trace of CLI command: nova boot) can be found here: <a href="http://boris-42.github.io/ngk.html" rel="noreferrer" target="_blank">http://boris-42.github.io/ngk.html</a><br>
><br>
> This library is very simple. For those who wants to know how it works and how it's integrated with OpenStack take a look here: <a href="https://github.com/openstack/osprofiler/blob/master/README.rst" rel="noreferrer" target="_blank">https://github.com/openstack/osprofiler/blob/master/README.rst</a><br>
><br>
> What is the current status? <br>
> -----------------------------------<br>
><br>
> Good news: <br>
> - OSprofiler is mostly done <br>
> - OSprofiler is integrated with Cinder, Glance, Trove & Ceilometer <br>
><br>
> Bad news: <br>
> - OSprofiler is not integrated in a lot of important projects: Keystone, Nova, Neutron <br>
> - OSprofiler can use only Ceilometer + oslo.messaging as a backend <br>
> - OSprofiler stores part of arguments in api-paste.ini part in project.conf which is terrible thing<br>
> - There is no DSVM job that check that changes in OSprofiler don't break the projects that are using it <br>
> - It's hard to enable OSprofiler in DevStack<br>
><br>
> Good news: <br>
> I spend some time and made 4 specs that should address most of issues: <br>
> <a href="https://github.com/openstack/osprofiler/tree/master/doc/specs" rel="noreferrer" target="_blank">https://github.com/openstack/osprofiler/tree/master/doc/specs</a><br>
><br>
> Let's make it happen in Mitaka!<br>
><br>
> Thoughts?<br>
> By the way somebody would like to join this effort?) <br>
><br>
> Best regards,<br>
> Boris Pavlovic <br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _________________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>