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
contain Compute Engine virtual machine (VM) instances. To view the
metrics for all of your VMs in a single view, you create
AllEnvironments, and then add the
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
AllEnvironmentswith console project picker. When you go to the Monitoring page, you access the metrics scope for the
AllEnvironmentsproject. The dashed line in the following diagram shows that the metrics for all three projects are accessible:
To view only the metrics for the
Stagingproject, select the
Stagingproject with the console project picker. When you go to the Monitoring page, you access the metrics scope for the
Stagingproject. The dashed line in the following diagram shows that the metrics for only the
Stagingproject are accessible:
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
were added as monitored projects. To view or
monitor the combined metrics for all projects, you use the metrics scope
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
project as a monitored project to the metrics scope of the
project. To view or monitor the metrics in all projects, you use the
metrics scope for the
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
Production projects. Therefore,
when you want to view or monitor only metrics stored in
Staging project, your chart or alerting policy must use
filters to eliminate the data from the
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 (
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
For more information, see Access control with IAM.
For information about how to add and remove Cloud projects to a metrics scope, see the following documents:
For information about how to add and remove AWS accounts to a metrics scope by using the console, see View metrics for an AWS account.
For information about pricing, see Pricing for Google Cloud's operations suite.
For information about quotas and limits, see Quotas and limits.