Logs, metrics and alerts
Intermediate
12 min read
See what production is doing, and be told when it needs you — before users have to.
Why it matters
Once software is live you cannot attach a debugger. Logs tell you what happened, metrics show trends, traces follow one request across services, and alerts wake someone only when users are affected.
Where it fits — Observability applies across these stages
What you will learn
- Write useful, structured log lines without sensitive data.
- Pick a few metrics that show whether users are served well.
- Alert on symptoms users feel, not on every warning.
Before you start
- Nginx as a reverse proxy✓ Learned
Three signals
- Logs — individual events with context: what happened, to which request, with which error.
- Metrics — numbers over time: requests per second, error rate, response time, queue length.
- Traces — the path of one request through several services, with the time spent in each.
Example
{"time":"2026-10-23T09:14:02Z","level":"error","request_id":"7f3a","route":"/api/orders","status":500,"message":"payment provider timeout"}Alerts people trust
Start with the symptoms users feel: errors, slow responses, the site being unreachable. Every alert should need a human action; an alert that is always ignored teaches people to ignore all of them.
- Errors and slow requests are visible on one dashboard.
- Someone is alerted when the error rate or response time stays high.
- Backups run, and a restore has been tested.
Official documentation and references
Documentation
- Prometheus overview ↗ Official · Prometheus
- OpenTelemetry documentation ↗ Official · OpenTelemetry
Guides
- Monitoring Distributed Systems ↗ Google SRE book — Where the "four golden signals" come from.
Learn next
- Incident response ›✓ Learned
Related topics
- Nginx as a reverse proxy✓ Learned
- Backups and recovery✓ Learned
- Configuration and secrets✓ Learned
Done with this topic?
Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.