We manage a lot of servers at Canadian Web Hosting — shared hosting, VPS, dedicated, the works. When something breaks on one of them, the first thing we do is check the logs. But when you’re running five, ten, twenty servers, SSH’ing into each one to grep through /var/log/syslog gets old fast.

That’s the problem syslog-ng solves. It pulls logs from every server in your fleet into one central place. One search, one dashboard, one spot to check when something goes wrong at 2am. We’ve seen customers running 3-4 VPS instances waste hours hopping between machines during an outage — a central log server turns that into a five-minute diagnosis.

This guide covers a production-ready syslog-ng deployment on Ubuntu 24.04, including TLS transport for secure log forwarding, retention planning so your disk doesn’t fill up, and hardening steps to keep the log server itself from becoming a target.

What You’ll Need

For a central log server handling 5-20 source hosts:

  • Starter (5 hosts): 2 vCPU, 4 GB RAM, 80 GB NVMe — Cloud VPS VPS4
  • Fleet-scale (20+ hosts): 4 vCPU, 8 GB RAM, 160+ GB NVMe — Cloud VPS VPS5 or an E-Series Dedicated Server if you need bare-metal I/O and longer retention
  • OS: Ubuntu 24.04 LTS
  • SSH access as a sudo user
  • At least one client host to forward logs from
  • NTP/time sync enabled — critical for correlating events across hosts

Not sure about managing the log server yourself? Managed Support — our team can set up syslog-ng, configure TLS, and handle retention policies for you.

Why syslog-ng Over the Alternatives?

There are a few options for centralized logging. Here’s how they compare:

ToolBest ForOverhead
syslog-ngLinux fleet logging, SIEM intake, low-resource environmentsVery low (~30 MB RAM)
rsyslogAlready installed on most distros, simple forwardingVery low
Fluentd / Fluent BitContainer-heavy stacks, Kubernetes, structured JSON logsModerate
Grafana Loki + PromtailTeams already using Grafana for dashboardsHigher (needs Grafana stack)
ELK / OpenSearchFull-text search, analytics, compliance auditingHigh (4+ GB RAM minimum)

syslog-ng wins when you want low overhead, flexible routing, and compatibility with everything. It handles classic Linux syslog and modern structured formats, and it can forward to a SIEM later without re-architecting. If you’re running a stack of self-hosted apps, syslog-ng gives you one place to see what’s happening across all of them.

Step 1: Install syslog-ng

SSH into your central log server and install:

sudo apt update
sudo apt install -y syslog-ng-core syslog-ng-mod-json
sudo systemctl enable --now syslog-ng
sudo systemctl status syslog-ng --no-pager

The syslog-ng-mod-json module is optional but useful — it lets you parse and forward structured JSON logs alongside traditional syslog.

Step 2: Set Up Per-Host Log Directories

Edit /etc/syslog-ng/syslog-ng.conf and add a destination that organizes logs by hostname and date:

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

This creates a clean directory structure: /var/log/remote/webserver01/2026-03-10.log. When you need to investigate an incident, you know exactly where to look.

Step 3: Enable Network Ingestion

Configure syslog-ng to accept logs over TCP (more reliable than UDP — TCP guarantees delivery):

source s_net_tcp {
  tcp(ip("0.0.0.0") port(514)
      max-connections(100)
      log-iw-size(10000));
};

log {
  source(s_net_tcp);
  destination(d_remote);
};

The max-connections and log-iw-size settings prevent resource exhaustion if you suddenly get a flood of logs (which happens — a container restart loop can generate thousands of log lines per minute).

Step 4: Add TLS Encryption

Sending logs in plaintext across the network means anyone on the path can read them. For production, add TLS:

# Generate a self-signed cert (or use your own CA)
sudo mkdir -p /etc/syslog-ng/ssl
sudo openssl req -new -x509 -days 3650 -nodes \
  -out /etc/syslog-ng/ssl/server.crt \
  -keyout /etc/syslog-ng/ssl/server.key \
  -subj "/CN=logserver.yourdomain.com"
sudo chmod 600 /etc/syslog-ng/ssl/server.key

Then update the source to use TLS:

source s_net_tls {
  tcp(ip("0.0.0.0") port(6514)
      tls(key-file("/etc/syslog-ng/ssl/server.key")
          cert-file("/etc/syslog-ng/ssl/server.crt")
          peer-verify(optional-untrusted))
      max-connections(100));
};

log {
  source(s_net_tls);
  destination(d_remote);
};

Port 6514 is the standard for syslog-over-TLS (RFC 5425).

Step 5: Validate and Reload

sudo syslog-ng --syntax-only
sudo systemctl restart syslog-ng
sudo journalctl -u syslog-ng -n 50 --no-pager

Always run the syntax check first. A bad config will prevent syslog-ng from starting, and you’ll lose log ingestion until you fix it.

Step 6: Lock Down the Firewall

Your log server should only accept connections from known hosts. If you’ve already hardened your VPS, add these rules:

# Allow syslog-TLS from your server fleet (replace with your IPs)
sudo ufw allow from 10.0.0.0/24 to any port 6514 proto tcp comment "syslog-ng TLS"

# If you're still using plain TCP on 514, restrict it too
sudo ufw allow from 10.0.0.0/24 to any port 514 proto tcp comment "syslog-ng TCP"

# Deny everything else to the log ports
sudo ufw deny 514
sudo ufw deny 6514

If you’re using CSF (common on cPanel servers), add the allow rules to /etc/csf/csf.allow instead.

Step 7: Configure a Client to Forward Logs

On each server you want to collect logs from, install syslog-ng and add a forwarding destination:

# /etc/syslog-ng/conf.d/forward-to-central.conf

destination d_central {
  tcp("logserver.yourdomain.com" port(6514)
      tls(ca-file("/etc/syslog-ng/ssl/server.crt")));
};

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

Restart syslog-ng on the client, then check the central server:

ls -la /var/log/remote/
# You should see a directory for the client hostname

tail -f /var/log/remote/client-hostname/$(date +%Y-%m-%d).log

Step 8: Set Up Log Retention

Logs grow fast. Without retention, your disk will fill up. Add a logrotate config:

# /etc/logrotate.d/syslog-ng-remote
/var/log/remote/*/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        /usr/sbin/syslog-ng-ctl reload
    endscript
}

This keeps 90 days of compressed logs. Adjust based on your disk — on a 160 GB VPS, 90 days of logs from 10 hosts typically uses 15-30 GB depending on verbosity. If you need longer retention for compliance, consider a Dedicated Storage Server with multi-TB capacity.

Hardening Checklist

Your log server is a high-value target — it contains evidence of everything happening across your fleet. Lock it down:

  • Run syslog-ng as a non-root user — it only needs write access to /var/log/remote/
  • Use TLS — never send logs in plaintext across a network
  • Restrict SSH access — key-only, no password auth, fail2ban active
  • Monitor disk usage — set up an alert at 80% capacity
  • Separate log partition — mount /var/log/remote on its own partition so log growth can’t fill the root filesystem
  • Audit access — who can read the logs? Restrict to operators only
  • Back up the logs — a CloudSafe backup gives you offsite copies in case the log server itself is compromised

Troubleshooting

SymptomLikely CauseFix
No logs appearing from clientFirewall blocking port 514/6514Check ufw status and test with nc -zv logserver 6514
TLS handshake failedCertificate mismatch or expired certRegenerate cert, copy CA to client
Disk filling up fastVerbose app logging or missing logrotateCheck logrotate config, reduce retention, add disk
syslog-ng won’t startConfig syntax errorRun syslog-ng --syntax-only and fix the reported line
Duplicate log entriesMultiple log statements matching same sourceUse flags(final) on the first matching log path

What’s Next

Once your central log server is running, you can build on it:

  • Add alerting — pipe specific log patterns to email or Slack notifications
  • Forward to a SIEM — syslog-ng can feed Wazuh, Graylog, or Splunk without changing your client configs
  • Correlate with monitoring — pair log data with metrics from Uptime Kuma, Netdata, or Prometheus
  • Compliance auditing — 90-day log retention satisfies most SOC 2 and PCI requirements, which CWH’s managed security environment is already certified for

Centralized logging is one of those things that feels optional until the first time you actually need it. Set it up now while nothing is on fire — future you will be grateful.

Need a server to run this on? Canadian Web Hosting’s Cloud VPS with full root access and Canadian data centres. For larger fleets needing long-term retention, our Dedicated Storage Servers start at with up to 48 TB of disk. And if you’d rather have our team set up the whole logging pipeline for you, Managed Support.