SPEAKER: We've covered using Cloud monitoring
in your projects.
But what if you're responsible for managing many projects,
and you need to unify monitoring across them?
And how can you control access to monitoring data
from many projects?
Today, we'll look at Cloud monitoring metrics scopes,
and learn how to use them to monitor multiple Cloud
projects.
Welcome to Engineering for Reliability with Google Cloud.
Let's start with a simple example.
How can you make it easier to view monitoring data
for multiple projects?
If I go to monitoring settings for my project,
I can see that my current metrics scope only
has a single project in it, the one I'm currently viewing.
I can add others, but what's actually happening here?
Let's have a look at metrics scopes and how they work.
When you create a Google Cloud project,
that project hosts a metrics scope
and becomes the scoping project for that scope.
It stores the alerts, uptime checks, dashboards,
and monitoring groups that you configure for the scope.
For example, if you create a staging project and then
access monitoring, you can see the metrics
for the resources in the staging project.
This happens for every project you create.
Each project creates a metrics scope for itself,
and hosts monitoring configuration for itself.
But what if you want to centralize how that data is
stored and how it's accessed?
You can add multiple projects to an existing scope.
Now, monitoring data for all projects in that scope
will be visible.
This will let you do things like create dashboards
showing resources from all the projects in the scope,
or alerting policies that apply to resources
in multiple projects as long as they're in the metrics scope.
Note that the recommended approach for production
deployments is to create a dedicated project to host
monitoring configuration data and use its metrics
scope to set up monitoring for the projects that
have actual resources in them.
This way, should a project not be necessary anymore
and get deleted, the monitoring configuration
for all the other projects won't be impacted.
What about access?
While in this configuration, you just
must have appropriate IAM permissions
to access monitoring data.
For example, a user would need to have the right role
in the monitoring project to be able to see monitoring
data for both projects.
A user who only has access to the staging project
would not be able to see any monitoring data
for the production project.
Now that you understand what metrics scopes are
and what to use them for, let's have
a look at how to set them up in Cloud monitoring.
Let's start in our staging project.
We'll go to Compute Engine, and see that we
have a single VM running.
We can go to monitoring, and see that monitoring data for the VM
is being shown.
For example, on the infrastructure summary
dashboard.
Let's now go to our monitoring project,
and confirm that there aren't any compute instances
running in it.
We also don't have the out-of-the-box compute
dashboards because we don't have any resources running in this
project.
Let's now add our staging project
to be monitored by this metrics scope.
We can do that in monitoring settings by adding a project,
selecting the project we want to add,
and confirming that we want to use this monitoring
project as the scoping project rather than creating
a new scope.
Once this operation is complete, monitoring data
from the staging project will be visible in this metrics scope.
We can confirm that by going to the VM instances dashboard,
for example.
From here, we can see more details
about the instance being monitored, even though it's
running in another project.
So that's how we can use the Cloud Console to configure
metrics scopes and collect monitoring
data for multiple projects.
So that's how to configure metrics scopes in the UI.
But how can you figure out where your project is
being monitored, or where the monitoring data you can see
in your project is coming from?
Let's have a look.
Now that we have added our staging project
to our monitoring metrics scope, let's
see how we can navigate between the two.
We can see information about our current metrics scope
here on the monitoring overview page for the monitoring
project.
If we click on that, we can see that the monitoring project
is monitoring metrics for resources
running in the project itself and in our staging project.
We can go there directly from here.
In the staging project, we can do the same thing,
and see that this project is monitoring metrics for itself,
and that it is being monitored by our monitoring project.
And we can go back to that project
simply by clicking on that link.
So that's how you can navigate between metrics scopes
and monitored projects in Cloud monitoring.
Navigating metrics scopes in the UI is easy enough.
But how can you ensure that, for example, new projects
are added to your Production Monitoring configuration?
You can use the API to automate that.
Let's have a look.
Let's start in monitoring settings,
and confirm that this particular metrics scope is only
monitoring this project, which is the scoping
project for this metrics scope.
Now let's go to our API.
We'll use the Create method for metrics scopes projects
which takes two arguments.
First one is the parent, which is the metrics
scope that we want to add our stage and project to.
The second is our project itself,
which is a monitored project resource.
The name field includes a reference
to both the staging project and the metrics scope
we're adding this project to.
Let's execute this request, authenticate, and confirm
that the operation is done.
We can now go back to monitoring settings for our monitoring
project, refresh the page, and confirm
that the staging project has been
added to this metrics scope.
So that's how you can use the Cloud monitoring
API to manage how projects are monitored by metrics scopes.
Thanks for joining me today.
We covered how metrics scopes lets you configure
monitoring across projects, and how to manage them in the UI
and using the API.
I hope this helps you standardize and automate
your monitoring, run more reliable services,
and keep your users happy.
Thanks so much for watching.
Don't forget to like and subscribe to never miss out
on more Engineering for Reliability with Google Cloud.
See you soon.