Troubleshoot HAProxy logs missing from rsyslog

Trace the logging path in three stages: HAProxy must emit an event, rsyslog must receive it on the configured transport, and a rule must write or forward it. Testing a local syslog socket does not prove that a UDP listener works, so keep the transport consistent while troubleshooting.

Configure the HAProxy sender

For an HTTP proxy using a local Unix socket, the relevant fragment is:

global
    log /dev/log local0

defaults
    mode http
    log global
    option httplog

Merge this into your existing sections rather than creating conflicting duplicates. log global makes the defaults inherit the global destination. For a TCP-mode proxy, use the logging format appropriate to that mode, such as option tcplog.

As an alternative to the socket, set the global destination to log 127.0.0.1:514 local0. That is a UDP syslog destination in this form, so rsyslog must listen on UDP.

Match the rsyslog receiver

For the UDP alternative, load the module once and bind the listener locally:

module(load="imudp")
input(type="imudp" address="127.0.0.1" port="514")

if $syslogfacility-text == "local0" then {
  action(type="omfile" file="/var/log/haproxy.log")
}

For /dev/log, use the distribution's local socket/journal integration; enabling UDP is unnecessary. In either case check output-directory permissions and rule order. Add stop after the action only if later rules should not process those events.

Check a chrooted socket path

With chroot /var/lib/haproxy, HAProxy's /dev/log refers to a socket inside that root. If it is absent, configure an additional rsyslog Unix socket at the corresponding host path:

input(type="imuxsock"
      Socket="/var/lib/haproxy/dev/log"
      CreatePath="on")

Ensure imuxsock is loaded once in the combined configuration. Alternatively, use the loopback UDP route and its matching receiver.

Validate each hop

sudo rsyslogd -N1
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

After applying valid configurations through your service manager, test the chosen input. On Linux with util-linux logger:

# Test the default local syslog path.
logger -t haproxy -p local0.info "Local syslog check"

# Test the loopback UDP listener instead.
logger --udp --server 127.0.0.1 --port 514 -t haproxy -p local0.info "UDP syslog check"

Then send a request through HAProxy and inspect /var/log/haproxy.log. Traffic logs may be emitted when the request/session completes; long-lived connections and logging suppression options can affect what you see.

If delivery fails only under load

Investigate socket buffers, rate limits, queues, CPU, disk, and receiver errors before attributing every loss to UDP. UDP provides no delivery acknowledgment. A different transport requires support and compatible framing at both ends; simply changing rsyslog to TCP is insufficient.

On SELinux systems, inspect denial records and apply a narrowly scoped policy for the required socket or port. Do not broadly enable unrelated outbound access as the first troubleshooting step.

References: HAProxy logging configuration, rsyslog Unix sockets, and UDP input.