[logback-user] Logging to stderr and stdout

[Daniel Ferber]

Hi Steve,

Once I worked on a java program that controls the execution of a
mathematical solver: it runs for extensive time and finishes with an
output. At that opportunity, I wondered about the exactly the same logging
issues mentioned by you and tried all them out. After a while,
I convinced myself that typical log shall not go either to stdout, nor
stderr, but preferably to a file per execution or a rolling file.

For a while, I was tempted to print warn and error messages to stderr,
while printing info, debug and trace messages to stdout. It sounded
intuitive. However, this configuration did not evince any value to our
work. I could not conceive any use case for having my log split into stderr
and stdout, therefore I abandoned this approach. Even worse, if a channel
is buffered, then stderr and stdout might get out of sync. That might
confuse you if an error message (stderr) is print before a trace message
(stdout) that describes the cause. If you run your program from a console
and redirect a channel to a file, the information will be incomplete. And I
think it is more value having all messages together for easier manipulation
with a good log analysis tool, rather than premature separation of log
messages during execution.

For the same reason, I believe that stderr and stdout never should print
both the same log message. Besides the issues explained above, it causes
useless duplicated output.

Therefore, for a "keep it simple" scenario, I would just print all log
messages, regardless of log level, to either stdout or stderr.
I  prefer not using any of them, but a log file per execution, or a rolling
file instead.

One could claim the following use case: to provide user friendly messages
separated from technical log messages. Note that log messages are usually
not intended to be read by the user. A trivial solution would be printing
user friendly messages to stdout and all log to stderr. This allows one to
call the program and redirect stderr (log) into a separate file or device,
while interacting with user friendly messages on the console. Be aware that
his is not the intended use of stderr according to the Posix standards,
though nobody would blame you. As long as well understood by the
development team and your users, this could be assumed as your own
standard. I used this approach for a while with reasonable satisfaction.

Best regards,
Daniel Felix Ferber
http://techtavern.wordpress.com




2012/10/20 Steve Ramage <vcolo at sjrx.net>

> **
>
> I had a question about the conventions of logging. We have an application
> scientific in nature, and basically it runs some process for some amount of
> time, and then finishes with it's output. All output in the program is
> driven by logback, and we generally hide the complexity of logback from our
> users, and support very limited configuration as needed.
>
>
>
> One issue is where error and warning messages should go for users.
>
>
>
> One argument is that they should go to stderr.  stdout should have INFO,
> DEBUG, and TRACE. There doesn't seem to be an easy way to do this in
> logback.
>
>
>
> Another argument is that they should go to stderr. stdout should also have
> them, but also INFO, DEBUG, and TRACE. If the user is running directly then
> both get spammed together.
>
>
>
> A final option is they should all go to stdout, as these are all log
> messages, and there is no need to split them
>
>
>
> Now this isn't so much a religious argument,  we are just more wondering
> what the conventions were, as we would like to follow them as much possible.
>
>
>
> Thanks,
>
>
>
> Steve Ramage
>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20121025/edaa65e9/attachment.html>