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

Alexis Lee lxsli at hpe.com
Thu May 26 16:29:27 UTC 2016

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
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.
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

More information about the OpenStack-dev mailing list