monitoring-alertinglisted

# Monitoring & Alerting Monitoring tells you what is happening. Alerting tells you when something is wrong. They answer: "is the system healthy, and how do I know?" ## Three pillars Logs (what happened), metrics (how much, how fast), traces (where did it go). Each answers a different question. Logs without metrics are a diary without a calendar. Metrics without traces are a speedometer without a map. ## Alert on symptoms, not causes "High error rate" is an alert. "CPU > 80%" is a cause. Alert on what the user experiences, not on what the infrastructure does. A user cannot feel CPU. ## SLIs and SLOs Service Level Indicators measure what matters (latency p95, error rate, availability). Service Level Objectives set the threshold. Alert when the SLO is about to breach, not when a metric crosses an arbitrary line. ## Alert fatigue Every alert that doesn't require action trains the responder to ignore alerts. If an alert has fired 10 times and no one has been paged at 3am, it's not an alert — it's a log entry with ambition. ## Dashboards A dashboard is a hypothesis, not a report. What question does it answer? "Is the system healthy?" — one row. Not "here are 40 graphs I might look at someday."