Reading and centralising server logs
Kort antwoord
On Linux, authentication attempts land in /var/log/auth.log or /var/log/secure, general system messages in /var/log/syslog or via journalctl on systemd distributions, and most applications keep their own logs under /var/log/<application>/. On Windows, the same information lives in Event Viewer, or is queryable from PowerShell with Get-WinEvent or Get-EventLog. Once you're running more than a server or two, centralising those logs somewhere off the servers themselves is what makes it possible to actually investigate an incident.
Every server keeps its own record of what happened on it, but where that record lives, and how long it survives, differs by operating system. Knowing where to look is the first half of the problem. The second half is what happens once you have more than one server: local logs alone stop being enough.
Where to look on Linux
| Log | Typical location | What it holds |
|---|---|---|
| Authentication | /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL-family) | SSH logins, sudo usage, authentication failures |
| General system messages | /var/log/syslog, or journalctl on systemd-based distributions | Kernel messages, service start/stop events, general system activity |
| Application logs | Typically under /var/log/<application>/, for example /var/log/nginx/ | Whatever the individual application chooses to log, format varies by application |
On a systemd-based distribution, journalctl is usually the fastest way in, it covers boot messages, service output, and kernel logs in one place, and can be filtered by service, time range, or priority. On older or non-systemd systems, the equivalent information is spread across the plain-text files under /var/log/ instead.
Where to look on Windows
Windows centralises most of this in Event Viewer, organised into logs such as Application, Security, and System. For anything you want to search, filter, or script against, PowerShell is usually quicker than clicking through the Event Viewer interface:
Get-WinEventis the modern cmdlet, works against the newer structured event log format, and supports filtering by log name, event ID, and time range.Get-EventLogis the older cmdlet, still common in existing scripts, and works against the classic event logs.
Either approach gets you the same underlying events that Event Viewer shows, just in a form you can filter, export, or feed into another tool.
Why centralising logs matters once you have more than one or two servers
Reading logs on a single server is manageable. The problem shows up once an incident spans more than one machine, which is most incidents that matter. If each server's logs only exist locally, correlating what happened across several of them, in the right order, at the right times, is nearly impossible: you're logging into each one separately, comparing timestamps by hand, and hoping none of the relevant entries have already rotated away. Most systems only keep local logs for a matter of days before rotating or deleting older entries, so by the time you notice a problem, some of the evidence may already be gone.
A central log platform addresses both problems at once. Logs from every server are shipped somewhere else as they're generated, so they stay searchable across the whole fleet from one place, they can be retained for as long as you choose rather than however long local rotation allows, and, critically, they survive even if the server that generated them goes down entirely or is compromised. That last point matters particularly for incident investigation: if an attacker has control of a server, local logs on that same server are not something you can trust, logs that were already shipped elsewhere before the compromise are.
The general pattern for shipping logs centrally
The mechanics vary by tooling, but the underlying pattern is consistent: a lightweight agent or forwarder runs on each server, watches the relevant log sources, and ships new entries to a central destination as they appear, rather than waiting for someone to go and collect them. That destination is typically built to handle full-text search, retention policies, and dashboards or alerting on top of the incoming log stream. This is a pattern, not a specific product, the right tool depends on your existing stack and how much log volume you're dealing with. Accurate timestamps across every server matter a great deal here too, correlating events across machines only works if their clocks agree, see Why accurate server time matters (NTP basics).