This document describes how to configure the metrics scopes of your Google Cloud projects for use with Google Cloud Managed Service for Prometheus.
The ideal Managed Service for Prometheus deployment is different from the typical Prometheus deployment by necessity. Prometheus is highly scoped to its own instance—which is itself typically cluster-scoped—in that rules 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 against Monarch, 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 determined by the Cloud Monitoring construct metrics scope, regardless of how you query the data.
Metrics scopes
A Monitoring metrics scope is a read-time-only construct that lets you query metric data belonging to multiple Google Cloud projects. Every metrics scope is hosted by a designated Google Cloud project, called the scoping project.
By default, a project is the scoping project for its own metrics scope, and the metrics scope contains the metrics and configuration for that project. A scoping project can have more than one monitored project in its metrics scope, and the metrics and configurations from all the monitored projects in the metrics scope are visible to the scoping project. A monitored project can also belong to more than one metrics scope.
When you query the metrics in a scoping project, and if that scoping project hosts a multi-project metrics scope, you can retrieve data from multiple projects. If your metrics scope contains all your projects, then your queries and rules evaluate globally.
For more information about scoping projects and metrics scope, see Metrics scopes. For information about configuring multi-project metrics scope, see View metrics for multiple projects.
To minimize the complexity of your permissions model, use as few metrics scopes as possible. If you do not consider your metric data to be sensitive and 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-scope configurations:
| Scope A | Scope B | Scope C | |
|---|---|---|---|
| Scoping project | scoping-project-A | scoping-project-B | scoping-project-C |
| Monitored projects | Project 1 Project 2 |
Project 3 Project 4 |
Project 1 Project 2 Project 3 Project 4 Project 5 |
| IAM-permissioned group (example) |
Dev team A | Dev team B | SRE team |