What Is Cloud Monitoring?
Cloud Monitoring is Google Cloud's built-in observability service that automatically collects metrics, uptime data, and metadata from resources like Compute Engine VMs, GKE clusters, Cloud SQL instances, and Cloud Run services. It ships with a metrics explorer, prebuilt dashboards, and an agent (the Ops Agent) that can be installed on VMs to capture system-level metrics such as CPU, memory, and disk I/O that aren't exposed by the hypervisor alone.
Cricket analogy: Just as a broadcaster overlays a scoreboard showing run rate, partnership, and required rate without the players doing anything extra, Cloud Monitoring auto-collects CPU and network metrics from your VMs without any code changes.
Metrics, Dashboards, and Alerting Policies
Metrics in Cloud Monitoring are time-series data identified by a metric type (e.g., compute.googleapis.com/instance/cpu/utilization), a resource type, and labels. You build dashboards from Metrics Explorer using Monitoring Query Language (MQL) or PromQL, and you define alerting policies with conditions such as 'CPU utilization above 80% for 5 minutes' that trigger notifications through channels like email, Slack, or PagerDuty via Pub/Sub.
Cricket analogy: Setting an alerting policy is like a captain telling the bowler to switch to a yorker if the batsman's strike rate exceeds 150 over the last two overs — a threshold condition sustained over a rolling window triggers an action.
# Example alerting policy condition (Cloud Monitoring API, simplified)
displayName: "High CPU on web-tier VMs"
conditions:
- displayName: "CPU utilization above 80%"
conditionThreshold:
filter: >
resource.type="gce_instance"
AND metric.type="compute.googleapis.com/instance/cpu/utilization"
comparison: COMPARISON_GT
thresholdValue: 0.8
duration: 300s
aggregations:
- alignmentPeriod: 60s
perSeriesAligner: ALIGN_MEAN
notificationChannels:
- "projects/my-project/notificationChannels/1234567890"
combiner: ORThe Ops Agent (successor to the older Monitoring and Logging agents) is the recommended single agent for collecting both metrics and logs from Compute Engine VMs, including third-party application metrics via built-in receivers for services like NGINX, MySQL, and Redis.
Uptime Checks and SLO Monitoring
Uptime checks send synthetic HTTP, HTTPS, or TCP requests to a public endpoint from multiple global locations at a set interval, verifying availability independent of your own infrastructure reporting metrics. Cloud Monitoring also supports Service Level Objectives (SLOs), letting you define an availability or latency target (e.g., 99.9% of requests under 300ms) and track error budget consumption over rolling windows, which is essential for teams practicing SRE.
Cricket analogy: An uptime check is like a third umpire independently reviewing a run-out from a different camera angle rather than trusting the fielder's own claim — external verification of availability.
Uptime checks verify only reachability and basic content matching from external probers — they will not catch degraded internal states like a database connection pool exhaustion that still returns HTTP 200. Pair them with application-level custom metrics for full coverage.
- Cloud Monitoring auto-collects metrics from most GCP resources with no extra setup, and the Ops Agent extends this to OS and third-party application metrics on VMs.
- Metrics are identified by metric type, resource type, and labels, and can be queried with MQL or PromQL in Metrics Explorer.
- Alerting policies combine a filter, a threshold, and a duration window, then notify via channels like email, Slack, or PagerDuty.
- Uptime checks are synthetic external probes from multiple regions that verify availability independent of your own telemetry.
- SLOs define availability/latency targets and track error budget consumption, forming the backbone of SRE practice on GCP.
- Dashboards can be built from prebuilt templates or fully custom widgets combining multiple metrics and resources.
- Uptime checks alone are insufficient for detecting internal degradation — combine with custom application metrics.
Practice what you learned
1. Which GCP agent is recommended for collecting both metrics and logs from a Compute Engine VM?
2. What does an uptime check primarily verify?
3. In an alerting policy, what does the 'duration' field control?
4. What concept tracks how much unreliability is acceptable within an SLO period?
5. Which query languages can be used in Metrics Explorer?
Was this page helpful?
You May Also Like
The GCP Architecture Framework
An overview of Google Cloud's Architecture Framework pillars — system design, operational excellence, security, reliability, cost optimization, and performance — for building well-architected workloads.
Deploying a Simple App on GCP
A hands-on walkthrough of deploying a simple containerized web app to Cloud Run, covering build, deploy, environment configuration, and rollback.
GCP Quick Reference
A condensed cheat sheet of core GCP services, gcloud commands, and IAM/networking concepts for fast lookup during study or work.