📖 Scenario: You are managing a Google Cloud project that runs several applications. You want to monitor how many error logs are generated to quickly detect issues.
🎯 Goal: Create a log-based metric in Google Cloud that counts the number of error logs with severity ERROR.
📋 What You'll Learn
Create a log-based metric resource with the exact name error_count_metric.
Use the filter to select logs with severity=ERROR.
Set the metric type to counter to count occurrences.
Use the Google Cloud Logging API resource format.
💡 Why This Matters
🌍 Real World
Log-based metrics help monitor application health by counting specific log entries like errors or warnings.
💼 Career
Cloud engineers and DevOps professionals use log-based metrics to set up alerts and dashboards for system reliability.
Progress0 / 4 steps
1
Define the log-based metric resource
Create a dictionary called log_metric with keys name set to "error_count_metric" and filter set to "severity=\"ERROR\"".
GCP
Hint
Use a Python dictionary with keys name and filter.
2
Add the metric descriptor type
Add a key metricDescriptor to log_metric with a nested dictionary containing metricKind set to "DELTA" and valueType set to "INT64".
GCP
Hint
The metric kind DELTA counts changes, and value type INT64 means integer values.
3
Add a description for the metric
Add a key description to log_metric with the value "Counts the number of error logs".
GCP
Hint
The description helps explain what the metric measures.
4
Complete the log-based metric configuration
Add a key labelExtractors to log_metric with an empty dictionary {} to complete the configuration.
GCP
Hint
Label extractors are optional but required as an empty dictionary to complete the metric resource.
Practice
(1/5)
1. What is the main purpose of a log-based metric in Google Cloud?
easy
A. To delete old logs automatically
B. To count specific log entries and turn them into numbers you can monitor
C. To store logs permanently without any processing
D. To encrypt logs for security
Solution
Step 1: Understand what log-based metrics do
Log-based metrics count log entries that match a filter and convert them into numerical data.
Step 2: Compare options to this definition
Only To count specific log entries and turn them into numbers you can monitor describes counting logs and turning them into numbers for monitoring.
Final Answer:
To count specific log entries and turn them into numbers you can monitor -> Option B
Quick Check:
Log-based metrics = counting logs for monitoring [OK]
Hint: Log-based metrics count logs to create numbers you watch [OK]
Common Mistakes:
Confusing log storage with metrics
Thinking metrics delete or encrypt logs
Assuming metrics store logs permanently
2. Which of the following is the correct way to create a log-based metric filter to count error logs with severity ERROR?
easy
A. severity != "ERROR"
B. severity = "ERROR"
C. severity:ERROR
D. severity == "ERROR"
Solution
Step 1: Recall the correct filter syntax for log-based metrics
Google Cloud uses the syntax severity == "ERROR" to filter logs with severity ERROR.
Step 2: Check each option
Double equals (==) is the correct equality operator; single equals (=) is invalid. Colon (:) is for substring matching, not exact equality. != excludes the value.
Final Answer:
severity == "ERROR" -> Option D
Quick Check:
Filter syntax uses == for equality [OK]
Hint: Use double equals sign for filter equality [OK]
Common Mistakes:
Using single equals instead of double
Using colon instead of equals
Using not equals when filtering for ERROR
3. Given this log-based metric filter: resource.type = "gce_instance" AND severity >= "ERROR", what logs will this metric count?
medium
A. All logs from GCE instances with severity ERROR or higher
B. Only logs with severity exactly ERROR from any resource
C. All logs from any resource with severity ERROR or higher
D. Only logs from GCE instances with severity lower than ERROR
Solution
Step 1: Analyze the filter conditions
The filter requires resource.type to be "gce_instance" and severity to be ERROR or higher (like CRITICAL).
Step 2: Match options to filter meaning
All logs from GCE instances with severity ERROR or higher correctly states logs from GCE instances with severity ERROR or higher. Others either ignore resource type or severity condition.
Final Answer:
All logs from GCE instances with severity ERROR or higher -> Option A
Quick Check:
Filter = GCE instance + severity >= ERROR [OK]
Hint: AND means both conditions must be true [OK]
Common Mistakes:
Ignoring resource.type condition
Confusing severity >= ERROR with exact match
Assuming severity lower than ERROR is included
4. You created a log-based metric with filter severity = "ERROR" OR severity = "CRITICAL", but the metric shows zero counts. What is the likely problem?
medium
A. The filter syntax is invalid; OR is not supported in log-based metric filters
B. Severity levels ERROR and CRITICAL do not exist
C. The logs do not have severity fields
D. The metric needs at least 24 hours to show data
Solution
Step 1: Check if the filter syntax is valid
The syntax severity = "ERROR" OR severity = "CRITICAL" is valid; OR is supported in log-based metric filters.
Step 2: Understand impact of zero counts
A valid filter with zero counts indicates no matching logs, likely because the logs do not have severity fields or lack ERROR/CRITICAL values.
Final Answer:
The logs do not have severity fields -> Option C
Quick Check:
Valid filter + zero = no matching logs [OK]
Hint: Zero metric despite valid filter usually means no matching log entries [OK]
Common Mistakes:
Assuming filter syntax invalid
Thinking OR unsupported
Waiting 24 hours unnecessarily
5. You want to create a log-based metric that counts how many times a specific error message appears in logs from Cloud Functions. The error message is in the field jsonPayload.message. Which filter correctly counts logs where the message contains the word "timeout"?
hard
A. resource.type = "cloud_function" AND jsonPayload.message : "timeout"
B. resource.type = "cloud_function" AND jsonPayload.message = "timeout"
C. resource.type = "cloud_function" AND jsonPayload.message >= "timeout"
D. resource.type = "cloud_function" AND jsonPayload.message != "timeout"
Solution
Step 1: Understand how to filter logs containing a word
The colon operator (:) is used to check if a field contains a substring in log filters.
Step 2: Check resource type and filter syntax
resource.type = "cloud_function" AND jsonPayload.message : "timeout" correctly filters logs from Cloud Functions where jsonPayload.message contains "timeout".
Final Answer:
resource.type = "cloud_function" AND jsonPayload.message : "timeout" -> Option A
Quick Check:
Use : to check substring in log filters [OK]
Hint: Use colon : to find substring in log fields [OK]
Common Mistakes:
Using equals instead of colon for substring
Using comparison operators like >= incorrectly
Filtering for not equals when looking for matches
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.