Open Stack

> A big part of my interest here is to make INFO a useful informational
> level for operators. That means getting a bunch of messages out of it
> that don't belong.


+1 to that! How should I open / tag bugs for this?

We should be logging user / tenant on every wsgi request, so that should
> be parsable out of INFO. If not, we should figure out what is falling
> down there.
>

At the moment we're not automatically parsing logs (just collecting via
syslog and logstash).

Follow on question: do you primarily use the EC2 or OSAPI? As there are
> some current short comings on the EC2 logging, and figuring out
> normalizing those would be good as well.


Most of our users work through Horizon or the nova CLI. Good to know about
the EC2 issues though.


On Tue, Jan 28, 2014 at 1:46 PM, Sean Dague <sean at dague.net> wrote:

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