I hate ham fisted advice like this that will always end up being dogmatized and multiplying complexity needlessly.
For example, I run gunicorn inside of a container with worker processes, and I had to do some trickery (writing to /proc/1/fd/1) to redirect the logs of the worker processes to the stdout of the master process so that they would show up in `docker logs`.
With all the hoops people jump through so they can say "we use Docker, we're cool" I think I shall refer to Docker fan-boys as Olympic Gymnasts from now on.
I have loads of containers logging to stdout and another container which collects all stdouts and send to a logging-as-a-service. Why is it a bad idea ?
Let's compare logging via stdout, to say syslog, with a simple test.
How do you identify the difference between a warning and an error or an emergency, in a string sent to stdout? What happens if the message contains a newline. How do you know if what follows is a continuation of the log entry, or is a new log entry?
If your application dares to have two processes in the same container (i know, crazy concept) how do you separate them.
The "literally one process per container" idea is what both causes the issue, and causes the obvious solution to the issue to be even harder to solve for the cases where software doesn't natively support the syslog protocol.
Anyways, this is dealt with in the logging-as-a-service (LAAS) that receives the logs... say you are using the python logger, you have different types of logging (DEBUG, INFO, WARN, ERR). If you just start the line with one of those statuses, your LAAS will know it should email you or something like that.
The print, or file, or whatever, it's just how your data is getting somewhere for the proper analysis.
You know if it's a new line or not because every log message starts with the same format, something like {APP, TIME, SEVERITY} and then the message...
> Were you the one who downvotted me because you disagree? o.O
Down voting on HN is broken[1], so I don't use it, ever[2].
1. In the sense of, it does the wrong thing, not in the sense of it doesn't do anything.
2. Except when i hit the wrong thing because of the complete lack of usability on a mobile device.
I currently have logs from the django app and nginx and was pretty easy to set up.
It might not be the best solution but I don't think it's stupid
I really really want a LOG directive for docker where I can just setup some pipes which the daemon will collect and tag into it's log files (would make dealing with old Java processes a lot easier).
But actually finding somewhere to hook this logic in - huge task. A lot harder then grabbing stdout/stderr of the init process in the container.
I use containers for 10 years (they are called VServer), and I newer had a problem with standard setup: some less important logs are stored directly in container and rotated with logrotate, some more important logs (and error messages from less important logs) are forwarded to central server for analyzing, some are just disabled or discarded.
But couldn't Docker provide additional file handles for extra logging streams?
Programs which understand they live in a Docker world could hook into an special system call directly. Non-Docker-Logging-Enabled apps could have a helper program (conceptually similar to 'ip netns exec') remap STDOUT & STDERR.
This exact job is what Syslog (over a network) does.
I'd say they are for isolation before they're for scaling out
> […] will always end up being dogmatized and multiplying complexity needlessly.
If more than one process helps you get your job done, great. If it's all one self-contained application, go for it. You start feeling the pain when you have unrelated or loosely-coupled applications in the same container.