How to Set Up a Remote Syslog Server with rsyslog

Updated: 18 October 2026 · Applies to: rsyslog 8.2510 on AlmaLinux 9.8 and 10.2 (the same steps apply to Rocky Linux and RHEL 9 and 10) and rsyslog 8.2312 on Ubuntu 24.04, all tested; package defaults checked on Ubuntu 26.04 (rsyslog 8.2512) and Debian 13 (8.2504)

A remote syslog server is a server that collects log messages from your other servers and network devices, by default on port 514 (UDP and TCP). With rsyslog you set it up in two parts: on the log server, an input on port 514 that writes each sender's logs to its own folder; on every other server, one forwarding line in /etc/rsyslog.d/. Test with logger.

Which port and protocol?

• UDP 514: classic syslog, and what most routers, switches and firewalls send. There is no delivery confirmation.
• TCP 514: the usual choice between Linux servers.
• RELP (package rsyslog-relp): according to rsyslog, it confirms every message, so nothing is lost in transit when a connection breaks, which plain TCP cannot promise. It has no fixed port; we used 20514.
• TLS on 6514: for logs that cross the internet. See remote rsyslog with TLS and plain TCP.

Before you start

• rsyslog is installed by default on AlmaLinux, Rocky Linux and RHEL (it is in the Core package group) and on Ubuntu (priority "important"). Debian 13 does not install it by default: apt install rsyslog.
• Give the log server enough disk space, and allow only your own servers through its firewall.

1. Set up the log server

1. Create /etc/rsyslog.d/10-remote-server.conf:

   module(load="imtcp")
   module(load="imudp")
   template(name="PerHost" type="string"
            string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log")
   ruleset(name="remote") {
       action(type="omfile" dynaFile="PerHost" fileCreateMode="0640" dirCreateMode="0750")
       stop
   }
   input(type="imtcp" port="514" ruleset="remote")
   input(type="imudp" port="514" ruleset="remote")

   • The separate ruleset keeps remote messages out of the server's own /var/log/messages or /var/log/syslog.
   • secpath-replace stops a crafted program name from writing outside the folder. In our test, a message tagged ../../../tmp/evil ended up as _..log inside /var/log/remote/.
   • The default rsyslog.conf has commented imudp and imtcp lines. Leave them commented, so each module is loaded once.
2. Check the syntax and restart. On Ubuntu 24.04 the check printed:

   rsyslogd -N1
   rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.
   
   systemctl restart rsyslog

3. Open port 514 for your servers only, for TCP and for UDP:

   firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port="514" protocol="tcp" accept'
   firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port="514" protocol="udp" accept'
   firewall-cmd --reload

   With UFW: ufw allow from 203.0.113.0/24 to any port 514 proto tcp and the same with proto udp. More in how to open a port on RHEL, AlmaLinux and Rocky Linux.

SELinux (AlmaLinux, Rocky Linux, RHEL): no change is needed for port 514. We checked the policy on AlmaLinux 9.8 and 10.2: TCP 514 is labelled for the old rsh service, but rsyslog is allowed to use it; TCP 601 and 20514 and UDP 514, 601 and 20514 are labelled for syslog, and 6514 and 10514 for syslog over TLS. For any other port, Red Hat documents semanage port -a -t syslogd_port_t -p tcp 30514 (from the policycoreutils-python-utils package).

Ubuntu: rsyslog opens the ports as root and then runs as the syslog user, so the files belong to syslog. Its AppArmor profile allows writing only below /var/log/: keep the remote folder there.

2. Test the server

From any Linux machine, send one message over TCP (-T) and one over UDP (-d):

logger -n 203.0.113.50 -P 514 -T -t test "hello over TCP"
logger -n 203.0.113.50 -P 514 -d -t test "hello over UDP"

Both should appear in /var/log/remote/HOSTNAME/test.log on the log server. If nothing arrives, check the port with nc.

3. Forward logs from each server

1. Create /etc/rsyslog.d/90-forward.conf with your log server's address:

   *.* action(type="omfwd" target="203.0.113.50" port="514" protocol="tcp"
              queue.type="LinkedList" queue.filename="fwd514" queue.maxDiskSpace="1g"
              queue.saveOnShutdown="on" action.resumeRetryCount="-1")

   The queue holds messages while the log server is unreachable, up to 1 GB on disk. According to Red Hat, action.resumeRetryCount="-1" stops rsyslog from dropping messages while it retries. Local logging continues as before.
2. Check and restart: rsyslogd -N1 && systemctl restart rsyslog
3. Send a test: logger -t test "hello from $(hostname)". In our lab, logger -t tcptest "hello over TCP" on a server named web1 arrived in /var/log/remote/web1/tcptest.log as:

   2026-10-12T05:55:57+00:00 web1 tcptest: hello over TCP

Other forms we tested:

• UDP: *.* action(type="omfwd" target="203.0.113.50" port="514" protocol="udp")
• The old one-line form *.* @@203.0.113.50:514 (TCP) still works. According to rsyslog, a single @ means UDP.
• RELP: install rsyslog-relp on both sides. On the log server add module(load="imrelp") and input(type="imrelp" port="20514" ruleset="remote"); on the clients use:

  module(load="omrelp")
  *.* action(type="omrelp" target="203.0.113.50" port="20514"
             queue.type="LinkedList" queue.filename="fwdrelp" queue.maxDiskSpace="1g"
             queue.saveOnShutdown="on" action.resumeRetryCount="-1")

What happens when the log server is down

We stopped the log server, sent messages and started it again. With TCP and with RELP, all messages arrived within about half a minute of the restart. While the server was down, the sending side logged lines such as (shortened):

rsyslogd: cannot connect to 203.0.113.50:514 (took 0.00 seconds): Connection refused
rsyslogd: action 'action-0-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. ...
rsyslogd: action 'action-0-builtin:omfwd' resumed (module 'builtin:omfwd')

When we also restarted rsyslog on the sending server during the outage, it saved the queue to its work folder (fwd514.00000001 and fwd514.qi in /var/lib/rsyslog on AlmaLinux; Ubuntu uses /var/spool/rsyslog) and sent it after the restart. The first message written after the outage began was lost in that case, with TCP and with RELP. Avoid restarting rsyslog on your servers while the log server is down.

4. Rotate the collected logs

Create /etc/logrotate.d/remote on the log server. This is the AlmaLinux version, which reloads rsyslog the same way as the system's own rule:

/var/log/remote/*/*.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/systemctl reload rsyslog.service >/dev/null 2>&1 || true
    endscript
}

On Ubuntu and Debian, use /usr/lib/rsyslog/rsyslog-rotate as the postrotate line, as their /etc/logrotate.d/rsyslog does. Test with logrotate -d /etc/logrotate.d/remote. More in how to set up log rotation with logrotate.

Common problems

• Nothing arrives: test the port from the sending server with nc -zv -w 3 203.0.113.50 514 and read journalctl -u rsyslog on both sides.
• Remote logs also appear in /var/log/messages: the input is not bound to the ruleset. Check ruleset="remote" on every input line.
• Folders named after a DNS name or IP address: rsyslog uses the host name inside each message; when a device sends none or an invalid one, the sender's resolved name is used instead. Set proper names with hostnamectl set-hostname.
• SSH logins became slow: see slow SSH logins and an unreachable rsyslog server.

Official documentation: rsyslog omfwd module, imrelp module and Red Hat: configuring a remote logging solution.