Hi. In the meantime you can use Socklog [1] or fluent-bit [2] to listen to syslog and write to stdout as I use it in my Image. Pay attention that Fluent-bit writes by default json format to stdout.
https://gitlab.com/aleks001/haproxy18-centos/blob/master/containerfiles/container-entrypoint.sh#L94 The image setup is documented in this post. https://www.me2digital.com/blog/2017/08/openshift-egress-options/#haproxy-generic-proxy I have also written a blog post about syslog in the container world as this is a non trivial topic, imho. https://www.me2digital.com/blog/2017/05/syslog-in-a-container-world/ It would be nice to have a log to stdout option in HAProxy, but until this is available there are many solutions available out there to solve the issue. Regards Aleks [1] http://smarden.org/socklog/ [2] https://fluentbit.io -------- Ursprüngliche Nachricht -------- Von: William Lallemand <wlallem...@haproxy.com> Gesendet: 5. November 2018 17:08:09 GMT+00:00 An: Lukas Tribus <li...@ltri.eu> CC: al-hapr...@none.at, haproxy <haproxy@formilux.org>, Willy Tarreau <w...@1wt.eu> Betreff: Re: CLI proxy for master process Hi Lukas, On Fri, Nov 02, 2018 at 12:21:47PM +0100, Lukas Tribus wrote: > > Btw could stdout logging leverage some of this infrastructure? I > assume that if the master process would write to stdout > (synchronously), we would not stall our workers because of slow log > readers? Well, it will just move the problem from the worker to the master, which will be slowed down and can prevent the ability to do maintenance operations from the master CLI. At the moment we don't have anything to forward the logs from the workers to the master which is another problem, but we could use the sockpair between them, but this is a stream socket which will lead to the same issue. > > https://www.mail-archive.com/haproxy@formilux.org/msg17436.html > https://github.com/dockerfile/haproxy/issues/3 > https://github.com/docker-library/haproxy/pull/39 > > > It looks like in the docker world, everything other than stdout > logging is unacceptable - at least for official docker image, and I'm > wondering if the master/worker process model along with this > infrastructure could theoretically help there, without sacrificing the > performance of the event loop or log reliability. We are aware of the problem and we already discussed this issue several time with the other developers, the ideal design should be the use of a log buffer which will allow TCP logging, and stdout logging. We have the idea in mind but the development is not planned yet. But it will definitively be a useful feature.
