-
Notifications
You must be signed in to change notification settings - Fork 414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symlink /dev/stdout instead of nginx-log-forwarder #72
Comments
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
|
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.The text was updated successfully, but these errors were encountered: