TopolearnYou want to hear about problems from an alert, not from your users.
Cloud Monitoring stores time series metrics. Google services publish hundreds automatically (e.g. run.googleapis.com/request_count, compute.googleapis.com/instance/cpu/utilization); VMs need the Ops Agent for memory and disk metrics; you can add custom metrics, log-based metrics, and Prometheus metrics via Managed Service for Prometheus. Metrics Explorer and dashboards visualise them; PromQL works in queries.
A metric query has a filter (metric and resource type, labels), an aligner that turns raw points into regular intervals per series (ALIGN_RATE, ALIGN_MEAN, percentiles) and a reducer that combines series (REDUCE_SUM across all revisions).
An alerting policy contains one or more conditions (threshold, metric absence, or a PromQL or log match) and notification channels: email, SMS, Slack, PagerDuty, webhooks, Pub/Sub. The condition's duration avoids alerting on a single spike.
Uptime checks probe HTTP(S) or TCP endpoints from several regions worldwide and can alert when a site is down from the outside.
Mature teams alert on SLOs rather than raw CPU: define a service-level indicator (fraction of good requests, latency under a threshold), a target such as 99.9% over 28 days, and alert on burn rate, i.e. how fast the error budget is being spent.
Example
cat > policy.yaml <<'EOF'
displayName: orders-api 5xx rate
combiner: OR
conditions:
- displayName: 5xx above 1 per second for 5 minutes
conditionThreshold:
filter: >-
resource.type = "cloud_run_revision" AND
resource.labels.service_name = "orders-api" AND
metric.type = "run.googleapis.com/request_count" AND
metric.labels.response_code_class = "5xx"
aggregations:
- {alignmentPeriod: 60s, perSeriesAligner: ALIGN_RATE, crossSeriesReducer: REDUCE_SUM}
comparison: COMPARISON_GT
thresholdValue: 1
duration: 300s
notificationChannels: [projects/shop-dev-4821/notificationChannels/1234567890]
EOF
gcloud monitoring policies create --policy-from-file=policy.yamlRemember
- Aligners regularise each series; reducers combine series
- Alerts = conditions + duration + notification channels
- Uptime checks test from outside; SLO burn-rate alerts beat CPU alerts
Watch out for
- Alerting on every CPU spike with no duration, which trains everyone to ignore alerts.