Open Stack

On 01/30/2014 07:15 PM, John Dickinson wrote:
> I've been keeping an eye on this thread, and it seems I actually have a few minutes to spend on a response today.
> 
> To first answer the specific question, while there are some minor technical concerns about oslo logging, the bigger concerns are non-technical. Some things I'm concerned about from a technical perspective are that it's not a separate module or package that can be imported, so it would probably currently require copy/paste code into the Swift codebase. My second concern is that there are log line elements that just don't seem to make sense like "instance". I'd be happy to be wrong on both of these items, and I want to make clear that these are not long-term issues. They are both solvable.
> 
> My bigger concern with using oslo logging in Swift is simply changing the request log format is something that cannot be done lightly. Request logs are a very real interface into the system, and changing the log format in a breaking way can cause major headaches for people relying on those logs for system health, billing, and other operational concerns.
> 
> One possible solution to this is to keep requests logged the same way, but add configuration options for all of the other things that are logged. Having two different logging systems (or multiple configurable log handlers) to do this seems to add a fair bit of complexity to me, especially when I'm not quite sure of the actual problem that's being solved. That said, adding in a different log format into Swift isn't a terrible idea by itself, but migration is a big concern of any implementation (and I know you'll find very strong feelings on this in gerrit if/when something is proposed).
> 
> 
> 
> Now back to the original topic of actual logging formats.
> 
> Here's (something like) what I'd like to see for a common log standard (ie Sean, what I think you were asking for comments on):
> 
> log_line = prefix message
> prefix = timestamp project log_level
> message = bytestream
> timestamp = `eg the output of time.time()`
> project = `one of {nova,swift,neutron,cinder,glance,etc}`
> 
> Now, there's plenty of opportunity to bikeshed what the actual log line would look like, but the general idea of what I want to see has 2 major parts:
> 
> 1) Every log message is one line (ends with \n) and the log fields are space-delineated. eg (`log_line = ' '.join(urllib.quote(x) for x in log_fields_list)`)
> 
> 2) The only definition of a log format is the prefix and the message is a set of fields defined by the service actually doing the logging.

So, actually, most of my concern at this point wasn't the line format.
It was the concern about when projects were calling the loggers, and
what kind of information should be logged at each level.

Given that most projects are using the oslo defaults today, much of the
line format is handled. I think that if you have concerns on that front,
it's probably a different conversation with the oslo team.

I do agree we should standards a little more on project (i.e. logger
"name"), because in most projects this is just defaulting to module.
Which is fine for debug level, but not very user friendly at ops levels.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140131/bfee5b03/attachment.pgp>