[openstack-dev] Proposed Logging Standards

Brad Topol btopol at us.ibm.com
Tue Jan 28 21:25:10 UTC 2014


So we are starting to add more cloud audit (aka CADF) support to 
OpenStack.  We have support in Nova and infrastructure added to Ceilometer 
and I am starting to add this capability to keystone.  This work is based 
on sending events to ceilometer.  If this is related to the audit work 
below I would like to be included. 

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Scott Devoid <devoid at anl.gov>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date:   01/28/2014 12:47 PM
Subject:        Re: [openstack-dev] Proposed Logging Standards



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 :-/

~ Scott


On Tue, Jan 28, 2014 at 11:11 AM, Everett Toews <
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 / 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


_______________________________________________
OpenStack-dev mailing list
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/4309cb4e/attachment.html>


More information about the OpenStack-dev mailing list