Hi guys, Long story short: We have a need for a new feature for haproxy, which allows logging to normal files (as opposed to the current domain socket/UDP servers). This will of course require adding such an option to the configuration. I am willing to write the whole feature (with reviews from the community, of course). I understood from the README at your github that it might be best to ask here first: is there a specific reason why this wasn't implemented yet?
Long Story (and an introduction): I normally work on the OpenStack project (an open source cloud project), and specifically on the networking component called Neutron. A simplified setup in OpenStack looks like one or more machines, and each machine may run a number of VMs and in addition several agents (some of which deal with networking, some of which deal with storage, etc). The main agent which is interesting to this discussion is an LBaaS-Agent (Load Balancing as a Service), which serves mainly as an engine to run one or more load balancing services - for example haproxy. Each service may handle more than one haproxy process. The problem I'm trying to solve: If there are N haproxy processes in one machine (N >= 2), and say the setup isn't stable (so VMs constantly goes up and down), many log messages will be written to syslog and it will become ungainly and complicated to differentiate which log message belongs to which haproxy. I spent a few days recently to solve this problem by assigning, for each haproxy process, a separate domain socket, and having LBaaS-Agent read from said sockets. Each time a new log is read, the message is written to a specific (different) file. In other words, say I have N haproxy processes; these are connected to N domain sockets, and the logs are read by a single LBaaS-Agent and finally written to N log files. This is far from optimal (and difficult to maintain because of the long route each log file is now making, and because there is now a single point of failure). Adding the ability for each haproxy to dump its logs to a specific file will solve the long workaround we made in the code (which is currently being reviewed and can be found at [1]). As you might read this, you might exclaim "a simple change in the syslog configuration will tell it to redirect the logs to a specific file (see [2]). However, we have two main issues with this implementation: 1) All the logs will be written to one file, not solving to sorting problem. The difficulty of manually sorting each log to a different haproxy is increased exponentially with the number of haproxy processes. 2) This requires changes in the deployment tool, since neutron shouldn't touch syslog.conf. This isn't as simple as it sound since there are quite a few deployment tools for OpenStack, and if someone isn't using a deployment tool for OpenStack, this feature shouldn't be available. In conclusion, I would appreciate any feedback on the proposed patch, and the reasons it hasn't been implemented yet. If you see other alternatives, these will be welcome as well (we are open to discuss any proposal). [1] https://review.openstack.org/#/c/119731/ [2] http://marc.info/?l=haproxy&m=138643818630142&w=2 Thanks a lot for reading this far, -- John Schwarz, Software Engineer, Red Hat.
