Improve usability of levelled logging
glyn opened this issue · comments
The readme mentions logging levels but only in terms of creating logs. It does not describe how to configure logging at runtime such that only logs of particular levels are output. Without this ability, levels are not so useful. For example, if there are many debug logs, informational messages can be swamped and so it is usual to turn off debug (and possibly info) messages when using a levelled logging system unless debugging is required.
Then when the logging level needs to be increased, e.g. during debugging, turning on debug logging globally often produces too great a volume of logs, so it is usual in logging systems to be able to narrow down the areas of code for which logging is activated.
See, for example, the way the vmodule flag of the glog library works.
For more general inspiration from a mature logging framework, see Java's logback.
The readme isn't clear on this point. When creating the writer sink you specify the minimum logging level to log:
logger.RegisterSink(lager.NewWriterSink(myWriter, lager.INFO))
We expose this as a flag in all our components.
lager does not currently support the ability to control logging level as a function of the area of code. This would make sense to add, however. Logs are organized by sessions and we could have a map of session -> minimum log level.
This probably won't be a high priority for us at this point though.
Thanks. Is the flag standardised across all components, in which case what is the flag? (Would be nice to document this somewhere, although presumably not in lager's docs if it's not a lager standard.)
We use cf-lager: https://github.com/cloudfoundry-incubator/cf-lager to
implement the standardization. We ended up with -logLevel=...
On Sat, Aug 23, 2014 at 9:43 AM, Glyn Normington notifications@github.com
wrote:
Thanks. Is the flag standardised across all components, in which case what
is the flag?—
Reply to this email directly or view it on GitHub
#4 (comment).
How do we enable logging in an integration test, for example? Do we have to modify the code (to generate a sink and register it)?
Not sure why this was closed.
Sorry, thought this was a dead topic.
We are moving to OpenTracing, so the details in this discussion will be changing. In OpenTracing, like X-Trace and Dapper, there is no direct concept of log levels, or of choosing which log levels to write out. Because there are no standard log levels, we would like to move to a more general concept in OpenTracing of sampling and sampling_priority, which allows us to throttle log output while ensuring that important traces are always recorded. Our Debug, Info, and Error logs can map to sampling priorities, and recorders can do whatever implementation specific things they do with that information.
In the lager package, we will provide a basic tracer implementation that can enable/disable the lowest sampling priority (DEBUG statements), and a test tracer that works with our ginkgo tooling. This recreates our existing tools. But we should be able to start consuming 3rd party tracers, such as tracers that do sampling and log in ZipKin format, as they are added to the OpenTracing community.
Thanks for the info.