Open Stack

On Wed, 2014-04-30 at 17:04 -0400, matt wrote:
> Basically I love the blueprints thrust.
> 
> I'd love to see a real spec for how to construct a proper openstack
> logging event, and how to place those events into the message queue
> for consumption.  Something that's more engineering spec then proverb.

A log message is not the same as an RPC API message or a notification
event that gets sent out to a message queue. The inconsistency and
sloppiness of the former is what Sean's blueprint addresses. The latter,
IMO, has been very much standardized, and in the last couple releases,
versioned, in order to provide rolling upgrade capabilities and provide
structure to the format and payload of RPC API messages.

> That being said, a couple of things I'd like to see that I didn't see
> in there just yet.  ( mind you i may have missed it, i am human after
> all )
> 
> 1.  Standardized Metadata 
> 
> Being able to parse a log for content with a known metadata structure
> would be very helpful for folks planning on consuming logs in adaptive
> orchestration scenarios.

Sure, this is certainly a good goal. What do you propose are some
concreate changes that we could make here?

> 2.  Message Service Etiquette
> 
> I think the 'logged events need to make sense' starts to get into the
> idea of a common logging etiquette.  But there's the logical aspect
> beyond the aesthetic.  I assume we'll probably want to force rate
> limiting of logging should something start getting noisy.  I feel like
> that's something that should be done before hitting the message bus
> and creating noise there.

Not entirely sure what you're referring to here as "the message bus".
Are you referring to something like rsyslog or syslog-ng and centralized
log file collection?

Regarding rate limiting of log messages, that's something that is
typically configured in configuration management/deployment systems via
standard Python log config and oftentimes depends on the underlying log
service configuration (i.e. syslog config)

>   Specifically I am thinking of the repetition of messages being
> condensed on the app side before being pushed to the bus.

There's certainly lots of room for improvement in getting rid of
worthless debug-level message bloat, but I think Sean's proposal of a
DEBUG2 level gets to the heart of this problem. Thoughts?

Best,
-jay

> This of course calls into question should this ettiquette be different
> for a WARN versus an ERROR?
> 
> 
> 3.  Audit Log Handling

> This is probably outside scope.  Feel free to declare it so.  But once
> we start talking audit logs we need to discuss what can and cannot be
> done to an event before it gets signed ( yeah that would need to be
> discussed too ) and handed off to the audit log pipeline ( that
> doesn't exist yet ).
> 
> 
> -Matt
> 
> 
> 
> On Wed, Apr 30, 2014 at 4:39 PM, Sean Dague <sean at dague.net> wrote:
>         I'm trying to work up some drafts of logging guidelines that
>         we can get
>         agreement on and hopefully get all openstack projects to
>         implement over
>         time. In advance of the Juno summit I'd like to get feedback
>         on drafts
>         via the nova-specs process.
>         
>         The draft review is here -
>         https://review.openstack.org/#/c/91446/
>         
>         Anyone is welcome to log into gerrit and provide feedback on
>         what's
>         there, including general comments on areas we should address
>         which
>         aren't there. I'll try to blend the feedback I get this week
>         for at
>         least one, if not 2 follow up drafts prior to summit.
>         
>         There is not a specific summit session for this, however if
>         we've got a
>         good working doc before the summit I was hoping we could bang
>         out any
>         sticky parts ad-hoc while there.
>         
>                 -Sean
>         
>         --
>         Sean Dague
>         http://dague.net
>         
>         
>         _______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>         
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators