Load balance syslog messages

You can load balance syslog traffic across a pool of backend servers by using a log backend. A log backend is a backend configuration section that specifies mode log.

Use a log backend in combination with a log-forward section to receive messages and load balance them across servers. To define a backend as a log backend:

• Specify mode log.
• Use the balance directive to specify the load balancing algorithm for a log backend. You can specify one of roundrobin, random, log-hash, or sticky.
• List the log servers that should receive log messages.

Log backends support common backend and server features but do not support the HTTP and TCP related features.

Load balance syslog over UDP Jump to heading #

To load balance syslog over UDP, the log-forward section must bind using the dgram-bind directive. In the backend section, the log server address must be prefixed with the udp@ string.

Example:

haproxy
log-forward syslog
  dgram-bind :5144
  log backend@mylog-rrb local0
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 udp@172.31.42.75:3514
  server log2 udp@172.31.41.76:3514

haproxy
log-forward syslog
  dgram-bind :5144
  log backend@mylog-rrb local0
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 udp@172.31.42.75:3514
  server log2 udp@172.31.41.76:3514

For this example, we’ve specified local0 on the log line, so be sure to configure your remote syslog servers to expect logs with the facility code local0. Below is an example portion of an rsyslog configuration that you could apply to save incoming messages to a file named example.log:

rsyslog.conf
text
local0.* /var/log/myapp/example.log

rsyslog.conf
text
local0.* /var/log/myapp/example.log

There is no way to enable a health check for a UDP syslog service. Instead, you can enable TCP checks or agent checks and configure your service to respond to those checks. See Health checks.

Load balance syslog over TCP Jump to heading #

Load balancing syslog over TCP is more reliable than UDP and should work well for the majority of users. However, its performance is generally lower due to extra copies and queuing costs.

To load balance syslog over TCP, the log-forward section must bind using the bind directive.

Example:

haproxy
log-forward syslog
  bind :5144
  log backend@mylog-rrb local0
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 172.31.42.75:3514
  server log2 172.31.41.76:3514

haproxy
log-forward syslog
  bind :5144
  log backend@mylog-rrb local0
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 172.31.42.75:3514
  server log2 172.31.41.76:3514

For this example, we’ve specified local0 on the log line, so be sure to configure your remote syslog servers to expect logs with the facility code local0. Below is an example portion of an rsyslog configuration that you could apply to save incoming messages to a file named example.log:

rsyslog.conf
text
local0.* /var/log/myapp/example.log

rsyslog.conf
text
local0.* /var/log/myapp/example.log

You can enable health checks for the log servers in a TCP syslog service. See Health checks.

Assign weights to servers Jump to heading #

To send more traffic to some servers than other servers, assign weights to each server. A higher weight means more traffic will go to that server.

Example:

haproxy
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 udp@172.31.42.75:3514 weight 20
  server log2 udp@172.31.41.76:3514 weight 10

haproxy
backend mylog-rrb
  mode log
  balance roundrobin
  server log1 udp@172.31.42.75:3514 weight 20
  server log2 udp@172.31.41.76:3514 weight 10

Here, the log1 server will receive twice as much traffic as the log2 server.

See also Jump to heading #

• balance
• log forwarding
• mode reference
• weight reference