Log-based metrics in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Log-based Metric Behavior

You create a log-based metric in Google Cloud Logging to count the number of error logs containing the word "Timeout". After deploying, you notice the metric value remains zero even though errors occur.

What is the most likely reason?

A The filter for the log-based metric does not include the correct severity level or text match for "Timeout".

B The metric is delayed by 24 hours before showing any data.

C Log-based metrics only count logs from Cloud Storage buckets, not from Compute Engine.

D The metric requires manual data import from logs before it starts counting.

💡 Hint

Check how the filter matches logs for the metric.

Log-based metrics count logs matching their filter immediately. If the filter is incorrect or too narrow, no logs match, so the metric stays zero.

❓ Configuration

intermediate

Creating a Counter Log-based Metric Filter

You want to create a counter log-based metric that counts all HTTP 500 errors logged by your application in Cloud Logging.

Which filter correctly matches these logs?

A resource.type="gce_instance" AND severity>=ERROR AND jsonPayload.status=500

B resource.type="gce_instance" AND severity="ERROR" AND jsonPayload.status=500

C resource.type="http_load_balancer" AND severity="ERROR" AND jsonPayload.status_code=500

D resource.type="http_load_balancer" AND severity="ERROR" AND jsonPayload.status=500

💡 Hint

Check the resource type and field names used in your logs.

The filter must match the resource type where the logs come from and the exact field name for the HTTP status code. Typically, Compute Engine instances use resource.type="gce_instance" and the status code field is jsonPayload.status.

❓ Architecture

advanced

Designing Log-based Metrics for Cost Efficiency

Your team wants to monitor specific error patterns in logs but minimize costs from exporting large volumes of logs. Which approach best balances detailed monitoring and cost control?

A Disable log-based metrics and rely on manual log scanning to reduce costs.

B Export all logs to BigQuery and create metrics from there to avoid using log-based metrics.

C Create a single broad log-based metric counting all errors and export all logs to Cloud Storage.

D Create multiple detailed log-based metrics with narrow filters and export only metric data to BigQuery.

💡 Hint

Think about how log-based metrics and exports affect cost.

Log-based metrics count logs internally and export only metric data, which is cheaper than exporting all logs. Using narrow filters reduces metric data volume. Exporting all logs is costly.

❓ security

advanced

Securing Access to Log-based Metrics

You want to restrict who can create or modify log-based metrics in your Google Cloud project to prevent unauthorized changes.

Which IAM role should you assign to users who need to manage log-based metrics?

A roles/monitoring.metricWriter

B roles/logging.admin

C roles/logging.viewer

D roles/owner

💡 Hint

Check which role allows managing logging configurations.

The roles/logging.admin role allows creating and modifying log-based metrics. roles/logging.viewer only allows viewing logs. roles/monitoring.metricWriter is for monitoring metrics but not logging configs. roles/owner is too broad.

✅ Best Practice

expert

Optimizing Log-based Metric Filters for Performance

You have a log-based metric with a complex filter that includes multiple OR conditions and regex matches. You notice the metric updates slowly and sometimes misses logs.

Which change will most improve performance and accuracy?

A Increase the metric's sampling rate to capture more logs.

B Add more regex patterns to cover all possible log variations in one filter.

C Simplify the filter by replacing OR conditions with multiple separate metrics each with simpler filters.

D Use a single broad filter without conditions to capture all logs and filter later in monitoring tools.

💡 Hint

Think about how complex filters affect log processing.

Complex filters with many ORs and regexes slow down log processing and can cause missed matches. Splitting into multiple simpler metrics improves performance and accuracy.

Practice

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

1. Step 1: Understand what log-based metrics do

   Log-based metrics count log entries that match a filter and convert them into numerical data.

2. 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.

3. Final Answer:

   To count specific log entries and turn them into numbers you can monitor -> Option B

4. 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

1. Step 1: Recall the correct filter syntax for log-based metrics

   Google Cloud uses the syntax severity == "ERROR" to filter logs with severity ERROR.

2. 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.

3. Final Answer:

   severity == "ERROR" -> Option D

4. 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

1. Step 1: Analyze the filter conditions

   The filter requires resource.type to be "gce_instance" and severity to be ERROR or higher (like CRITICAL).

2. 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.

3. Final Answer:

   All logs from GCE instances with severity ERROR or higher -> Option A

4. 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

1. 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.

2. 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.

3. Final Answer:

   The logs do not have severity fields -> Option C

4. 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

1. 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.

2. 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".

3. Final Answer:

   resource.type = "cloud_function" AND jsonPayload.message : "timeout" -> Option A

4. 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