Metrics scopes overview

This document describes how Cloud Monitoring determines which metrics you can view and monitor. If you only want to view and monitor the metrics collected by a single Google Cloud project, then skip to the Compute Engine quickstart. However, if you want to view and monitor the metrics collected by multiple Google Cloud projects, then you need to configure Cloud Monitoring. This document introduces the data model and best practices. For a list of documents that describe how to configure Cloud Monitoring, see the What's next section.

This document doesn't describe the features available in Cloud Monitoring. For feature information, see Cloud Monitoring overview.

Monitoring lets you view and manage metrics in the following ways:

  • For a single project
  • For multiple projects within a single organization
  • For multiple projects across multiple organizations
  • For multiple Google Cloud projects and AWS accounts

By default, a Google Cloud project has visibility only to the metrics it stores. However, you can expand the set of metrics that a project can access by adding other Google Cloud projects to the project's metrics scope. The metrics scope defines the set of Google Cloud projects whose metrics the current Google Cloud project can access.

A scoping project hosts a metrics scope. Because every Google Cloud project hosts a metrics scope, every project is also a scoping project. The scoping project stores information about its metrics scope. It also stores the alerts, uptime checks, dashboards, and monitoring groups that you configure for the metrics scope. You can identify the scoping project for a metrics scope as the project selected by the Google Cloud console project picker.

For example, assume that a metrics scope of a scoping project contains three Google Cloud projects. When you create an alerting policy in the scoping project for that metrics scope, the policy monitors the metrics in the three projects.

You can configure a metrics scope from the Google Cloud console or from the Cloud Monitoring API.

Example of scoping projects and monitored projects

Assume that your Staging and Production projects contain Compute Engine virtual machine (VM) instances. To view the metrics for all of your VMs in a single view, you create another project, AllEnvironments, and then add the Staging and Production projects as monitored projects. You can view the metrics stored in the Staging project in two different ways with this configuration:

  • To view the metrics in all projects, select AllEnvironments with Google Cloud console project picker. When you go to the Monitoring page, you access the metrics scope for the AllEnvironments project. The dashed line in the following diagram shows that the metrics for all three projects are accessible:

    Multi-view metrics scope includes all three projects selected.

  • To view only the metrics for the Staging project, select the Staging project with the Google Cloud console project picker. When you go to the Monitoring page, you access the metrics scope for the Staging project. The dashed line in the following diagram shows that the metrics for only the Staging project are accessible:

    The metrics scope of `Staging` only includes the `Staging` project.

Best practices for scoping projects

We recommend that you use a new Google Cloud project or one without resources as the scoping project when you want to view metrics for multiple Google Cloud projects or AWS accounts.

When a metrics scope contains monitored projects, to chart or monitor only those metrics stored in the scoping project, you must specify filters that exclude metrics from the monitored projects. The requirement to use filters increases the complexity of chart and alerting policy, and it increases the possibility of a configuration error. The recommendation ensures that these scoping projects don't generate metrics, so there are no metrics in the projects to chart or monitor.

The previous example follows our recommendation. The scoping project, AllEnvironments, was created and then the Staging and Production projects were added as monitored projects. To view or monitor the combined metrics for all projects, you use the metrics scope for the AllEnvironments project. To view or monitor the metrics stored in the Staging project, you use the metrics scope for that project.

Consider an alternative design. Suppose you decide to add the Production project as a monitored project to the metrics scope of the Staging project. To view or monitor the metrics in all projects, you use the metrics scope for the Staging project:

Screenshot that shows the metrics scopes for the `Staging` project which includes the metrics for the `Production` project.

However, this design makes it more difficult to view or monitor only the metrics stored in the Staging project. The metrics scope for the Staging project provides the combined metrics of the Staging and Production projects. Therefore, when you want to view or monitor only metrics stored in the Staging project, your chart or alerting policy must use filters to eliminate the data from the Production project.

Grant access to Cloud Monitoring

To view the metrics visible to a metrics scope, your Identity and Access Management (IAM) role on the scoping project must include all the permissions in the Monitoring Viewer (roles/monitoring.viewer) role. You don't need any other permissions. For example, suppose the metrics scope of a scoping project monitors three Google Cloud projects and that you have a role of Monitoring Viewer on the scoping project. When you access the scoping project by using the Google Cloud console, you can view the metrics stored in that project and the metrics stored in the other three Google Cloud projects.

To modify a metrics scope, your Identity and Access Management roles on the scoping project and on each project that you want to add as a monitored project must include all permissions in the Monitoring Admin (roles/monitoring.admin) role.

For more information, see Control access with Identity and Access Management.

What's next