3.2. Monitoring, Logging, and Observability

What happens when your production system fails silently? Without monitoring, you discover problems when customers complain. Without logging, you investigate blind. Without observability, you fix symptoms instead of root causes.

Think of monitoring and logging like a car's dashboard versus its diagnostic computer. The dashboard shows you speed and fuel level — enough to drive. But when the engine light comes on, you need the diagnostic computer to read error codes, check sensor history, and pinpoint the failing component. CloudWatch metrics are your dashboard; CloudWatch Logs, X-Ray traces, and Athena queries are your diagnostic computer.

Consider this scenario: CPU utilization spikes to 95% on a production instance. Is this a problem? It depends — 95% during a known batch job at 2 AM is normal. 95% at 10 AM on a Tuesday is an anomaly. Static threshold alarms can't tell the difference, but anomaly detection can. This section teaches you to build monitoring that understands context, not just numbers.

The trade-off is signal versus noise. More alarms mean faster detection but also more false positives — and alert fatigue kills incident response faster than any production bug. How do you find the balance? Through composite alarms, treat-missing-data configuration, and metric math that filters transient spikes from genuine incidents.