Logging levels

[Monnand]

Hi all,

I am writing a go program and using log package to write logs. It is
quite handy. However, it does not support logging levels --- debug,
info, error, etc. So I need to write it by myself.

For some logging functions/methods, we don't want it to be compiled in
the final object files. For example, we may not want to compile the
method mylog.Debug() because it only output debug information.

In C/C++, we have preprocessor. It may be evil but quite useful in
some cases. Does go provide similar feature to do the job I mentioned
before?(I mean logging levels, not preprocessor)

Regards,
-Monnand

[Krzysztof Kowalczyk]

There are 2 separate issues here.

1. Logging that provides logging levels.

As you noted, log package in go standard library doesn't provide that
but you can trivially write your own.

2. Excluding some functions depending on the build type.

In C, one way to do it is to use preprocessor. Go doesn't have that
but you can do it differently.

Let's, for example, assume you have a function (Log*) Debug(string s).
You can have 2 different implementation in 2 different files, e.g.
debug_release_build.go and debug_debug_build.go where implementation
in debug_release_build.go would have a no-op implementation.

Then in your build system (e.g. make or whatever build system you use)
you compile either debug_release_build.go or debug_debug_build.go
files. Note that this technique would work in C/C++ as well.

I can't guarantee that current Go compiler is smart enough to fully
exclude code of the no-op implementation (something you can verify
yourself) but even if it doesn't, you probably would have grounds for
opening a bug report.

-- kjk

[Graham Anderson]

Perhaps log4go package has the features you are looking for.

http://code.google.com/p/log4go/

[Kyle Lemons]

Perhaps log4go package has the features you are looking for.

http://code.google.com/p/log4go/

The log4go package does its level best to minimize the execution penalty for calling logging functions when the log message will not go anywhere, but there is still a penalty.  If you are logging in a tight loop (probably on the FINEST log level) you will probably not want to use the utility functions, as those incur extra overhead for making smart decisions about what you're passing it.  In general, I don't recommend preprocessing out debugging logs because it's often useful to turn the debugging up while an application (usually a daemon) is running, which can't be done if those debug messages aren't in the final binary.  I don't usually recommend people use log4go unless they plan on taking meticulous care to specify the proper log level for every message, otherwise you're better off just using the standard log package and prefixing messages with greppable tags like "debug:" or "error:".

~K

[Kyle Lemons]

It will be nice if App Engine logging with its multiple log levels can somehow be unified with the standard log package. 

Log levels were deliberately left out of the standard log package, and were added to appengine because the developer console "expects" them.  There are so many reasons and ways to use log levels that it only really makes sense to leave this up to external packages based on need.

~K

[Monnand]

Thanks for all your nice and smart answers. They are really helpful.

Right now, I just built my own logger with multiple logging levels
based on the standard log package. As Kyle said, debug information may
be useful and it would be better to keep it in final release.

Regards,
-Nan

[Alex]

In generally, I would consider it desirable to have more control on the level of logging output produced by my applications. This should be compiled into the final release binary so I can pass a command line flag to adjust this output on the fly.

My understanding from the previous messages is that go deliberately left out logging levels ... why?

~Alex

[Jesse McNelis]

The appropriate level of a log message is based on the requirements of
the user/admin not the developer. The developer can't actually know what
an appropriate level of a log message should be.

The http package writes log messages, what level should they be at?
The answer is going to be different for every user of the http package.
The same goes for every other package that needs to log.

- jessta

[Paul Borman]

There are lots of opinions on how to do logging correctly.  I would not want to see any package in the standard library do logging (which is different from providing a logging facility).  Logging is something the application developer does (I should note this is a very broad net that includes people writing libraries for suites of applications within an organization).

Each organization and application will likely have different goals for logging.  Kyle and I both work in the same organization and we both have written our our logging packages.  When we compared notes we realized we had different goals as our projects were in different spaces.

Perhaps someone should provide a Go version syslog or syslog-ng that can be installed via goinstall.

    -Paul

[Russ Cox]

On Thu, Sep 8, 2011 at 13:41, Paul Borman <bor...@google.com> wrote:
> Perhaps someone should provide a Go version syslog or syslog-ng that can be
> installed via goinstall.

godoc syslog

[bflm]

Gently reminding us that the dev guys are notorious time travelers ;-)

[Alex]

I understand that, but what can't the standard library log package provide a better interface to developers? Even if standard packages didn't log, I would consider it really useful to have a better log package as a developer.

[Kyle Lemons]

I understand that, but what can't the standard library log package provide a better interface to developers? Even if standard packages didn't log, I would consider it really useful to have a better log package as a developer.

goinstall <your favorite logging package>

Done.