Monitoring Dashboards

1. Monitoring Dashboards

Let's get into monitoring and visualizing information with dashboards. Google Cloud unifies the tools you need to monitor your service SLOs and SLAs in real time. These tools include Monitoring, Logging, Trace, Error Reporting, and Profiler. All of these enable you to gain the insights you need to achieve your SLOs and to determine the root cause in those rare cases that you do not achieve your SLOs. Dashboards are one way for you to view and analyze metric data that is important to you. This includes your SLIs to ensure that you are meeting your SLAs. The Monitoring page of the Cloud Console automatically provides pre-defined dashboards for the resources and services that you use. It is important that you monitor these things you pay for to determine the trends, bottlenecks, and potential cost savings. Here's an example of some charts in a Monitoring dashboard. On the left, you can see the CPU usage for different Compute Engine instances. And on the right is the ingress traffic for those instances. Charts like these provide valuable insights into usage patterns. To help you get started, Cloud Monitoring creates default dashboards for your project resources as shown in this screenshot. You can also create custom dashboards which you can explore in the upcoming lab. Now, it's a good idea to monitor latency because it can quickly highlight when problems are about to occur. As shown on the slide, you can easily create uptime checks to monitor the availability and latency of your services. So far, there is a 100% uptime with no outages. Latency is actually one of the four golden signals called out in Google's Site Reliability Engineering, or SRE book. SRE is a discipline that applies aspects of software engineering to operations whose goals are to create ultra-scalable and highly reliable software systems. This discipline has enabled Google to build, deploy, monitor, and maintain some of the largest software systems in the world. I've linked the SRE book in the slides of this module. Your SLO will be more strict than your SLA, so it is important to be alerted when you are not meeting an SLO because it's an early warning that the SLA is under threat. Here's an example of what creating an alerting policy looks like. On the left, you can see an HTTP check condition on the summer01 instance. This will send an email that is customized with the content of the documentation section on the right.

2. Let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.