Rsyslog

Right, so you’ve got logs spewing out of every server like a firehose. You could try to read them by SSHing into each box and tailing files until your eyes bleed, but let’s be honest: that’s a special kind of masochism reserved for people who also enjoy assembling IKEA furniture without the instructions. The only sane way to make sense of this chaos is to get all those logs off the individual machines and into a central system—a SIEM, an Elasticsearch cluster, a cloud-based log aggregator, whatever. You need a single pane of glass, even if that glass is sometimes a little dirty.

Right, so journalctl is your new best friend and your worst critic, all wrapped into one. It’s the primary tool for reading the structured, indexed journal that systemd creates, and if you’re just running it naked, you’re doing it wrong. You’ll be buried in a firehose of data, from the very first boot message to the kernel’s latest hiccup. The power, and the point, is in the filters. Let’s talk about the ones you’ll use every single day.

Right, let’s talk about journald’s split personality when it comes to storage. This isn’t just some academic distinction; it dictates whether your precious logs vanish into the ether after a reboot or stick around for you to autopsy later. It’s the difference between a detective having a crime scene and just having a vague memory of what might have happened. By default, most distros ship with the journal stored only in memory (/run/log/journal/). This is the “volatile” storage. It’s fast, it doesn’t wear out your SSD with a million tiny writes, and it’s perfect for… well, for situations where you don’t care about logs after a reboot. I can’t think of many of those situations, but they must exist. The moment you shut down, poof—the journal is gone. It’s like a court reporter with amnesia.

Right, let’s talk about logrotate. You’re here because your disk space is screaming for mercy, or you’re just smart enough to know it will be soon. Log files are the digital equivalent of hoarding old newspapers; they just keep piling up until you can’t open the front door. logrotate is your friendly, automated cleanup crew. It’s not the flashiest tool, but it’s one of the most reliable workhorses in your sysadmin toolkit. It rotates, compresses, mails, and deletes log files according to rules you set. And it’s probably already installed on your system, silently doing its job for core services.

Right, let’s talk about /var/log. This is where your system’s diary lives, and like any good diary, it’s full of secrets, drama, and a meticulous record of everything that’s ever gone wrong. If your system starts acting weird, this is your first crime scene. Don’t just glance at it; learn to read it like a detective. The Lay of the Land First, a quick tour. The /var/log directory is the designated dumping ground, by convention and by the Filesystem Hierarchy Standard (FHS), for all log files. This is brilliant because it means you always know where to start looking. You’ll find everything from the kernel’s deepest mutterings (kern.log) to a user failing to log in for the tenth time (auth.log). The structure is mostly flat, which is both a blessing (simplicity) and a curse (a potential mess of hundreds of files). Some applications, being the special snowflakes they are, create their own subdirectories like /var/log/apt or /var/log/nginx, which is actually a decent practice.

Right, so you’ve got logs. Lots of them. They’re spewing out of your systems like confetti from a cannon, and right now they’re probably all just piling up in /var/log/syslog, which is about as useful as a screen door on a submarine. We need to bring order to this chaos, and rsyslog is our tool of choice. It’s the venerable workhorse of Linux logging, and it’s powerful enough to make you weep with joy or frustration, sometimes simultaneously. Forget the basic syslog; rsyslog is its modern, plugin-driven, über-powered descendant. Let’s bend it to our will.

Alright, let’s talk about syslog. You’ve seen those cryptic messages scrolling through your system logs, right? They’re not just random text vomit; they’re actually structured messages following one of the oldest and most widely adopted protocols in computing. It’s the duct tape and baling wire of logging—it’s everywhere, it’s ugly, but it gets the job done. The protocol itself, defined in RFC 5424, is a standard for message logging that allows different devices and software to send event notification messages across an IP network. But we need to start with the classic, original format to understand its soul.