system-config/playbooks/roles/haproxy/files/rsyslog.d/49-haproxy.conf

# Create additional haproxy socket to be mapped into container

$AddUnixListenSocket /var/lib/haproxy/dev/log

:programname, startswith, "haproxy" {
   /var/log/haproxy.log
   stop
}
haproxy: redirect logs to a separate file haproxy only logs to /dev/log; this means all our access logs get mixed into syslog. This makes it impossible to pick out anything in syslog that might be interesting (and vice-versa, means you have to filter out things if analysing just the haproxy logs). It seems like the standard way to deal with this is to have rsyslogd listen on a separate socket, and then point haproxy to that. So this configures rsyslogd to create /var/run/dev/log and maps that into the container as /dev/log (i.e. don't have to reconfigure the container at all). We then capture this sockets logs to /var/log/haproxy.log, and install rotation for it. Additionally we collect this log from our tests. Change-Id: I32948793df7fd9b990c948730349b24361a8f307 2022-06-10 14:37:14 +10:00			`# Create additional haproxy socket to be mapped into container`

Move haproxy config into /var/lib/haproxy Rsyslog on Noble has apparmor rules that restrict rsyslog socket creation to /var/lib/*/dev/log. Previously we were configuring haproxy hosts to create an rsyslog socket for haproxy at /var/haproxy/dev/log which doesn't match the apparmor rule so gets denied. To address this we move all the host side haproxy config from /var/haproxy to /var/lib/haproxy. This allows rsyslog to create the socket. To avoid needing to update docker images (for haproxy statsd) and to continue to make the haproxy container itself happy we don't adjust paths on the target side of our bind mounts. This means some things still refer to /var/haproxy but they should all be within containers. I don't believe this will be impactful to existing load balancer servers. We should deploy new content to /var/lib/haproxy then automatically restart services (rsyslog and haproxy container) because their configs are updating. One potential problem with this is rsyslog will restart before the containers do and its log path will have moved. If we are concerned about this we can configure rsyslog to continue to attempt to create the old path in addition to the new path (this will fail on Noble). Change-Id: I4582e6b2dda188583f76265ab78bcb00a302e375 2025-02-12 09:10:08 -08:00			`$AddUnixListenSocket /var/lib/haproxy/dev/log`
haproxy: redirect logs to a separate file haproxy only logs to /dev/log; this means all our access logs get mixed into syslog. This makes it impossible to pick out anything in syslog that might be interesting (and vice-versa, means you have to filter out things if analysing just the haproxy logs). It seems like the standard way to deal with this is to have rsyslogd listen on a separate socket, and then point haproxy to that. So this configures rsyslogd to create /var/run/dev/log and maps that into the container as /dev/log (i.e. don't have to reconfigure the container at all). We then capture this sockets logs to /var/log/haproxy.log, and install rotation for it. Additionally we collect this log from our tests. Change-Id: I32948793df7fd9b990c948730349b24361a8f307 2022-06-10 14:37:14 +10:00
			`:programname, startswith, "haproxy" {`
			`/var/log/haproxy.log`
			`stop`
			`}`