Complete Guide: How to Set Up a Centralized Log Server with Rsyslog

Why centralizing logs is essential for your infrastructure

In environments with multiple Linux servers — whether physical, virtualized on Proxmox, or cloud instances — one of the biggest operational challenges is visibility. When an incident occurs, the time lost logging into each server individually to hunt for error messages is time your team does not have, especially in critical environments such as healthcare data centers or industrial infrastructure.

A log aggregation server solves this problem by centralizing everything in a single point, allowing:

• Event correlation across multiple servers during an incident

• Centralized retention and auditing, essential for compliance (LGPD, ISO 27001)

• Log survival even if the source server is compromised or destroyed

• Centralized alerts integrating with tools such as Zabbix, Grafana, or LLM analysis pipelines

• Operational noise reduction, with a single location for dashboards and searches

In this guide we will build, from scratch, a central log server using rsyslog, the standard system logging tool in virtually all enterprise Linux distributions (RHEL, Oracle Linux, Ubuntu, Debian).

Solution architecture

┌─────────────────┐     TCP/UDP 514      ┌──────────────────────┐
│  Servidor Web     │ ────────────────►   │                      │
├─────────────────┤                      │                      │
│  Servidor Oracle  │ ────────────────►   │   Servidor Central    │
├─────────────────┤     TLS 6514          │   Rsyslog             │
│  Servidor AD/DC   │ ────────────────►   │   /var/log/clients/   │
├─────────────────┤                      │                      │
│  Firewall/Proxy   │ ────────────────►   │                      │
└─────────────────┘                      └──────────────────────┘

Each client server sends its logs over the network to the central server, which organizes them in directories separated by hostname, applying configurable rotation and retention.

1. Preparing the central server

A dedicated machine (physical or VM) is recommended, with resources proportional to the expected log volume. For small and medium environments (up to ~30 client servers), a VM with 2 vCPUs, 4 GB of RAM, and a separate disk for /var/log (ideally on a ZFS pool or LVM with room to grow) is sufficient.

1.1 Installing rsyslog

On most RHEL/Oracle Linux-based distributions, rsyslog is already installed by default. To ensure the latest version:

# Oracle Linux / RHEL / CentOS
sudo dnf install -y rsyslog rsyslog-relp

# Debian / Ubuntu
sudo apt update
sudo apt install -y rsyslog rsyslog-relp

Check the installed version (8.x or higher recommended for full TLS and RELP support):

rsyslogd -v

1.2 Enabling the service

sudo systemctl enable rsyslog
sudo systemctl start rsyslog
sudo systemctl status rsyslog

2. Configuring the central server to receive logs

The main configuration file is /etc/rsyslog.conf, but best practice is to create separate files in /etc/rsyslog.d/ to keep everything organized and facilitate future maintenance.

2.1 Enabling the reception modules

Create the file /etc/rsyslog.d/00-listen.conf:

sudo nano /etc/rsyslog.d/00-listen.conf

Content:

# Módulo para receber via UDP (mais leve, porém sem garantia de entrega)
module(load="imudp")
input(type="imudp" port="514")

# Módulo para receber via TCP (recomendado, com garantia de entrega)
module(load="imtcp")
input(type="imtcp" port="514")

# Aumenta o limite de conexões TCP simultâneas
$MaxOpenFiles 65536
$InputTCPServerMaxSessions 500

Technical note: for critical environments, always prefer TCP over UDP. UDP does not guarantee delivery of packets — in case of traffic peaks or network saturation, you may lose important events without any warning.

2.2 Organizing logs by source server (dynamic template)

One of the biggest mistakes in centralized log servers is dumping everything into a single /var/log/messages file, mixing events from dozens of different servers. The correct practice is to use dynamic templates to separate by hostname and date.

Create the file /etc/rsyslog.d/10-templates.conf:

# Template que organiza logs por hostname/ano-mes/dia
template(name="DynamicFile" type="string"
  string="/var/log/clients/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

# Aplica o template a tudo que não seja do próprio servidor local
if $fromhost-ip != '127.0.0.1' then {
  action(type="omfile" dynaFile="DynamicFile")
  stop
}

This rule ensures that:

• Logs from the central server itself continue to go to /var/log/messages normally

• Logs received over the network are written to /var/log/clients/<hostname>/<data>.log

• The stop prevents the message from also being duplicated in the central server's local logs

Create the base directory with correct permissions:

sudo mkdir -p /var/log/clients
sudo chown syslog:adm /var/log/clients   # Debian/Ubuntu
# or
sudo chown root:root /var/log/clients    # RHEL/Oracle Linux
sudo chmod 750 /var/log/clients

2.3 Restarting the service

sudo systemctl restart rsyslog
sudo ss -tulpn | grep 514

You should see rsyslog listening on ports 514 (TCP and UDP).

3. Configuring client servers (sending logs)

On each Linux server that should send logs to the central server, create the file /etc/rsyslog.d/90-forward.conf:

sudo nano /etc/rsyslog.d/90-forward.conf

Content (replace with the real IP or hostname of your central server):

# Envio via TCP com buffer em disco em caso de falha de rede (recomendado)
$ActionQueueFileName fwdQueue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1

*.* @@srv-logs.nyverra.local:514

Note the use of @@ (double at sign), which indicates sending via TCP. A single @ would indicate UDP.

The queue directives (ActionQueue*) ensure that, if the network goes down or the central server becomes unavailable, logs are stored locally on disk and automatically resent when the connection is re-established — avoiding event loss during maintenance or network instability.

Restart rsyslog on the client:

sudo systemctl restart rsyslog

3.1 Testing the sending

On the client, generate a test message:

logger "Teste de envio de log centralizado - $(hostname)"

On the central server, check that the message arrived:

tail -f /var/log/clients/<hostname-do-cliente>/*.log

4. Security: encrypting transport with TLS

Sending logs in plain text over the network is a risky practice, especially if traffic passes through shared network segments or WAN. Logs often contain sensitive information (login attempts, internal IPs, application data).

4.1 Generating certificates

For internal environments, you can use your own CA (recommended) or reuse your existing PKI infrastructure. Simplified example with OpenSSL:

# No servidor central, gerando uma CA própria para os logs
sudo mkdir -p /etc/rsyslog.d/certs
cd /etc/rsyslog.d/certs

openssl genrsa -out ca-key.pem 4096
openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=Nyverra-Log-CA"

# Certificado do servidor
openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -out server.csr \
  -subj "/CN=srv-logs.nyverra.local"
openssl x509 -req -days 365 -in server.csr -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem

Distribute ca-cert.pem to all clients that will send logs.

4.2 Configuring TLS on the central server

Add to /etc/rsyslog.d/00-listen.conf:

module(load="imtcp"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="anon")

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca-cert.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/server-key.pem"
)

input(type="imtcp" port="6514")

4.3 Configuring TLS on the client

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca-cert.pem"
)

action(type="omfwd"
  target="srv-logs.nyverra.local"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="anon"
)

Restart rsyslog on both sides and validate encrypted traffic with tcpdump (content should be unreadable, unlike port 514 without TLS).

5. Firewall and port opening

Do not forget to open the ports on the central server's firewall. Example with firewalld (RHEL/Oracle Linux):

sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=6514/tcp   # se estiver usando TLS
sudo firewall-cmd --reload

With ufw (Debian/Ubuntu):

sudo ufw allow 514/tcp
sudo ufw allow 514/udp
sudo ufw allow 6514/tcp

If there is a perimeter firewall (pfSense, Fortinet) between the servers, ensure that the opening rules are made only between specific management networks/VLANs — never expose the log reception ports to public or untrusted networks.

6. Log rotation and retention

With multiple servers sending logs continuously, the central server's disk can grow quickly. Configure logrotate to manage this automatically.

Create /etc/logrotate.d/rsyslog-clients:

/var/log/clients/*/*.log {
    daily
    missingok
    rotate 90
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate 2>/dev/null || true
    endscript
}

This example keeps 90 days of history with compression, a reasonable balance between disk space and audit needs. Adjust rotate according to the retention policy required by your industry (hospitals and clinics, for example, often have longer retention requirements due to audits).

7. Going further: Zabbix integration and intelligent analysis

After the logs are centralized, the next natural step is to turn this raw data into operational intelligence:

• Zabbix can monitor log files via log[] items or consume alerts generated from specific patterns (authentication failures, application errors, critical disk usage)

• Elasticsearch + Kibana or Grafana Loki can be used as a search and visualization layer on top of the logs already centralized by rsyslog, without sacrificing the simplicity and reliability of rsyslog as the transport layer

• Automated analysis pipelines (via LLM or rules) can consume these logs to generate daily incident summaries, reducing manual triage time for the infrastructure team

Final deployment checklist

• Rsyslog installed and updated on the central server and all clients
• TCP reception enabled (preferably with TLS in production)
• Dynamic templates configured to separate logs by hostname/date
• Local relay queue configured on clients (`ActionQueue*`)
• TLS certificates generated and distributed, if applicable
• Ports opened only on management networks, never publicly
• Logrotate configured with retention policy appropriate for your industry
• Failover test: temporarily disconnect the client's network and validate that logs are not lost

Conclusion

Setting up a log aggregation server with rsyslog is a relatively simple investment, using native Linux tools, that brings a huge return in incident response capability, auditing, and compliance. For B2B environments — especially in regulated sectors such as healthcare and industry — this centralization is not just a good technical practice, it is often a compliance requirement.

At Nyverra, we help companies structure this type of observability infrastructure solidly and tailored, whether in on-premise environments, virtualized on Proxmox, or hybrid. If your company does not yet have a log centralization strategy, this is a great starting point.

Need help implementing this architecture in your company? Talk to the Nyverra team.