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);

1. an alerting policy over it;
2. a notification channel it delivers to;
3. 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.