Increase information density of logs #85
Conversation
|
Could you split the Close/Ping change into a separate pull request? That one is much less controversial than the rest. Your refactoring does remove one important optimization: Avoiding a large number of logging calls if the debug level isn't set. Usually applications won't have debug logging enabled, so it's quite nice to avoid all the extra logging function calls. |
|
Done. The commits are still in this one because there are small changes that make them conflict, but I rebased this one on the other one, so if you accept the other one this commits will disappear from this one. As for the timing aspect: yes, it's true that it's slightly more overhead (in fact, it's almost 4 times slower!) but we're talking about half a microsecond: https://gist.github.com/novas0x2a/43391b46b8bc7fede657. |
|
An addendum, since I didn't really mention the motivation for that change; one of the nice things about just trusting the log configuration rather than caching the isEnabledFor value is you can change loglevels dynamically- if you notice that your long-running program is misbehaving, you just need to build in a hook to do |
|
refreshed the pull, since it conflicted with merged changes. |
We already have a logger associated with the client, and this makes it easier to track which client is doing what when the logs are aggregated on a log server.
This makes it easier to match requests and responses when the logs are aggregated on a log server.
The getEffectiveLevel check is not actually necessary, the logger already performs an isEnabledFor check when you use the loglevel-specific methods (see Logger in python's logging module). This also breaks DEBUG into two levels, INFO (for the request-response cycle) and DEBUG (for the protocol-specific messages and pings).
Increase information density of logs
I aggregate logs to syslog, and some aspects of how kazoo does logging make it difficult to follow; this pull focuses on improving the log messages and logger handling.