Question

Difficulty: MediumDefining and Managing SLOs, SLIs, and Error Budgets

A video streaming platform hosts its user authentication and session management microservice on Google Cloud Run. The Site Reliability Engineering (SRE) team defines a monthly availability Service Level Objective (SLO) of 99.9%99.9\% based on the ratio of successful HTTP responses (2xx2\text{xx} and 3xx3\text{xx}) to total requests. To prevent alert fatigue while ensuring fast detection of rapid error budget consumption, which alerting strategy should the SRE team implement?

  1. Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to trigger when short-term (e.g., 5-minute and 1-hour) and long-term (e.g., 6-hour and 3-day) budget consumption rates exceed defined thresholds.Answer
  2. B
    Set up a static threshold alert in Cloud Monitoring that triggers whenever the HTTP 5xx error rate exceeds 0.1% over a single rolling 5-minute window.
  3. C
    Create an automated metric alert that triggers whenever Cloud Run CPU utilization exceeds 85% for more than 10 minutes.
  4. D
    Trigger a high-priority alert whenever the measured Service Level Indicator (SLI) value falls below the 99.9% target Service Level Objective (SLO) for any single minute.

Answer

Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to trigger when short-term (e.g., 5-minute and 1-hour) and long-term (e.g., 6-hour and 3-day) budget consumption rates exceed defined thresholds.
Configuring multi-window, multi-burn-rate alerts in Cloud Monitoring is the Google SRE standard for monitoring SLO error budget consumption. It evaluates both short-term lookback windows (to quickly detect catastrophic outages) and long-term lookback windows (to detect subtle, persistent bugs draining the budget over days), while drastically reducing alert noise.

Step-by-Step Solution

1
Analyze the operational goal
The team needs an alerting strategy that detects both fast and slow exhaustion of the error budget without causing alert fatigue.
Alert fatigue occurs when alerts trigger on transient spikes or non-actionable events, whereas missing slow burn rates leads to unexpected SLO breaches.
2
Evaluate SRE best practices for Cloud Monitoring SLO alerting
Google SRE practices mandate multi-window, multi-burn-rate alerting.
Using multiple lookback windows (e.g., short 5-minute/1-hour windows paired with longer 6-hour/3-day windows) ensures high precision and recall by requiring sustained error budget consumption before notifying engineers.
3
Compare against static and infrastructure-based alerting options
Static single-window threshold alerts and infrastructure metric alerts fail to align directly with error budget burn rate dynamics.
Static metrics ignore error budget remaining capacity, and CPU utilization does not directly measure HTTP request availability.

Key Concept

Multi-window, multi-burn-rate alerting for SLO error budgets
Rate this question