4 ms·
They both can do logging. nginx has issues with formatting numbers/string and undefined values, which makes it harder to extract meaningful data from log. hapr
by user5994461 9y ago
They both can do logging.
nginx has issues with formatting numbers/string and undefined values, which makes it harder to extract meaningful data from log. haproxy is easier to deal with.
Docker abstract away the logging facilities and the filesystem. It's a general issue with Docker, not the software. See the 4th answer in your issue for a solution.
- mschuster91 9y ago> Docker abstract away the logging facilities and the filesystem. No it does not, it expects stdout and stderr to be used and stores its output in a logfile to be replayed with "docker logs" command. First solution in issue: mount /dev/log. Does not work when your host system is OS X or Windows, as you don't have access to the VM that Docker internally uses on non-linuxes. Also, on Linux it pollutes the syslog instead of docker log. Second (the one that refers to a gmane post from 2010) is essentially the same as #1. Third, rsyslog on host (or in a docker image): does not use docker log facility, and docker link is weird. Fourth, use the alpine image which has a syslogd: works, maybe, but is subject to changes in the Dockerfile (e.g. when the inner path of haproxy changes). Also I don't touch Alpine images because I can't use the standard Debian/Ubuntu tooling in case there are network/firewall issues that can best be debugged from inside the container by docker exec -it haproxy bash.
- user5994461 9y agoYes, it does. Docker abstracts away the network and the filesystem. There are many way to write logs, to files, to syslog, to unix socket, to stdout, to UDP sockets. Docker screws with most of them.
- mschuster91 9y ago> Docker abstracts away the network and the filesystem. Not neccessarily the network, if you're using --net=host. Docker does not screw with writing logs to files, to stdout or via UDP networking. When it comes to unix sockets or syslog, depends if the target is inside the container (which works fine AFAIK) or outside (e.g. due to bind-mounting /dev/log or such), but I have not tried the latter.