jcelliott/lumber

A simple logger for Go

lumber's Issues

Add SetLevels to Logger interface

Thread safe?

Hello,

Just wondering if this library is thread-safe? It probably could be mentioned in the readme.

Exit on Fatal

Hi

I like your Logger, but what I do not understand is, why you didn't put an os.exit(1) when logging Fatal like the standard go logger?

Maybe it would also be great if this is configurable.

Here the doc of the standard go logger:
http://golang.org/pkg/log/#Logger.Fatalf

A panic log level would also be great.

BR, Rene

Prefixes to logs

Add some way to add a prefix to log lines. The idea is to know which package a log came from (like python's logging.getLogger).

No support for log rotation by time

Hey,

Currently it seems the library only does log rotation based on line count. Log rotation based on time would be a really useful feature however. For example if logs were rotated daily this would help finding the correct log file more easier, otherwise multiple files would need to be scanned through to find the correct time range.

Move log levels up one

It would be nice to have log levels start at 1 and have the default log level be 0. The meaning of the default log level could be user-configurable (e.g. Info or 3).

The reason here is that when parsing options with the default "flag" package, it's hard to know when a user wants 0 (trace) or the default (3). Currently, I have to do this:

flag.IntVar(&loglevel, "loglevel", lumber.Info, "some helpful text")

When there are multiple layers (e.g. config file and cmd options), it's more difficult to write fallback code (if not specified on the command-line, use config file}. The only way I could think of is to use an invalid default value (e.g. -1; ugly...) with flag or parse the config file first (not possible if a command-line option can specify where the config file is). This is a solvable problem, but not KISS IMHO.

Everything would be 1e6x easier if log levels started at 1, and 0 meant the default level.

Sprintf always evaluated no matter the log level

The way the various level functions (Info, Debug, Warn etc) contain this code:

fmt.Sprintf(format, v...)

This means that the Sprintf call is always evaluated, no matter what the log level is. This can be very problematic when the package is used with expensive data structures and we want detailed debug messages that should be ignored the rest of the time.

For example, I was using your package with a linter I'm building. This linter traverses a tree and I had seeded it with logger.Debug calls that printed out the whole tree recursively. When I changed the underlying parser to output a bigger tree, my program all of the sudden ran on the order of 10 minutes instead of a couple of seconds. The cause was the calls to logger.Debug which were evaluating the string printouts of the entire tree about once per every vertex in the tree, even when the log level was set to less than DEBUG.

If users have to worry that writing debug messages will affect the performance of their program they won't do it. That defeats the purpose of multilevel logging.

A possible solution is to order the log levels and wrap the logging calls inside the level functions inside a function that checks the current log level.

Panic on multiple log.Close() calls

Calling log.Close() more than once will cause a panic with:

runtime error: close of closed channel

The close method should be safe to call multiple times.

FileLogger not using log level correctly

Not sure if this is a standard everywhere, but from a logger what I would define as expected usage is that:

• Any messages below the logger level will not be tracked. It will not be displayed or written to file.
• Any messages at or above the logger level will be tracked. It will be displayed and/or written to file.

I've set a FileLogger to INFO level. However, one of my Info level messages will not print on console, but it will be written in the file:

 logger.Info(ip, " POST failed validation: ", gridPost)

The above syntax works with fmt.Printf() syntax.

If I switch the message to Warn level, it will still not print on console.

Now, here's where things gets even more interesting.

If I create my FileLogger at WARN level, I still have Info messages being printed out on the console (but not written to file), my Warn messages still doesn't get printed but some are correctly written.

I'm unable to accurately describe examples because it all seems arbitrary.