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.