The Struggle of Hopping Between Servers to Find Logs
When I first started my career, I managed about 5 VPS instances running web services. Whenever an error occurred, the process was frustratingly repetitive: SSH into Server 1, run tail -f, find nothing, exit, and move to Server 2. While manageable with 5 servers, as the system scales to 20-30 nodes including switches and routers, this approach becomes a complete productivity disaster.
Even more critical is the security risk. If a hacker breaches your system and wipes the traces in /var/log/, or if a server suffers a sudden hardware failure, you’ll be completely in the dark regarding the cause. That was when I realized a Centralized Logging system—perhaps paired with Logwatch to summarize reports—is no longer optional—it’s mandatory.
Why Do You Need a Centralized Log Repository?
The biggest issue is data fragmentation. Imagine an error from a Load Balancer triggering issues in the Web App and Database. Correlating events across different timelines is a nightmare if you can’t view them in a single place.
Furthermore, storing logs locally often leads to disk space exhaustion. Just one service caught in an error loop, logging continuously, can consume 10-20GB of space in hours, causing the entire server to hang, requiring you to perform a deep cleaning Ubuntu regularly.
Rsyslog: The Lightweight and Efficient Solution
There are many log management tools available today for effortless server management, each serving different needs:
- Cloud Solutions (Datadog, Splunk): Extremely powerful features, but the monthly bill can reach thousands of dollars for high log volumes.
- ELK Stack (Elasticsearch, Logstash, Kibana): Professional and fast searching, but extremely resource-heavy. A basic ELK cluster needs at least 8GB of RAM to run stably.
- Rsyslog: Built-in on Ubuntu, extremely lightweight (consuming only about 10-20MB of RAM), and simple to configure.
Step 1: Configuring the Rsyslog Server (Receiver)
Assume your Log Server has the IP 192.168.1.100. The first step is to open the ports to receive logs from other machines.
Open the configuration file using the following command:
sudo nano /etc/rsyslog.conf
Find and uncomment the following lines. I recommend enabling both UDP (for speed) and TCP (to ensure no log loss):
# Receive logs via UDP
module(load="imudp")
input(type="imudp" port="514")
# Receive logs via TCP
module(load="imtcp")
input(type="imtcp" port="514")
To prevent logs from 50 different servers from dumping into a single syslog file and causing chaos, we will categorize them. Add this template section before the GLOBAL DIRECTIVES part:
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& ~
This line instructs Rsyslog to automatically create directories based on the hostname and files based on the application name. The & ~ tag is crucial; it tells the system to stop processing the log after writing it to the template, preventing logs from being duplicated into local system files.
Restart the service and open the firewall:
sudo systemctl restart rsyslog
sudo ufw allow 514/udp
sudo ufw allow 514/tcp
Step 2: Configuring the Rsyslog Client (Sender)
On the client machines, the configuration is minimal. You just need to redirect logs to the central server.
sudo nano /etc/rsyslog.conf
Add this line to the end of the file (use one @ for UDP, two @@ for TCP):
*.* @@192.168.1.100:514
Then restart the service: sudo systemctl restart rsyslog.
Step 3: Verifying the Results
On the Log Server, check the /var/log/remote/ directory. You should see directories named after the client hostnames appearing immediately.
ls /var/log/remote/
Managing Storage with Logrotate
Consolidating logs in one place without cleaning them up will soon lead to a full hard drive. With about 10 servers sending logs continuously, you could lose several GBs of space daily. We will use logrotate to compress and delete old logs.
Create a new configuration file:
sudo nano /etc/logrotate.d/remote-logs
Use the following content:
/var/log/remote/*/*.log {
daily
missingok
rotate 30
compress
notifempty
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
This configuration rotates logs daily, keeps the 30 most recent copies, and compresses them. You can save up to 90% of storage space thanks to this compression, which is a great way to speed up Ubuntu disk cleanup.
Crucial Lessons from the Field
- Security First: Syslog is unencrypted by default. As part of automating Ubuntu server hardening, always use a VPN (like WireGuard) or configure TLS if sending logs over the Internet. Never expose port 514 to the public Internet.
- Time Synchronization: Install NTP on all servers. If time zones or clocks are out of sync, investigating errors across servers will become an inescapable maze.
- Filter at the Source: If an application logs too many junk messages (debug logs), configure filtering directly on the client machine to save bandwidth.
Building a Syslog Server is the first step toward professional system administration. It not only makes debugging easier but also serves as the foundation for building future Alerting systems.

