Open konsti opened 9 years ago
I hadn't thought about that. But having an nginx-log-forwarder process allows you to disable it in case you don't want it. And scrolling through the actual log file is easier than scrolling through the Docker logs (though that may just because of the relative immaturity of Docker logs).
Maybe we can use -F instead of -f. -F allows tail to track renames.
Ok I see. You can keep it flexible by using a service.
We try to avoid log files in the containers as much as possible to keep them from growing. All logs go to docker logs and are shipped to an ELK stack from there, so searching through docker logs isn't a problem for us.
For containers, logging to STDOUT and STDERR is the best way. Agreeing with @konsti, Containers are ephemeral, so the logs cannot be inside them, they need to be exposed to docker so they can be parsed. If you want to have the log contents, you should use a volume instead.
Agree as well. Containers should log to STDOUT and STDERR, let Docker, Kubernetes, your logging platform handle collection, aggregation, attribution and storing. There's no reason for a container to log to the file system.
We've removed the log forwarder (which has caused all sorts of logging problems) and updated our Dockerfile
as follows to log directly to STDOUT and STDERR and have found it much more reliable:
# Disable nginx-log-forwarder because we just use stderr/stdout, but
# need to remove the "sv restart" line in the nginx run command too.
RUN touch /etc/service/nginx-log-forwarder/down && \
sed -i '/nginx-log-forwarder/d' /etc/service/nginx/run
# Forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
Hi,
is there any reason for the nginx-log-forwarder? Having a process with
tail -f
causes trouble with logrotate in my containers and I think we could avoid this entirely.