Topic 8 of 10
Cloud Monitoring
Exam section 3.4 asks you to monitor resources: create alerts from metrics, configure custom metrics, install the Ops Agent, use Managed Service for Prometheus, and rely on Gemini Cloud Assist and Active Assist. Logging is covered in the next article.
Contents
What Cloud Monitoring collects
Cloud Monitoring collects, stores, and analyzes metrics. Metrics for most Google Cloud services are collected automatically, with nothing to install.
| Metric type | Where it comes from |
|---|---|
| System metrics | Generated by Google Cloud services |
| Agent metrics | The Ops Agent on Compute Engine VMs, including apps such as Apache, Nginx, MongoDB, or PostgreSQL |
| User-defined | Created with the Cloud Monitoring API or libraries such as OpenTelemetry |
| Prometheus | Managed Service for Prometheus, or the Ops Agent with the Prometheus or OTLP receiver |
| Log-based | Numeric information derived from Cloud Logging entries |
Chart and alert queries are built from menus, with PromQL, or with Monitoring filter expressions. Metrics Explorer lets you explore time series quickly and save charts to a dashboard.
Metrics scope: multiple projects
By default, a project only sees its own metrics. The metrics scope defines which projects (and AWS accounts) a project can chart and monitor. The project that hosts it is the scoping project, which stores the alerting policies, uptime checks, dashboards, and groups.
Recommended practice
Use a new project, or one without resources, as the scoping project. If it has its own VMs, their metrics mix with those of the monitored projects and you have to filter every chart and alert.
Alerting policies
An alerting policy describes when to alert and who to notify. When the data meets the condition, Monitoring creates an alert (a persistent record with status, links to logs, and a chart) and sends notifications. When the condition is no longer met, it closes the alert and notifies you.
Metric-based
Evaluate Monitoring time series.
Log-based
Notify you when a specific message appears in a log entry.
SQL-based
Evaluate the results of a SQL query on logs (in preview).
| Condition | Met when… |
|---|---|
| Metric threshold | The value is above or below a threshold for a retest window |
| Metric absence | A time series has no data for a retest window (maximum 24 hours) |
| Forecasted value | The threshold is predicted to be crossed within the forecast window (1 hour to 7 days) |
| PromQL | A PromQL expression: ratios, several metrics, or dynamic thresholds |
- Each policy has a condition, a list of notification channels, and optional documentation shown in the notification (for example, a runbook link).
- Integrations (GKE, Compute Engine, Cloud SQL…) offer preconfigured recommended alerts: you only choose the channel.
- A policy can't be limited to certain hours. To pause it during maintenance, create a snooze.
- With gcloud, policies are created from a JSON file that contains the definition.
gcloud monitoring snoozes create --display-name="Maintenance Week" \ --criteria-policies="projects/my-project/alertPolicies/12345" \ --start-time="2026-11-01T03:00:00Z" --end-time="2026-11-01T07:00:00Z"
Notification channels
Email, Cloud Mobile App, PagerDuty, SMS, Slack, webhooks, and Pub/Sub. A policy can have several channels.
- Google recommends several channel types for redundancy. Mobile App, PagerDuty, webhooks, and Slack share the same internal service; if you use one, add email or Pub/Sub as a backup.
- SMS isn't fully reliable: always pair it with another channel.
- To automate actions from notifications, use webhooks or Pub/Sub; the format of the others can change.
Custom and log-based metrics
User-defined (custom)
- Application data that built-in metrics don't collect.
- Google recommends instrumenting with OpenTelemetry; Prometheus or the Monitoring API also work.
- The name uses the
custom.googleapis.com/prefix. - They are chargeable.
Log-based
- Derived from the content of log entries that match a filter.
- Counter (how many entries match) or distribution (values such as latencies, in a histogram).
- Not retroactive: they only count entries received after they're created.
- They can have gaps; alerts on them should define how to handle missing data.
gcloud logging metrics create high_severity_count \ --description="Number of high severity log entries" \ --log-filter="severity > WARNING"
User-defined log-based metrics are calculated from both included and excluded logs; system ones only from included logs.
Ops Agent
It's the primary agent for collecting telemetry from Compute Engine VMs: logs, metrics, and traces in a single process. It uses Fluent Bit for logs and the OpenTelemetry Collector for metrics and traces. It's configured with a YAML file.
- With no configuration it collects system logs (syslog, Windows Event Log) and metrics such as CPU, disk, memory, swap, network, and processes.
- Third-party application integrations, Prometheus metrics, OTLP metrics and traces, and NVIDIA GPU (DCGM) metrics.
- It uses the VM's service account, which needs
roles/logging.logWriterandroles/monitoring.metricWriter. The Cloud Logging and Cloud Monitoring APIs must be enabled. - It shouldn't run alongside the legacy Logging or Monitoring agents (duplicate data).
- With agent policies you install it across a fleet of Linux VMs, new and existing, with a single command.
- It isn't supported on AWS EC2 instances or on-premises machines.
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh sudo bash add-google-cloud-ops-agent-repo.sh --also-install
Managed Service for Prometheus
A managed, multi-cloud service for Prometheus and OpenTelemetry metrics, with no Prometheus servers to run. You query it with PromQL, so existing Grafana dashboards and alerts keep working. It uses the same backend as Cloud Monitoring (Monarch) and keeps data for 24 months at no extra cost.
| Collection mode | When |
|---|---|
| Managed | An operator for Kubernetes (GKE and others). Recommended for all Kubernetes environments |
| Self-deployed | You manage Prometheus as usual, with Google's drop-in replacement binary |
| OpenTelemetry Collector | One agent for metrics, logs, and traces in any environment |
| Ops Agent | Compute Engine VMs |
On Cloud Run you use a Prometheus or OpenTelemetry sidecar.
Uptime checks and dashboards
Public uptime checks send periodic HTTP, HTTPS, or TCP requests from several locations worldwide to a URL, VM, App Engine app, Kubernetes service, Cloud Run revision, or EC2 instance. When you create one you can add an alerting policy. For resources on a private network there are private uptime checks.
- They don't load page assets or run JavaScript, and by default they don't authenticate.
- If the resource is behind a firewall, allow the IP addresses of the uptime-check servers.
- Console role:
roles/monitoring.editor.
Google Cloud creates managed dashboards for your resources automatically. Custom dashboards show metric charts, logs, error groups, alerts, text, and events; you can import them from Grafana or install them from templates.
Gemini Cloud Assist and Active Assist
Gemini Cloud Assist
- Investigations: diagnose issues from logs, errors, or natural-language prompts.
- Proactive alert investigations: an alerting policy can trigger Gemini Cloud Assist, which clusters related alerts and generates a preliminary root-cause analysis with next steps.
- It can hand off the investigation to a Google support case as context.
Active Assist
- A portfolio of tools that generate recommendations and insights through recommenders.
- Six categories: cost, security, performance, reliability, manageability, and sustainability.
- Examples: idle VMs, machine type, committed use discounts, overprovisioned Cloud SQL instances, the IAM recommender, firewall insights.
- View them in Active Assist, in context on each service, in FinOps hub, on the Cloud Hub Optimization page, with gcloud, or with the API. You apply or dismiss them.
Before applying a recommendation
Google warns that someone in your organization should assess its impact: applying recommendations without review can affect performance or reliability or remove required permissions. If you apply them without human review, have a rollback process in place.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| Notify the team when a VM's CPU is above 80% for 5 minutes | Alerting policy with a metric-threshold condition | Condition + notification channel. |
| See VM memory usage and Apache logs | Install the Ops Agent | Collects system metrics and third-party logs. |
| An operations team must see metrics from 20 projects in one place | Metrics scope in a scoping project with no resources | This is the recommended practice. |
| Count how often "payment failed" appears in logs and alert on it | Log-based metric (counter) plus an alert on it | Only counts entries from when it's created. |
| Alert if a disk will reach 80% within the next 24 hours | Forecasted metric-value condition | Forecast window from 1 hour to 7 days. |
| Silence alerts during a maintenance window | Create a snooze | Policies can't be limited to certain hours. |
| Monitor GKE workloads with PromQL without running Prometheus servers | Managed Service for Prometheus with managed collection | Recommended for Kubernetes; keeps 24 months. |
| Find idle VMs to cut costs | Active Assist recommendations (idle VM recommender) | Cost category. |
Common exam traps
❓ Do you need to install anything to see a VM's CPU in Cloud Monitoring?
No. System metrics from Google Cloud services are collected automatically. The Ops Agent adds operating system metrics, such as memory, and application logs.
❓ Does a newly created log-based metric include yesterday's logs?
No. It only counts entries received after it was created.
❓ Can you configure an alerting policy to work only during business hours?
No. It's always evaluated; to pause it for a specific period, create a snooze.
❓ Is a single Slack channel enough for critical alerts?
Not recommended. Slack, PagerDuty, webhooks, and Mobile App share a single point of failure; add email or Pub/Sub.
❓ Where are the alerts and dashboards of a multi-project metrics scope stored?
In the scoping project, which ideally has no resources of its own.
❓ Can you run the Ops Agent alongside the legacy Logging agent?
You shouldn't: it causes duplicate logs or metric conflicts. Uninstall the legacy agents.
Did you get this topic?
Test what you just learned
You want an alert when memory usage on a group of Linux VMs goes above 90%. Metrics Explorer shows no memory metric for those VMs. What do you do first?