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: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Scott Devoid <dev...@anl.gov> To: "OpenStack Development Mailing List (not for usage questions)" <email@example.com> 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.to...@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 . Thanks, Everett  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 > s...@dague.net / sean.da...@samsung.com > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev