Usually log messages are written to stderr. I'm wondering if it is a good idea/practice to split log messages so that errors and warnings go to stderr while debug/informational/notice messages go to stdout instead? Or is this irrelevant given that many dedicated logging processes only read from stdin anyway, which requires source log messages in stderr and stdout be combined and redirect to logger's stdin.
The two answers below both mentioned syslog, I think I need to clarify the setup in detail.
The daemon processes I asked are running in foreground by themselves. Daemonization is managed by supervising processes such as
supervisord. In both cases, the stderr and stdout of the daemon processes will be captured by the supervising processes, and it's the supervising processes' job to decide how and where to store the logs (might be syslog, or somewhere else in the network over UDP). The daemon processes don't have to worry about what and where to write logs, as they just write to stdout/stderr.
In the case of
runit, its logging facility
svlogd will read from its stdin for the redirected log messages, which are combined stderr/stdout of the managed daemon process. As for
supervisord, it can record stderr and stdout to separate log files.
So in this specific settings, is it a good practice to split logs between stderr and stdout, or just write to one of them?