Google Cloud Monitoring

At a glance

Google Cloud Monitoring collects time-series metrics and turns them into charts, dashboards and alert conditions. It is a strong starting point for a service already running on Google Cloud because many platform metrics are collected automatically. It is worth using when a question such as which instance is saturated can be answered from existing telemetry. The useful work is selecting the right signal and grouping, not filling a dashboard with every available chart.

Good fit

Teams that want platform and application metrics in one managed system, including metrics exposed in the Prometheus format through a managed collection path. Metrics Explorer can chart existing data before you build a dashboard. Metrics scopes can bring several projects into one view, while a scoping project holds the dashboard and alert configuration. Cloud Logging and Cloud Trace are related services, not names for the same metric store; their data collection and charges need separate consideration.

Consider something else when

You need a full monitoring result without deciding what to measure, or a predictable flat bill regardless of metric design. An empty chart can reflect a missing metric, time range, filter or scope. Labels multiply the number of distinct time series, so adding a changing identifier can create much more telemetry than adding one ordinary chart. For a small site that only needs an external availability check, compare that narrow job with operating a broader cloud-observability setup.

Start here

In an existing project with permission to view its metrics, open Monitoring, Metrics Explorer and confirm the project picker. Select a metric that already has data, such as a VM’s CPU utilization, and inspect a short relevant time range. Compare the unaggregated series with a grouped view before drawing a conclusion: an average can hide a single busy instance. Save a useful chart to a dashboard only after verifying the resources and labels. This is the documented workflow; no customer project, chart or alert was accessed or created for this assessment.

Cost and requirements

On 31 October 2026, published pricing separates non-chargeable platform metrics, byte-metered metrics and sample-metered Prometheus ingestion. The byte-metered category includes 150 MiB per billing account each month, then starts at $0.258 per MiB in the first paid tier. API reads outside the console, uptime-check executions and synthetic monitors have separate allowances or charges. Announced metric-alerting charges start no earlier than 1 September 2027, rather than being an established current charge. Review the effective dates and your agreement before estimating a monthly bill.

Limits to know

A metrics scope changes visibility; it does not copy metrics into the scoping project. Monitoring Viewer access there can expose the metrics from its included projects, so scope and access design belong together. Metrics Management can identify unused, high-volume billable metrics; reducing label combinations or collection frequency changes what you can diagnose as well as cost. Alert delivery, collector behavior, API/CLI calls, ingestion delay and incident detection were not tested. A chart or an alert policy alone does not establish that an on-call response works.

Related work

• Prometheus: metric model and collection context for the managed integration (context)