Open madhukaw opened 4 years ago
The current behaviour is correct. The usual practice is to write logs to the stderr stream irrespective of the log level. The idea is to separate diagnostic info from normal program output (e.g., user printing something using println()
). See https://linux.die.net/man/3/stderr, https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout and https://unix.stackexchange.com/questions/331611/do-progress-reports-logging-information-belong-on-stderr-or-stdout
Thanks @pubudu91 for the clarification. However, in virtual environments such as Docker etc. where logs are analyzed and processed by machines, stdout and stderr are treated differently. Logs to stderr are usually used as an indication of something abnormal and can be used to trigger alerts, etc. by log analytics solutions. And IMO there is no single globally accepted practice around this, hence better to make it flexible. How about making this configurable, so that if required log levels such as error and fatal can be specifically sent to stderr and others to stdout?
+1 for making it configurable. @MadhukaHarith92 has initiated a discussion on this in the mailing group
We are going with stderr
publishing for swan lake. We are planning to publish log events to a topic, which anyone can subscribe to and execute any custom logics. but this will support after SL
Created a spec issue: https://github.com/ballerina-platform/ballerina-spec/issues/934
Description: Currently, logs of all the levels are written into standard error stream. The correct behavior is only the
ERROR
level logs, i.elog:printError()
should be written into STDERR. Logs of other levels (WARN
,INFO
,DEBUG
,TRACE
) should be written into STDOUT stream.Steps to reproduce: Run the following sample and observe the console output.