4.4.1. Cloud Monitoring Alerts and Custom Metrics
💡 First Principle: Cloud Monitoring alerts exist to convert "a metric crossed a concerning threshold" into "a human or automated system was actually notified" — a metric silently breaching a threshold with nobody watching the dashboard provides zero operational value.
Creating Cloud Monitoring alerts based on resource metrics (CPU utilization, request latency, error rate) defines a condition and a notification channel (email, Slack, PagerDuty, and similar), so the right team is paged the moment a threshold is breached rather than discovering the problem from a customer complaint. Beyond Google's built-in metrics, creating and ingesting custom metrics lets an application or a log-based extraction process feed Cloud Monitoring with business-specific measurements (like "checkout completions per minute") that Google has no way of knowing about on its own.
⚠️ Exam Trap: A scenario describing a business-specific measurement — like "number of failed checkout attempts" — that isn't a resource-level metric Google Cloud already tracks, is testing whether you know custom metrics exist for exactly this gap, rather than trying to force a built-in infrastructure metric to represent something it wasn't designed to measure.
Reflection Question: An application team wants to alert when checkout failures exceed a threshold, but "checkout failures" isn't a metric Google Cloud tracks natively. What feature closes that gap?
