Cloud Monitoring

This chapter follows Cloud Logging and closes the Google Cloud Platform series. Cloud Monitoring (formerly Stackdriver) stores metrics, drives dashboards, uptime checks, and alerting policies, and supports service level objectives (SLOs) on supported services.

Cloud Run metrics

Cloud Run exports metrics automatically—no agent inside the container. Useful series in Metrics Explorer:

Metric	Meaning
`run.googleapis.com/request_count`	Traffic volume by response class
`run.googleapis.com/request_latencies`	Latency distribution
`run.googleapis.com/container/cpu/utilizations`	CPU use
`run.googleapis.com/container/memory/utilizations`	Memory use
`run.googleapis.com/container/instance_count`	Active instances

Filter by service_name file-api and location europe-west1.

Example MQL-style exploration starts in Metrics Explorer with resource type Cloud Run Revision and adds filters for your project.

Dashboards

Create a custom dashboard with charts for 5xx rate, p95 latency, and instance count. Share it with on-call rotation members.

Pin the load balancer backend latency chart when Cloud Armor and the external HTTPS LB front Run—correlate edge delays with Run latency.

Uptime checks

Uptime checks probe a public URL from multiple regions. Point one at the load balancer /health endpoint:

1
gcloud monitoring uptime create file-api-uptime \
2
  --resource-type=uptime-url \
3
  --host=YOUR_LB_HOST \
4
  --path=/health \
5
  --period=60

Failed checks feed alerting policies and SLO error budgets when configured.

Alerting policies

An alerting policy compares a metric to a threshold (or uses MQL) and notifies channels (email, Slack, PagerDuty):

1
# Prefer Console or Terraform for complex conditions; illustrative filter:
2
# filter: response_code_class=5xx

Start with alerts on:

Elevated 5xx rate on Cloud Run
Uptime check failures
Cloud Armor deny rate spikes (load balancer metrics)

Link alerts to runbooks that mention Logs Explorer queries from the previous chapter.

SLOs and error budgets

Define an SLO on availability or latency for the file-api service—for example 99.9% of requests succeed over 30 days. Monitoring tracks error budget burn; slow releases when budget is nearly exhausted.

SLOs work best when /health and critical paths are stable and logged consistently.

Series recap

You started with projects and IAM, published an image to Artifact Registry, ran it on Cloud Run with Cloud Storage, automated deploys with Cloud Build, tightened networking with VPC, protected the edge with Cloud Armor, and observed the stack with Logging and Monitoring.

For command quick reference, see the Google Cloud cheat sheet. Terms are defined in the Google Cloud glossary.