Cloud Monitoring: Metrics, Dashboards, Uptime Checks and the Ops Agent

GCP Basics · Operations – Cloud Monitoring, Alerting, Cloud Logging and Audit Logs · Lesson 1 of 5

Cloud Monitoring collects metrics from Google Cloud services, the Ops Agent and your apps; metrics scopes show many projects in one place, and uptime checks test your endpoints from around the world.

Cloud Monitoring stores time series: a metric (for example CPU utilization) for a monitored resource (a VM, a Cloud Run revision) over time.

flowchart LR
  GCP["Google Cloud services<br/>system metrics"] --> CM["Cloud Monitoring"]
  OA["Ops Agent on VMs<br/>memory, disk, app metrics"] --> CM
  PROM["Managed Service for Prometheus<br/>GKE metrics"] --> CM
  UP["Uptime checks<br/>from 6 regions"] --> CM
  CM --> DB["Dashboards and SLOs"]
  CM --> AL["Alerting policies"]
  %% step GCP: Every Google Cloud service publishes system metrics automatically, at no cost.
  %% step OA: The Ops Agent adds what the hypervisor cannot see, such as memory and disk usage, plus metrics from apps like nginx or MySQL.
  %% step PROM: Managed Service for Prometheus collects Prometheus metrics from GKE and lets you query them with PromQL.
  %% step UP: Uptime checks call your public endpoint from several locations and record latency and success.
  %% step DB: Dashboards and SLO monitoring turn the metrics into views and error budgets.
  %% step AL: Alerting policies watch the same metrics and notify people (next lesson).

Metric sources

Source	Examples	Notes
System metrics	`compute.googleapis.com/instance/cpu/utilization`, Cloud Run request latency	Automatic, free
Agent metrics	Memory, disk space, process metrics	Need the Ops Agent on VMs
Prometheus	Any `/metrics` endpoint on GKE	Managed Service for Prometheus
Custom / user-defined	`custom.googleapis.com/orders_paid` via OpenTelemetry or the API	Billed by volume
Log-based metrics	Count of log lines matching `"payment failed"`	Created in Cloud Logging

Install the Ops Agent with VM Manager policies or the console; it also ships logs to Cloud Logging.

Metrics scopes

One scoping project can show metrics from many projects. Create a dedicated monitoring project and add dl-shop-prod, dl-data-prod… so the operations team has one place to look.

Dashboards

Predefined dashboards for VMs, GKE, Cloud SQL, load balancers.
Custom dashboards with charts, filters and group-by; store them as JSON in Git.
Use Metrics Explorer for ad-hoc questions; PromQL works there too.

Uptime checks and SLOs

Uptime checks: HTTP(S) or TCP probes from multiple regions, with content matching; private uptime checks reach internal endpoints through Service Directory.
SLO monitoring: define a service, an SLI (for example share of requests under 300 ms) and a target (99.5% over 28 days) to track the error budget.

gcloud monitoring uptime create shop-home --resource-type=uptime-url   --resource-labels=host=shop.example.com,project_id=dl-shop-prod --protocol=https --path=/healthz
gcloud monitoring dashboards create --config-from-file=shop-dashboard.json

Command	Meaning
`gcloud monitoring uptime list-configs`	Uptime checks
`gcloud monitoring dashboards list`	Dashboards
`gcloud compute ssh vm -- "sudo systemctl status google-cloud-ops-agent"`	Check the agent on a VM

Traps: without the Ops Agent there is no memory metric for VMs; a metrics scope only shows data, it does not grant IAM access to the projects’ resources; high-cardinality custom labels (user IDs) make custom metrics expensive.