Logging & System Monitoring
The problem
When something goes wrong on a running system, you usually aren't watching it happen live — logs are the durable record of what a system did, and monitoring tools show its current resource state, together turning 'something broke, no idea why' into a diagnosable trail of evidence.
Why now
File systems & I/O already covered persistent storage generally; logging is that storage applied specifically to recording events over time. CPU scheduling already covered how the system allocates resources; monitoring is how you observe that allocation happening in practice, in real time.
Mental model
A log is an append-only file — read file-systems-and-io's persistence idea, specialized to 'never overwrite, only add,' so history is preserved for later inspection. Monitoring tools are just periodic snapshots of scheduling and memory state (which process is using how much CPU, right now), the practical, observable face of decisions cpu-scheduling makes constantly and invisibly.
Requires
- File Systems & I/OOperating Systems
Logs are files, written incrementally via the same I/O operations already covered, with the specific append-only discipline that makes them a reliable historical record.
- CPU SchedulingOperating Systems
System monitoring tools (top, htop) display exactly the scheduling and resource-allocation state cpu-scheduling describes — CPU share, run queue length — made observable in real time.
Unlocks
Used in
- Incident response — reading logs to reconstruct what happened before a failure
- journalctl and syslog as the standard logging infrastructure on most Linux systems
- Resource monitoring dashboards (Grafana, Datadog) built on the same underlying OS metrics
- Log rotation, preventing logs from silently consuming all available disk space
Projects
- Use journalctl or tail -f to follow a live log stream while triggering the event it should record, and confirm it appears
- Set up basic log rotation for a growing log file and explain why unmanaged logs are a real operational risk
Examples
- tail -f /var/log/nginx/access.log shows requests hitting a web server in real time as they happen
- A disk-full outage is often caused by an unrotated log file that grew unbounded over months
Resources
Mastery checklist
- I can follow a live log file and correlate entries with real events
- I can use a system monitoring tool to identify current CPU and memory usage
- I can explain why log rotation is necessary for long-running systems
- I can locate and read the relevant system logs after a simulated failure