📖 Scenario: You are a cloud engineer at a company using Google Cloud Platform (GCP). Your team wants to monitor the CPU usage of virtual machines to ensure they run smoothly without overload.You will create a custom metric and then build a dashboard to visualize this metric.
🎯 Goal: Build a custom metric in GCP to track CPU usage and create a dashboard that displays this metric clearly.
📋 What You'll Learn
Create a custom metric descriptor for CPU usage
Set a threshold value for CPU usage alert
Write a query to fetch CPU usage data
Configure a dashboard widget to display the CPU usage metric
💡 Why This Matters
🌍 Real World
Monitoring VM CPU usage helps prevent performance issues and downtime by alerting teams before problems occur.
💼 Career
Cloud engineers and DevOps professionals often create custom metrics and dashboards to maintain healthy cloud infrastructure.
Progress0 / 4 steps
1
Create a custom metric descriptor
Create a custom metric descriptor named custom.googleapis.com/vm_cpu_usage with a description CPU usage percentage of VM instances and a metric type of GAUGE.
GCP
Hint
Use the exact metric name custom.googleapis.com/vm_cpu_usage and set the type to GAUGE.
2
Set a CPU usage alert threshold
Create a variable named cpu_alert_threshold and set it to 80 to represent 80% CPU usage as the alert threshold.
GCP
Hint
Set cpu_alert_threshold exactly to 80.
3
Write a query to fetch CPU usage data
Write a variable named cpu_usage_query that contains the Monitoring Query Language (MQL) query string to fetch the custom.googleapis.com/vm_cpu_usage metric data for the last 5 minutes.
GCP
Hint
Use the exact query string 'fetch custom.googleapis.com/vm_cpu_usage | within 5m'.
4
Configure a dashboard widget for CPU usage
Create a dictionary named dashboard_widget with keys title set to "CPU Usage", type set to "line_chart", and query set to the variable cpu_usage_query.
GCP
Hint
Use the exact keys and values as specified, and assign cpu_usage_query to the query key.
Practice
(1/5)
1. What is the main purpose of a dashboard in Google Cloud Monitoring?
easy
A. To visually display metrics and help monitor cloud resources
B. To store data permanently for backup
C. To write code for cloud functions
D. To manage user permissions
Solution
Step 1: Understand what dashboards do
Dashboards show visual summaries of metrics to help users watch cloud resources easily.
Step 2: Identify the correct purpose
Among the options, only displaying metrics visually matches the dashboard's role.
Final Answer:
To visually display metrics and help monitor cloud resources -> Option A
Quick Check:
Dashboard = Visual metric display [OK]
Hint: Dashboards show data visually, not store or code [OK]
Common Mistakes:
Confusing dashboards with storage or coding tools
Thinking dashboards manage permissions
2. Which of the following is the correct way to filter CPU usage metric in a Google Cloud Monitoring dashboard widget?
easy
A. filter: cpu_usage_metric
B. metric = "cpu_usage"
C. metric.type = "compute.googleapis.com/instance/cpu/utilization"
D. metric.cpu = "usage"
Solution
Step 1: Recall correct metric filter syntax
Google Cloud Monitoring uses metric.type with full metric names like "compute.googleapis.com/instance/cpu/utilization".
Step 2: Match options to syntax
Only metric.type = "compute.googleapis.com/instance/cpu/utilization" uses the correct full metric.type format.
Final Answer:
metric.type = "compute.googleapis.com/instance/cpu/utilization" -> Option C
Quick Check:
Correct metric filter uses metric.type with full name [OK]
Hint: Use full metric.type path for filters [OK]
Common Mistakes:
Using incomplete or shorthand metric names
Wrong filter keywords like 'filter:' or 'metric.cpu'
3. Given this snippet for a dashboard widget filter: metric.type = "compute.googleapis.com/instance/disk/read_bytes_count" AND resource.label.instance_id = "12345" What does this filter show?
medium
A. Disk read bytes count for instance with ID 12345
B. CPU usage for instance 12345
C. Network bytes sent by instance 12345
D. Disk write bytes count for instance 12345
Solution
Step 1: Analyze metric.type value
The metric is "disk/read_bytes_count", which means bytes read from disk.
Step 2: Check resource label filter
The filter limits data to instance with ID "12345".
Final Answer:
Disk read bytes count for instance with ID 12345 -> Option A
Quick Check:
Disk read bytes + instance filter = Disk read bytes count for instance with ID 12345 [OK]
Hint: Match metric.type and resource label to understand filter [OK]
Common Mistakes:
Confusing read bytes with write bytes
Mixing disk metrics with CPU or network
4. You created a dashboard widget but it shows no data. Which of these is the most likely cause?
medium
A. The user has read access to the project
B. The dashboard widget is set to refresh every 5 seconds
C. The dashboard has more than 5 widgets
D. The metric filter uses an incorrect metric type name
Solution
Step 1: Identify common reasons for no data
Incorrect metric type names cause filters to match no data, so widget shows empty.
Step 2: Evaluate other options
Refresh rate or widget count do not prevent data display; read access is needed but assumed correct here.
Final Answer:
The metric filter uses an incorrect metric type name -> Option D
Quick Check:
No data usually means wrong metric filter [OK]
Hint: Check metric type spelling if no data shows [OK]
Common Mistakes:
Blaming refresh rate or widget count
Ignoring permission issues but assuming access is correct
5. You want to create a dashboard showing both CPU utilization and network bytes sent for multiple instances, but only for instances tagged with "env:production". Which approach is best?
hard
A. Create a widget with a filter for "env:production" but only for disk metrics
B. Create two widgets with filters for CPU and network metrics, each filtering resource labels for "env:production"
C. Create a widget filtering only CPU metrics for all instances, ignoring network metrics
D. Create one widget showing CPU and network metrics without filters, then manually check instance tags
Solution
Step 1: Understand the requirement
You need to show two different metrics (CPU and network) filtered by instance tag "env:production".
Step 2: Choose filtering and widget setup
Best practice is separate widgets for each metric with proper filters on resource labels for the tag.
Step 3: Evaluate other options
Options A, B, and C either miss filtering, use wrong metrics, or ignore one of the required metrics.
Final Answer:
Create two widgets with filters for CPU and network metrics, each filtering resource labels for "env:production" -> Option B
Quick Check:
Separate widgets + correct filters = best dashboard [OK]
Hint: Use separate widgets with filters for each metric [OK]
Common Mistakes:
Trying to combine unrelated metrics in one widget without filters
Ignoring resource label filters for tags
Showing irrelevant metrics
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.