Cloud Monitoring Ratio Alerting Custom Metrics

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your DevOps team is implementing a Service Level Objective (SLO) error-rate alerting policy in Google Cloud Monitoring for a microservice deployed across 200 Compute Engine virtual machine (VM) instances. The initial configuration computed a ratio across two independent custom metrics: custom.googleapis.com/rpc/total_count and custom.googleapis.com/rpc/error_count.

During low-traffic intervals, on-call engineers receive frequent false-positive alerts caused by anomalous ratio spikes (such as 1/0 or 2/1) evaluated on individual instances. You need to redesign the custom metrics, alignment, and alerting policy condition to eliminate these ratio calculation anomalies, reduce alert fatigue, and minimize monitoring costs.

What should you do?

Retain the two separate custom metrics, set the rolling window function to percent change without alignment, and create 200 distinct single-condition alerting policies targeting each individual VM instance.

Consolidate into a single custom metric type that records all RPCs and uses a response status label, then configure the alerting condition to aggregate across instances using an alignment window longer than the metric sampling period.

Retain both separate custom metrics, set the condition alignment window to 1 second to capture real-time granularity, and evaluate the ratio across raw, unaggregated time series for each VM instance.

Combine a LogMatch condition scanning application error logs with a MetricThreshold ratio condition in a single multi-condition alerting policy using unaggregated log views.

Professional Cloud DevOps Engineer

Cloud Monitoring Ratio Alerting Custom Metrics

Related questions