A DevOps team manages a web microservice behind an External HTTP(S) Load Balancer in Google Cloud. To maintain strict service level objectives, they need to establish an automated alerting system that notifies the Site Reliability Engineering (SRE) team via PagerDuty whenever the HTTP 5xx error rate from the load balancer exceeds 2% of total requests over a 5-minute rolling window. Which configuration sequence in Google Cloud Observability should the team perform to meet this operational goal?
- AGrant the SRE team's service account the primitive Owner role at the project level so that Cloud Monitoring can automatically route error threshold alerts to external webhook endpoints.
- Create an alerting policy in Cloud Monitoring selecting the load balancer HTTP response count metric, define a threshold condition for HTTP 5xx response codes over a 5-minute alignment window, and attach a configured PagerDuty notification channel.Answer
- CInstall the legacy Stackdriver Monitoring agent package on the load balancer backend Compute Engine instances and update local agent configuration files to forward syslog HTTP error counts directly to external incident endpoints.
- DEnable the Cloud Monitoring API at the parent Organization node level rather than the project level, relying on default resource hierarchy inheritance to generate 5xx error incident alerts.
Answer
Create an alerting policy in Cloud Monitoring based on the load balancer HTTP response count metric, configure a threshold condition for 5xx codes over a 5-minute window, and attach the PagerDuty notification channel.
The standard and effective way to alert on infrastructure performance in GCP is to create a Cloud Monitoring alerting policy based on GCP-collected metrics (such as Load Balancer response counts), define threshold logic over an alignment period, and link notification channels like PagerDuty.
Step-by-Step Solution
Key Concept
Cloud Monitoring Alerting Policies and Notification Channels
Estimated Time:1m 30s