We get this question often from teams building centralized logging on a VPS: should we run rsyslog or syslog-ng? Both are mature, production-proven syslog daemons with decades of deployment history. But they differ meaningfully in configuration style, parsing capability, and how they handle complex routing pipelines.

If you have already explored the broader self-hosted logging landscape (Loki, ELK, Graylog, and more) and narrowed your choice down to a traditional syslog daemon, this guide will help you make the final call between rsyslog and syslog-ng based on real operational trade-offs — not marketing.

Logs often contain personally identifiable information (usernames, IPs, session tokens). If you operate in Canada, your log storage and retention practices fall under PIPEDA (the Personal Information Protection and Electronic Documents Act). Choosing a Canadian-hosted VPS means your log data stays within Canadian jurisdiction, which simplifies compliance. For a deeper look at why that matters, see our post on Canadian data residency.

Quick Answer (TL;DR)

Pick rsyslog if your team runs Debian, Ubuntu, or RHEL-family distributions and wants the path of least resistance. It is already installed on most Linux systems, has a massive module ecosystem, and handles high throughput well with its multi-threaded architecture.

Pick syslog-ng if you want a cleaner, more expressive configuration language, need advanced parsing (CSV, JSON, key-value) built in, or plan to build complex routing pipelines that split, filter, and transform logs at ingestion time. For a deeper dive, see our centralized logging with syslog-ng guide.

Neither choice is wrong. The right decision depends on your team’s operational habits and where you expect your log pipeline to grow.

Candidate Overview

rsyslog

Strengths: Default on most major Linux distributions (Debian, Ubuntu, RHEL, Rocky, Alma). Extremely high throughput — the multi-threaded message queue can handle hundreds of thousands of messages per second. Huge module library (omfwd, omelasticsearch, omhttp, omkafka, imfile, imjournal). Battle-tested at scale by large enterprises and hosting providers.

Limitations: The configuration language (RainerScript) can feel inconsistent, mixing legacy BSD-style lines with newer scripting blocks. Documentation is extensive but scattered. Complex filter chains can become hard to read and debug.

Best for: Teams that want to start quickly with what is already installed, environments where raw throughput matters, and shops already comfortable with rsyslog’s module system.

syslog-ng

Strengths: Clean, readable configuration syntax with a consistent source-filter-destination model. Built-in parsers for CSV, JSON, key-value pairs, and PatternDB. Strong typing and template functions make log enrichment straightforward. The Open Source Edition (OSE) is free; the Premium Edition adds commercial support and extras.

Limitations: Not installed by default on most distributions — requires adding it manually. Smaller community than rsyslog, so fewer third-party tutorials. Some advanced features (like the Kafka destination with guaranteed delivery) are Premium-only.

Best for: Teams that want cleaner config files, need built-in structured data parsing, or plan to build multi-tenant log routing from day one.

Feature Comparison

Feature rsyslog syslog-ng OSE
Default on major distros Yes (Debian, Ubuntu, RHEL) No (manual install)
Config language RainerScript + legacy BSD Consistent block syntax
Built-in JSON parsing Via mmjsonparse module Native json-parser()
CSV / KV parsing Limited (custom templates) Native csv-parser(), kv-parser()
Multi-threaded Yes (native) Yes (since 4.x)
Disk-assisted queues Yes Yes
TLS transport Yes (GnuTLS or OpenSSL) Yes (OpenSSL)
Elasticsearch output omelasticsearch module elasticsearch-http() destination
Kafka output omkafka module kafka() destination (OSE)
PatternDB / classification No native equivalent Yes (PatternDB)
Licence GPL v3 LGPL v2.1 (OSE) / Commercial (PE)

Decision Guide

If your scenario is… Choose Because
Standard Ubuntu/RHEL VPS, small team, just need centralized logs fast rsyslog Already installed; minimal setup, proven defaults
Multi-tenant environment with per-customer log routing syslog-ng Filter-destination model maps cleanly to tenant isolation
Need to parse JSON or structured app logs at ingestion syslog-ng Native json-parser() and kv-parser() without extra modules
Very high message volume (100k+ msg/sec) rsyslog Mature multi-threaded queue engine, proven at extreme scale
Team prefers readable, self-documenting config files syslog-ng Consistent block syntax is easier to review and maintain
Forwarding logs to Elasticsearch, Kafka, or Loki Either Both have solid output modules for major backends
Compliance logging (PIPEDA, SOC 2) with immutable retention Either Both support TLS, file permissions, and retention policies

Hosting Requirements

Workload rsyslog syslog-ng OSE Notes
Light (1-5 hosts, <1k msg/sec) 1 vCPU / 1 GB RAM 1 vCPU / 1 GB RAM 40 GB SSD minimum for 30 days retention
Medium (5-20 hosts, 1k-10k msg/sec) 2 vCPU / 4 GB RAM 2 vCPU / 4 GB RAM 80 GB NVMe; enable disk-assisted queues
Heavy (20-100 hosts, 10k-100k msg/sec) 4 vCPU / 8 GB RAM 4 vCPU / 8 GB RAM 160+ GB NVMe; TLS adds ~15% CPU overhead
Enterprise (100+ hosts, 100k+ msg/sec) 8 vCPU / 16 GB RAM 8 vCPU / 16 GB RAM Consider dedicated server for sustained loads

Installation

On Ubuntu 24.04, rsyslog is already installed. For syslog-ng, you will need to add it manually:

# rsyslog (already installed on Ubuntu/Debian/RHEL)
sudo apt update && sudo apt install rsyslog -y
sudo systemctl enable rsyslog && sudo systemctl start rsyslog

# syslog-ng OSE
sudo apt update && sudo apt install syslog-ng -y
sudo systemctl enable syslog-ng && sudo systemctl start syslog-ng

On RHEL/Rocky/Alma, rsyslog is the default. For syslog-ng, enable the EPEL repository first:

# RHEL/Rocky 9
sudo dnf install epel-release -y
sudo dnf install syslog-ng -y

Configuration Examples

rsyslog: Forward All Logs to a Central Server via TCP

Edit /etc/rsyslog.d/50-forward.conf on each client:

# Forward all logs to central rsyslog server over TCP
*.* action(
    type="omfwd"
    target="logserver.example.com"
    port="514"
    protocol="tcp"
    queue.type="LinkedList"
    queue.filename="fwd_queue"
    queue.maxdiskspace="500m"
    queue.saveonshutdown="on"
    action.resumeRetryCount="-1"
)

On the central server, enable TCP reception in /etc/rsyslog.conf:

# Load TCP input module
module(load="imtcp")
input(type="imtcp" port="514")

# Write logs per-host, per-day
template(name="RemoteLogs" type="string"
    string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

*.* ?RemoteLogs
& stop

syslog-ng: Forward All Logs to a Central Server via TCP

Edit /etc/syslog-ng/conf.d/forward.conf on each client:

# Client: forward everything to central syslog-ng server
destination d_central {
    tcp("logserver.example.com"
        port(514)
        disk-buffer(
            mem-buf-size(100M)
            disk-buf-size(500M)
            reliable(yes)
            dir("/var/syslog-ng-buffer")
        )
    );
};

log {
    source(s_src);
    destination(d_central);
};

On the central server, configure /etc/syslog-ng/conf.d/central.conf:

# Server: receive and store per-host logs
source s_network {
    tcp(port(514));
};

destination d_hosts {
    file("/var/log/remote/${HOST}/${YEAR}-${MONTH}-${DAY}.log"
        create-dirs(yes)
        owner("root")
        group("adm")
        perm(0640)
    );
};

log {
    source(s_network);
    destination(d_hosts);
};

Security and Compliance

Logs contain sensitive data. On a VPS, you control the full stack, which means security is your responsibility. Here is a checklist that applies to both rsyslog and syslog-ng:

  • Use TCP + TLS for transport. Both daemons support TLS natively. Never send logs in plaintext over the public internet.
  • Restrict listener access. Allowlist source IP ranges using firewall rules (iptables, nftables, or your VPS provider’s firewall). Do not expose syslog ports publicly.
  • Set strict file permissions. Log files should be owned by root with mode 0640 or tighter.
  • Define retention policies. Operational logs might keep 30 days. Compliance logs (PIPEDA, SOC 2) may require 1-7 years. Automate rotation with logrotate or syslog-ng’s built-in log rotation.
  • Offsite backups. Critical security logs should be copied to a separate location — an object store or a second VPS — so they survive if the primary node is compromised.
  • Monitor disk growth. Alert before 80% usage. A full disk means dropped logs.

If your organization falls under Canadian privacy legislation, storing logs on a Canadian-hosted VPS keeps your data under Canadian jurisdiction and avoids cross-border data transfer questions under PIPEDA.

Monitoring and Visualization

Neither rsyslog nor syslog-ng include a built-in dashboard. For visualization, forward logs to a backend like Elasticsearch, Loki, or Graylog and view them through Grafana or Kibana. If you are exploring that stack, our Grafana stack guide covers how the pieces fit together, and our self-hosted monitoring overview covers the broader monitoring ecosystem.

Operational Mistakes to Avoid

  • No queue strategy: Log bursts during incidents can overwhelm a receiver. Both tools support disk-assisted queues — configure them before you need them.
  • No schema plan: Inconsistent hostnames and app labels make searching painful. Standardize naming conventions across all hosts from day one.
  • Choosing by brand: Start from your ingestion volume, retention requirements, and team skill set — not from blog hype.
  • No failure drills: Test what happens when the central server is down, when disk fills up, and when a client floods logs. Do this quarterly.
  • Ignoring log rotation: Without rotation and compression, even a small environment can fill a disk in weeks. Automate it.

Our Recommendation

For most small-to-mid teams running VPS infrastructure, start with rsyslog. It is already on your server, it handles the common use cases well, and you can have centralized logging running within an hour. If your needs grow toward structured parsing, multi-tenant routing, or complex pipelines, evaluate syslog-ng on a staging node — the migration path is straightforward since both speak standard syslog.

Whichever daemon you choose, invest more effort in transport security (TLS), retention policy, and log structure than in the daemon itself. Those decisions will have a bigger long-term impact than which binary processes the messages.

If you want a managed environment where our team handles the underlying infrastructure while you focus on your logging pipeline, check out our managed support plans. And when your log volumes grow, a Cloud VPS from Canadian Web Hosting gives you the NVMe storage, predictable networking, and Canadian data residency to run centralized logging properly.