Working with Logs

A log line is the smallest useful unit of observability: a timestamp, and what happened at that moment.

Log levels

Almost every logging library supports the same rough hierarchy, from least to most severe:

DEBUG  → INFO  → WARN  → ERROR → FATAL

In production, DEBUG is usually turned off entirely (too much noise, too much cost to store), INFO records normal operation worth keeping, and WARN/ERROR are what actually deserve a human's attention.

Structured logging

Compare these two lines:

User 42 logged in from 10.0.0.5 at 2026-01-04T10:02:00Z

{"event":"login","user_id":42,"ip":"10.0.0.5","ts":"2026-01-04T10:02:00Z"}

The second is structured (JSON): a machine can filter "every login from this IP" without fragile text parsing. Structured logging is slightly more ceremony to produce, but it's what makes centralized log search actually fast and reliable at any real scale.

Centralizing logs

A single server's logs are easy - just read the file. A hundred servers, each with their own local logs, is a different problem: you need every log shipped somewhere centralized, so "show me every error across the whole fleet in the last hour" is one query instead of a hundred SSH sessions.

Common stacks: the ELK stack (Elasticsearch, Logstash, Kibana) and Grafana Loki are two of the most widely used.

journald - the local starting point

On any systemd-based Linux host, journalctl is already capturing logs for every service, with no setup required - the natural first stop before anything gets shipped off to a centralized system:

journalctl -u nginx -n 20   # last 20 lines for the nginx unit
journalctl -u nginx -f      # follow new lines live

Try it

journalctl -u nginx -n 20

When you're ready, hit Mark complete and move to the next lesson.