Observability on a Tight Budget: Structured Logs, Metrics, and Just Enough Tracing

The word observability is often equated with an expensive, complicated software stack. For a small team, most of the benefit can actually be had from three habits that require no extra infrastructure at all.

Structured logs, not sentences

Free-form log lines are easy to read one at a time and nearly impossible to analyse in aggregate. A question like "how many requests from this user failed in the past hour" requires fragile text searching.

Writing logs as JSON with consistent fields changes that completely. A single line holding a timestamp, severity, request ID, user ID and duration can be queried directly with simple command-line tools, even without an indexing service.

One rule is mandatory: never write passwords, tokens or card numbers to a log. Sanitisation has to happen in the logging layer, not be left to each caller's discipline.

A request ID that ties everything together

The second habit is generating a random identifier for every incoming request and including it on every log line produced while that request is handled.

The payoff comes when you are tracking down an error. A single user complaint with a request ID turns a search that eats up hours into one filter command. Showing the same identifier on the error page the user sees lets them report it without being asked.

Four metrics that are almost always enough

The temptation to record everything produces dashboards nobody ever opens. These four numbers catch most incidents: request rate, error rate, latency distribution, and saturation of resources such as memory or database connections.

For latency, use percentiles, not averages. Averages hide problems very effectively — a service with an 80-millisecond average can have a 99th percentile of four seconds, and the users hitting those four seconds are the ones writing the complaints.

Just enough tracing

Full distributed tracing is overkill for an application running on a single server. A simpler version still earns its keep: record the duration of each important stage within a request — database query time, external API calls, view rendering — and include them in a summary log at the end of the request.

A single line stating that a request took 1,200 milliseconds, 1,100 of them in one query, points straight at the cause, with no extra service required.

Alerts worth waking up for

Alerts that fire too often get ignored, and an ignored alert is as good as no alert at all. Restrict alerts to conditions that genuinely require someone to act right now.

A useful rule: if the person receiving the alert does not know what to do after reading it, that alert belongs on a dashboard, not in a message that wakes someone at midnight.