This document describes how to configure the metrics scopes of yourGoogle Cloud projects for use with Google Cloud Managed Service for Prometheus.

The ideal Managed Service for Prometheus deployment is different from thetypical Prometheus deployment by necessity. Prometheus is highly scoped toits own instance—which is itself typically cluster-scoped—in thatrules and queries run on the Prometheus server that collects the data.Because Managed Service for Prometheus sends data to the global backend,Monarch, queries must be configured to execute againstMonarch, not the local cluster. If you are using managed collection,then the same requirement applies to rules.

The data you query using Managed Service for Prometheus is determinedby the Cloud Monitoring constructmetrics scope, regardless ofhow you query the data.

Metrics scopes

A Monitoring metrics scope is a read-time-only construct thatlets you query metric data belonging to multiple Google Cloud projects. Everymetrics scope is hosted by a designated Google Cloud project, called thescoping project.

By default, a project is the scoping project for its own metrics scope,and the metrics scope contains the metrics and configuration for thatproject. A scoping project can have more than one monitored project in itsmetrics scope, and the metrics and configurations from all the monitoredprojects in the metrics scope are visible to the scoping project. Amonitored project can also belong to more than one metrics scope.

When you query the metrics in a scoping project, and if thatscoping project hosts a multi-project metrics scope, you can retrievedata from multiple projects. If your metrics scope contains all yourprojects, then your queries and rules evaluate globally.

For more information about scoping projects and metrics scope,seeMetrics scopes. For information about configuringmulti-project metrics scope, seeView metrics for multipleprojects.

To minimize the complexity of your permissions model, use as few metricsscopes as possible. If you do not consider your metric data to be sensitiveand it is acceptable for all users to be able to access all metrics,then use a single metrics scope that contains all your projects.

Grouping projects together for querying

The other best-practice scenarios use the following metrics-scopeconfigurations: