Overview of viewing metrics for multiple projects

This document, which describes how you can view and manage your metrics, is intended for developers and system administrators. To learn more about the features available in Cloud Monitoring, see Introduction to Cloud Monitoring.

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 console project picker.

For example, assume that a metrics scope of a scoping project contains three 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 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 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 Cloud project or one without resources as the scoping project when you want to view metrics for multiple 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 Cloud projects and that you have a role of Monitoring Viewer on the scoping project. When you access the scoping project by using the console, you can view the metrics stored in that project and the metrics stored in the other three Cloud projects.

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

For more information, see Access control with IAM.

What's next