Linux Log Management

Why Logs Matter

Logs are one of the first places you look when a Linux system or application behaves unexpectedly. They show service starts, authentication attempts, kernel events, web server requests, and application errors.

For DevOps engineers, log management is not only about reading files. It is also about knowing where logs live, how to filter them quickly, and how to prevent them from filling the disk.

The /var/log Directory

Traditional Linux log files are usually stored under /var/log.

Useful examples include:

• /var/log/syslog for general system messages on many Debian based systems
• /var/log/auth.log for authentication related events
• /var/log/kern.log for kernel messages
• /var/log/nginx/ for Nginx access and error logs
• /var/log/apache2/ for Apache logs

You can inspect the directory with:

ls /var/log
ls /var/log/nginx

Different distributions place logs differently, so learn the layout of the systems you operate.

Watching Logs Live with tail -f

One of the quickest ways to follow activity is tail -f.

tail -f /var/log/syslog
tail -f /var/log/nginx/access.log

This keeps the terminal open and streams new lines as they are written.

It is especially useful while restarting a service, testing a deployment, or reproducing an error.

Tip: Open one terminal to follow a log and another terminal to reproduce the issue. Seeing the event appear live often shortens troubleshooting time.

Filtering Logs with grep

Raw logs can be noisy. grep helps you focus on the lines you care about.

grep sshd /var/log/auth.log
grep ERROR /var/log/myapp.log
tail -f /var/log/syslog | grep nginx

You can combine tools to narrow large outputs into something meaningful. That is a core Linux troubleshooting skill.

Using journalctl for systemd Logs

On systemd-based systems, journalctl reads the system journal.

Show recent journal entries:

journalctl

Follow logs live:

journalctl -f

Show logs for a specific service:

journalctl -u nginx
journalctl -u sshd -f

Filter by time:

journalctl --since "1 hour ago"
journalctl --since "2026-07-14 09:00:00" --until "2026-07-14 10:00:00"

Filter by priority:

journalctl -p err
journalctl -p warning

journalctl is powerful because it organizes logs by service, time, boot, and priority rather than forcing you to search every file manually.

Note: Some systems use both traditional files in /var/log and the systemd journal. You should be comfortable with both approaches.

Managing Log Growth with logrotate

Without rotation, log files can grow until they waste disk space or even cause outages.

logrotate solves this by rotating old logs, compressing them, and deleting very old copies according to policy.

Typical configuration concepts include:

• rotate for how many archived files to keep
• compress for gzip compression of old logs
• daily, weekly, or monthly for rotation schedule
• missingok so missing logs do not cause failure
• notifempty so empty logs are not rotated

A simplified example config might look like:

cat /etc/logrotate.d/nginx

And you may see directives such as:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

This means Nginx logs are rotated daily, 14 old copies are kept, and archived logs are compressed.

A Practical Troubleshooting Flow

Suppose a web app returns errors after deployment. A sensible sequence is:

tail -f /var/log/nginx/error.log
journalctl -u myapp --since "15 minutes ago"
grep 500 /var/log/nginx/access.log

That helps you inspect the reverse proxy, the application service, and request outcomes together.

What You Should Remember

Linux log management starts with knowing where logs are stored and how to inspect them quickly. Use /var/log for traditional files, tail -f for live updates, grep for filtering, and journalctl for structured systemd logs.

Then use logrotate so logs stay useful instead of becoming a disk space problem.

Test Your Understanding

---

Frequently Asked Questions

Where are log files stored on Linux?

Under /var/log. The names vary by distribution: /var/log/syslog on Debian and Ubuntu holds general system messages, while RHEL-family systems use /var/log/messages. Authentication goes to /var/log/auth.log or /var/log/secure, and services keep their own directories such as /var/log/nginx/. On systemd distributions much of this is superseded by the journal, which is binary and read with journalctl rather than cat, so an empty-looking /var/log does not mean nothing is being logged.

What is the difference between journalctl and reading /var/log?

journalctl reads systemd's structured binary journal, which lets you filter by unit, priority, boot and time, journalctl -u nginx -p err --since today is one command where grep across plain files would be several. Files under /var/log are plain text written by rsyslog or by applications directly, and are what non-systemd services and most containers produce. Both usually coexist: use journalctl for anything systemd manages and the files for everything else.

How do I follow a log file in real time?

tail -f /var/log/syslog, or tail -F which survives the file being rotated out from under you. Worth preferring, since the plain -f silently follows a file nobody writes to any more after rotation. For systemd, journalctl -f, or journalctl -u myapp -f for one service. Combine with grep for a live filter: tail -F /var/log/nginx/access.log | grep " 500 ".

How do I stop logs filling the disk?

logrotate handles files: a config in /etc/logrotate.d/ sets how often to rotate, how many to keep and whether to compress, and logrotate -d /etc/logrotate.d/myapp does a dry run so you can check it. For the journal, set SystemMaxUse=500M in /etc/systemd/journald.conf, or clear it now with journalctl --vacuum-size=200M. Note that rotating a file a process holds open does not free space until that process reopens it, which is what copytruncate or a postrotate reload signal is for.

What do log priority levels mean?

Eight syslog severities, from 0 to 7: emerg, alert, crit, err, warning, notice, info, debug. journalctl -p err shows that level and everything more severe, which is the useful default when investigating. Most applications log at info in normal operation and can be turned up to debug temporarily. Worth remembering to turn it back down, since debug logging is a common cause of a disk filling overnight.

How do I find errors across all logs quickly?

Start with journalctl -p err -b, which shows every error-level message from the current boot across all units, usually the fastest way to see what is broken. Then narrow to a unit with -u. For plain files, sudo grep -ri "error" /var/log --include="*.log" | tail -50 casts a wide net, and adding -A 5 gives you the lines after each match, which is often where the actual cause is. Check timestamps against when the problem started rather than reading from the top.