<div dir="ltr"><div><br class=""><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">A big part of my interest here is to make INFO a useful informational<br>
level for operators. That means getting a bunch of messages out of it<br>that don't belong.</blockquote></div><div><br></div><div>+1 to that! How should I open / tag bugs for this?</div><div><br></div><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">
We should be logging user / tenant on every wsgi request, so that should<br>be parsable out of INFO. If not, we should figure out what is falling<br>down there.<br></blockquote><div><br></div><div>At the moment we're not automatically parsing logs (just collecting via syslog and logstash).</div>
<div><br></div><div><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">Follow on question: do you primarily use the EC2 or OSAPI? As there are<br>
some current short comings on the EC2 logging, and figuring out<br>normalizing those would be good as well.</blockquote><div> </div></div>Most of our users work through Horizon or the nova CLI. Good to know about the EC2 issues though.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 1:46 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><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">
<div class="im">On 01/28/2014 12:41 PM, Scott Devoid wrote:<br>
> For the uses I've seen of it in the nova api code INFO would be<br>
> perfectly fine in place of AUDIT.<br>
><br>
><br>
> We've found the AUDIT logs in nova useful for tracking which user<br>
> initiated a particular request (e.g. delete this instance). AUDIT had a<br>
> much better signal to noise ratio than INFO or DEBUG. Although this<br>
> seems to have changed since Essex. For example nova-compute spits out<br>
> "AUDIT nova.compute.resource_tracker" messages every minute even if<br>
> there are no changes :-/<br>
<br>
</div>A big part of my interest here is to make INFO a useful informational<br>
level for operators. That means getting a bunch of messages out of it<br>
that don't belong.<br>
<br>
We should be logging user / tenant on every wsgi request, so that should<br>
be parsable out of INFO. If not, we should figure out what is falling<br>
down there.<br>
<br>
Follow on question: do you primarily use the EC2 or OSAPI? As there are<br>
some current short comings on the EC2 logging, and figuring out<br>
normalizing those would be good as well.<br>
<br>
-Sean<br>
<div class="im"><br>
><br>
> ~ Scott<br>
><br>
><br>
> On Tue, Jan 28, 2014 at 11:11 AM, Everett Toews<br>
</div><div><div class="h5">> <<a href="mailto:everett.toews@rackspace.com">everett.toews@rackspace.com</a> <mailto:<a href="mailto:everett.toews@rackspace.com">everett.toews@rackspace.com</a>>> wrote:<br>
><br>
> Hi Sean,<br>
><br>
> Could 1.1.1 "Every Inbound WSGI request should be logged Exactly<br>
> Once" be used to track API call data in order to discover which API<br>
> calls are being made most frequently?<br>
><br>
> It certainly seems like it could but I want to confirm. I ask<br>
> because this came up as B "Get aggregate API call data from<br>
> companies willing to share it." in the user survey discussion [1].<br>
><br>
> Thanks,<br>
> Everett<br>
><br>
> [1]<br>
> <a href="http://lists.openstack.org/pipermail/user-committee/2014-January/000214.html" target="_blank">http://lists.openstack.org/pipermail/user-committee/2014-January/000214.html</a><br>
><br>
><br>
> On Jan 27, 2014, at 7:07 AM, Sean Dague wrote:<br>
><br>
> > Back at the beginning of the cycle, I pushed for the idea of doing<br>
> some<br>
> > log harmonization, so that the OpenStack logs, across services, made<br>
> > sense. I've pushed a proposed changes to Nova and Keystone over<br>
> the past<br>
> > couple of days.<br>
> ><br>
> > This is going to be a long process, so right now I want to just<br>
> focus on<br>
> > making INFO level sane, because as someone that spends a lot of time<br>
> > staring at logs in test failures, I can tell you it currently isn't.<br>
> ><br>
> > <a href="https://wiki.openstack.org/wiki/LoggingStandards" target="_blank">https://wiki.openstack.org/wiki/LoggingStandards</a> is a few things I've<br>
> > written down so far, comments welcomed.<br>
> ><br>
> > We kind of need to solve this set of recommendations once and for<br>
> all up<br>
> > front, because negotiating each change, with each project, isn't going<br>
> > to work (e.g - <a href="https://review.openstack.org/#/c/69218/" target="_blank">https://review.openstack.org/#/c/69218/</a>)<br>
> ><br>
> > What I'd like to find out now:<br>
> ><br>
> > 1) who's interested in this topic?<br>
> > 2) who's interested in helping flesh out the guidelines for<br>
> various log<br>
> > levels?<br>
> > 3) who's interested in helping get these kinds of patches into various<br>
> > projects in OpenStack?<br>
> > 4) which projects are interested in participating (i.e. interested in<br>
> > prioritizing landing these kinds of UX improvements)<br>
> ><br>
> > This is going to be progressive and iterative. And will require<br>
> lots of<br>
> > folks involved.<br>
> ><br>
> > -Sean<br>
> ><br>
> > --<br>
> > Sean Dague<br>
> > Samsung Research America<br>
</div></div>> > <a href="mailto:sean@dague.net">sean@dague.net</a> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
> <mailto:<a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a>><br>
<div class="im">> > <a href="http://dague.net" target="_blank">http://dague.net</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</div><div class=""><div class="h5">--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>