Open Stack

On a previous project, I wrote a library that provided a command-line
option to set the logging levels for different loggers. This was handy for
developers and for support. An example translated to Keystone would be like

keystone-all --logging=keystone.identity=DEBUG

Now the keystone.identity loggers are DEBUG while the rest of the loggers
are still at INFO or whatever their default is. This would be used if you
think the problem is in the identity backend. It's more convenient than
editing a config file.

Also, in our config file we listed the important loggers and had the
default levels for them... for keystone it would be like

# keystone.identity=INFO
# keystone.assignment=INFO
# dogpile=WARNING

This was useful for developers and customers alike, because it was then
easier to figure out what the loggers are.

- Brant




On Thu, Oct 24, 2013 at 10:22 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 10/24/2013 11:00 AM, Sean Dague wrote:
> > On 10/24/2013 10:05 AM, Dan Smith wrote:
> >>> Example 1:
> >>> ==============
> >>>
> >>>      n-conductor log in tempest/devstack -
> >>>
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
> >>>
> >>>
> >>>
> >>>      Total log lines: 84076
> >>>      Total non DEBUG lines: 61
> >>>
> >>>      Question: do we need more than 1 level of DEBUG? 3 orders of
> >>> magnitude information change between INFO -> DEBUG seems too steep a
> >>> cliff.
> >>
> >> Some of them are not useful to me (but might be to others), like the
> >> amqp channel lines. However, everything else has been pretty crucial at
> >> one point or another when debugging issues that span between the two
> >> tightly-coupled services.
> >
> > Right, which is definitely why it's a conversation, to figure out what's
> > useful, and what isn't. We definitely don't want to remove things that
> > are useful.
> >
> > The amqp lines are 49562 of the DEBUG lines, so dropping those would
> > drop our DEBUG output in more than half, which would be cool if it
> > didn't have an impact of folks.
> >
> > I also just wanted to raise the question, are there multiple levels of
> > DEBUG that might make sense here? For instance, every received seems to
> > be followed by an unpacked, which actually has info that was in the
> > received hash -
> >
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz#_2013-10-23_12_25_22_524
> >
> >
> > If we had DEBUG and DEBUG2 levels, where one of them would only be seen
> > at the higher debug level, would that be useful?
> >
> > I'm not actually trying to pick on conductor here, but it makes a good
> > example of a service that DEBUG level is extremely useful to
> > development, and is used heavily, and might make us thing about multi
> > levels of DEBUG to go deeper down the rabbit hole only if we really need
> > to.
>
> Note that we can't actually change the level used by other libs, like
> amqp.  However, we can set more granular logger levels.  We could
> re-define debug=True to only set up debug for openstack stuff, and add a
> new option debug_all=True that enables debugging for *everything*.
>
> --
> Russell Bryant
>
> _______________________________________________
> 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/20131024/1e5d1766/attachment.html>