---
cuppy_hub: gcp
cuppy_path: reference/observability/cloud-monitoring.md
cuppy_section: docs
cuppy_doc: MTGK-6SGE
cuppy_doc_uuid: 54091f7e-1e7f-437c-ad42-d8c4b4fef2f1
cuppy_permalink: https://cuppy.io/gcp/d/MTGK-6SGE
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/observability/cloud-monitoring
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: d49c25a908e220a28a53f0d8a9fb678620e64e86f06d2a1b67e11c5fda78e57d
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Cloud Monitoring

## 1. The eight concepts

| Concept | What it is |
|---|---|
| **metric** / **metric type** | the measured thing, and its definition |
| **monitored resource** | what is being measured |
| **time series** | the data points for one metric on one resource |
| **dashboard** | the visual arrangement |
| **alerting policy** | the rule that fires |
| **notification channel** | where an alert is delivered |
| **uptime check** | synthetic probing of availability |
| **SLO** | a target the service is held to |

**A time series is identified by metric type *plus* monitored resource.** That pairing is the thing to
internalise: "CPU utilisation" is not a series, "CPU utilisation of *this* instance" is. Most confusion about
why a chart is empty or an alert fires for the wrong thing is a resource-label problem, not a metric problem.

## 2. The metrics scope — the setting that makes multi-project monitoring work

The documentation names **"configure a metrics scope"** as a foundational step, with a **scoping project**
establishing which resources Cloud Monitoring observes.

This is the one piece of Cloud Monitoring that has to be designed before anything is built, because:

- a Google Cloud estate is **many projects** (`reference/overview/projects-and-resource-hierarchy.md`), and a
  dashboard or an alert that spans them needs a scope that includes them;
- adding a project to a scope later is easy; **discovering after a year that every dashboard was built in the
  wrong project** is not.

In a landing zone, pick the scoping project at the same time as the central logging project, and for the same
reason.

## 3. Alerting, in the order it actually gets built

1. a **metric** — platform, custom, or **log-based**
   (`reference/observability/cloud-logging.md` §4);
2. an **alerting policy** over it;
3. a **notification channel** it delivers to;
4. optionally an **SLO**, if the thing being measured is a user-visible promise.

An **uptime check** is the exception to the order: it *creates* the signal as well as consuming it, which makes
it the fastest useful monitoring for something that has none.

## 4. Prometheus — a hedge, stated as one

The page read **references "Prometheus Query Language (PromQL) for Cloud Monitoring"**, so PromQL querying is
referenced. **The product name "Managed Service for Prometheus" is not on this page**, so this document does
not assert what that product does or covers.

Why it is recorded at all: for a migration, "can we keep our PromQL queries and Grafana dashboards" is a
high-value question with a real answer somewhere in Google Cloud's documentation. Go and read that product's
own pages rather than inferring from here — and note the question explicitly in an assessment, because the
answer can remove a whole self-managed monitoring stack from the target estate.

## 5. For a migration estimate

Monitoring cost is driven by **ingested volume** — custom metrics, log-based metrics, and the cardinality of
their labels. **Label cardinality is the trap**: a label carrying a request id or a user id multiplies the time
series count without anyone choosing to.

Measure, before moving: number of custom metrics, their label cardinality, and the number of alerting policies.
The last one is also an effort estimate — policies are re-created, not migrated. See
`guides/parity/observability.md`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->