Cloud Monitoring is the metric, alert, and dashboard layer of Google Cloud's observability stack. For the Professional Cloud Architect exam, you need to know what kinds of metrics it collects, how alerts route to notification channels, how to build a single pane of glass across multiple projects, and how uptime checks work end to end including the firewall implications. I'll walk through each of those.
Cloud Monitoring collects, analyzes, and visualizes metrics from Google Cloud resources so you can keep track of the health and performance of your applications and infrastructure. It surfaces real-time metrics, supports custom dashboards, and feeds an alerting engine that can fire on any metric you're tracking.
If you've worked with Google Cloud for a while, you may remember Cloud Monitoring as Stackdriver Monitoring. Same product, renamed. It now sits inside the Cloud Observability suite alongside Cloud Logging and Cloud Trace, and the three are designed to work together to give you metrics, logs, and traces from one place.
Cloud Monitoring deals with three categories of metrics, and the Professional Cloud Architect exam expects you to recognize each one.
Built-in metrics are emitted automatically by Google Cloud services with no setup on your part. They cover infrastructure (CPU utilization, disk I/O, network traffic, memory usage), application behavior (response times, error rates, request rates, latency), and system state (system load, running processes). These are the metrics you reach for first because they're already there.
Custom metrics are ones you define yourself to track things the built-in catalog doesn't cover. User engagement counters, business transaction volume, application-specific health signals. You instrument your code to write these to the Monitoring API.
External metrics let you pull in data from outside Google Cloud, such as workloads running on AWS or Azure, or on-prem applications and monitoring tools. This is how you build a unified view across a hybrid or multi-cloud estate.
The general guidance is to use built-in metrics where you can. They're optimized for the GCP services that emit them and require zero configuration. Reach for custom and external metrics when the built-in ones don't cover what you need.
Real-time alerts can be configured on any metric Cloud Monitoring is tracking. Common examples include CPU utilization crossing a threshold like 90%, response time creeping past a target, error rate spikes, or a sudden drop in active users that suggests something is broken upstream.
When an alert fires, you choose where the notification goes. The supported notification channels include:
Pub/Sub and webhook channels are the ones to remember for automation scenarios. If you want an alert to kick off an automated workflow rather than just notify a human, you route it to Pub/Sub and have a Cloud Function or Cloud Run service subscribe to that topic. Webhooks let you integrate with arbitrary HTTP endpoints. Email and SMS are for the human-in-the-loop case, and Slack and PagerDuty are the standard third-party integrations for team-based incident response.
Most real Google Cloud environments have many projects. Different teams, different environments, different cost centers. Cloud Monitoring handles this by letting you set up a workspace in one project and link other projects to it.
The pattern is straightforward. You pick one project to be the primary, set up a Cloud Monitoring workspace there, and link the other projects to that workspace through the Google Cloud Console. The primary workspace becomes the central hub where you build dashboards and configure alerts that span all the linked projects.
The classic use case is a company with multiple departments, each operating in their own project, where leadership or a central platform team needs a unified view of operations. Linking the project metrics into one workspace gives you that view without having to bounce between projects in the console.
Uptime checks are a Cloud Monitoring feature that periodically probes your applications and services to confirm they're available and responsive. By default the check runs every minute, and you can adjust that interval to fit your needs.
The mechanics are simple. Cloud Monitoring sends a request to your endpoint the way a user would. If the endpoint responds normally, the check passes. If no response comes back, the check fails and Cloud Monitoring triggers an alert that can be routed through any of the notification channels described above. That alert can land in Pub/Sub for automated remediation, in Slack for the on-call channel, on a phone for an incident commander, or in an email inbox for slower-tempo follow-up.
Two operational details worth remembering. Uptime checks work against both public-facing and private applications, so you can use them across very different deployment topologies. And the default interval is one minute, which is usually fine, but you can dial it up or down depending on how aggressive you need the monitoring to be.
Uptime checks come from Google-operated monitoring servers, which means your application has to actually let those servers in. If your firewall blocks them, every check fails and you get a wave of false-positive alerts.
To make uptime checks work, you allow incoming traffic from the IP addresses Google uses for uptime monitoring. Open port 80 for HTTP and port 443 for HTTPS, depending on what your application serves. The IP list spans multiple regions globally, including Iowa, Virginia, Oregon, Sao Paulo, Singapore, and Belgium, so you're allowing a fixed set of source ranges rather than the whole internet.
You don't have to memorize the IPs. The Console lets you download a current list as a text file, and on the command line you can run:
gcloud monitoring uptime list-ipsThat command returns the current set of IPs the monitoring servers use. The list does change over time, so if you've hard-coded firewall rules from a list you grabbed years ago, it's worth re-pulling.
For the Professional Cloud Architect exam, the Cloud Monitoring topics that show up most often are the difference between built-in, custom, and external metrics, the available notification channels for alerts (and especially that Pub/Sub and webhooks are how you connect alerts to automation), the multi-project pattern of one workspace with linked projects, and the uptime check workflow including the firewall rules that have to be in place for checks to succeed.
My Professional Cloud Architect course covers Cloud Monitoring alongside the rest of the IAM and governance material.
