DevOps
Monitoring
Collecting metrics — latency, error rate, saturation, traffic (the golden signals) — and alerting when they cross thresholds, visualised in dashboards like Prometheus and Grafana. It tells you something is wrong, ideally before users notice. The trap is alert fatigue: page only on symptoms that need human action, not on every blip.
Purpose
Monitoring collects numeric signals from systems — the four golden signals: latency, traffic, errors, saturation — graphs them, and alerts when thresholds break. Its job is to tell you something is wrong before users do, and to show at a glance whether the system is healthy.
When to Use It
Dashboards for services (request rate, p95/p99 latency, error percentage), infrastructure (CPU, memory, disk), and business pulses (signups, orders per minute). Alerting on symptoms — error rate, latency SLOs — pages a human only when action is needed.
Trade-offs
The failure mode is alert fatigue: pages for every CPU blip train responders to ignore alerts entirely, which is worse than no alerting. Averages also mislead — a fine mean latency hides a terrible p99 — so percentiles are the honest measure.
Implementation
Prometheus + Grafana is the standard open-source stack: services expose /metrics, Prometheus scrapes, Grafana visualises, Alertmanager routes pages. Alert on user-visible symptoms with runbook links, not on causes; track percentiles, not means; and review alert noise as seriously as you review code.