[openstack-dev] [oslo] Log spool in the context

Doug Hellmann doug at doughellmann.com
Thu May 26 17:32:13 UTC 2016

Excerpts from Alexis Lee's message of 2016-05-26 17:29:27 +0100:
> Doug Hellmann said on Thu, May 26, 2016 at 10:16:31AM -0400:
> > I'm not sure silencing all messages for successful requests is a good
> > idea. That was not my understanding of the intent of this work, for
> > sure. I thought the idea was to run the spool logger at debug, but
> > maintain the other normal logging at info level so that monitoring
> > systems could still do things like track request rates and whatever else
> > one might want to do with logs aside from debugging failures.
> We can still emit a few messages per request on the normal logger,
> EG log the request and response for auditability [A]. It's important
> records for a topic come out in-order though.
> By default spooled records will end up in the main log so we also have
> to avoid making it look like more events occurred than actually did.
> This means logging every record to at most one logger. Even if there are
> clues, it's easy to miss them at 3am on an incident, better to avoid
> duplicate messages entirely.
> Please could you go through the usecase you're worried about? For my

It sounded like you were suggesting that all request logging would be
spooled, and there would only be any log messages at all if there was an
error of some sort. I think you've clarified that's not the case.

What I expected was the spool logger would record info at a higher
level than the main logger, but write it to a different location.
That way monitoring tools that do things with the info-level messages
would still be able to look at the main log, but debug tools (or
humans) could look at the spooled log.

> money, either a high-level logrecord is 1) to do with the request
> failing, 2) an issue that does not cause the request to fail or 3)
> something you noticed en-passant, maybe related to the request but
> mostly to do with the overall health of the system.
> 1) Spool like normal, emitted when the request fails.
> 2) Who cares? The code dealt with it.
> 3) Put this on the normal logger. It gets emitted immediately.
> There may be case 2s we care about, EG deprecation warnings. Those
> shouldn't be logged per-request anyway though? So we probably shouldn't
> have case 2s. I'd not expect any case 3s below INFO.
> The normal case will be messages up to INFO getting spooled; INFOs and
> WARNs usually getting spooled, occasionally not; and ERRORs always being
> spooled but flushed very quickly (unless they're so fatal they bring the
> whole system down).
> Alexis (lxsli)
> [A] Logs are not a notification API though, anyone using them as such is
> asking to be broken.

More information about the OpenStack-dev mailing list