Soru

Zorluk: OrtaDefining and Managing SLOs, SLIs, and Error Budgets

A global freight logistics platform processes time-critical shipment dispatch requests using a Cloud Run microservice. The Site Reliability Engineering (SRE) team has established a Service Level Objective (SLO) requiring a 99.9% success rate for HTTP request processing over a rolling 30-day window. During a recent minor service degradation, 15% of the 30-day error budget was consumed over a 2-hour period without triggering an alert because alerting was configured using a static 5-minute error rate threshold set at 5%. The team needs to redesign the alerting mechanism to ensure prompt notification for high budget burn rates while avoiding false-alarm fatigue caused by brief transient spikes. Which alerting implementation should the Cloud Architect recommend?

  1. Implement multi-window, multi-burn-rate alerting in Cloud Monitoring that evaluates error budget consumption across both short and long lookback windows.Cevap
  2. B
    Configure static threshold alerts in Cloud Monitoring to notify the on-call engineer whenever Cloud Run CPU utilization exceeds 85% for more than 10 minutes.
  3. C
    Reduce the static error rate alert threshold from 5% to 0.1% while maintaining a 1-minute evaluation window.
  4. D
    Redefine the Service Level Indicator (SLI) metric to measure the remaining error budget percentage rather than the ratio of successful HTTP requests.

Cevap

Implement multi-window, multi-burn-rate alerting in Cloud Monitoring that evaluates error budget consumption across both short and long lookback windows.
The correct recommendation is to implement multi-window, multi-burn-rate alerts. In Google SRE practices, monitoring error budget burn rates over short lookback windows (e.g., 5 minutes and 1 hour) catches severe outages rapidly, while checking longer lookback windows (e.g., 6 hours and 3 days) ensures sustained smaller error rates are caught before depleting the 30-day budget.

Adım Adım Çözüm

1
Analyze the existing alerting defect
The current static 5-minute threshold of 5% failed to detect a sustained 2-hour degradation that consumed 15% of the total monthly error budget.
Static single-window thresholds cannot balance fast detection of sustained low-rate budget leaks with immunity to short-lived spikes.
2
Evaluate SRE best practices for SLO-based alerting
Multi-window, multi-burn-rate alerting calculates burn rates over multiple time windows (e.g., short windows for rapid depletion and longer windows for gradual depletion).
This approach ensures critical alerts fire quickly when large fractions of the error budget are consumed, while preventing alert fatigue.
3
Select the optimal GCP Cloud Monitoring strategy
Configuring Cloud Monitoring burn-rate alerts with multiple lookback windows directly addresses both fast and slow budget consumption scenarios.
This aligns precisely with Google SRE principles and standard GCP Cloud Architect operational requirements.

Anahtar Kavram

Multi-window, multi-burn-rate SLO alerting for error budget management
Bu soruyu puanla