An SRE team is configuring Service Level Objectives (SLOs) in Google Cloud Monitoring for two distinct workloads: Workload 1: A user-facing microservice running on Google Kubernetes Engine (GKE) that requires an SLI tracking whether request latency remains under 200 milliseconds. Workload 2: A batch processing pipeline running on Cloud Dataproc that requires an SLI tracking the correctness of batch jobs (successful versus failed submissions). You need to define quantifiable, request-based Service Level Indicators (SLIs) in Cloud Monitoring that accurately represent the ratio of good events to valid total events for both workloads. Which configuration approach should the SRE team use?

Configure a custom DistributionCut SLI specifying an acceptable latency range below 200 ms for Workload 1, and configure a custom TimeSeriesRatio SLI specifying `cluster/job/submitted_count` for the total filter and `cluster/job/failed_count` for the bad service filter for Workload 2.: ### What Custom SLIs with DistributionCut and TimeSeriesRatio Are In **Google Cloud Monitoring**, custom Service Level Indicators (SLIs) allow teams to define compliance criteria when standard pre-computed mesh or platform metrics are not automatically populated. Custom SLIs are constructed as ratios of valid positive (good) events to total valid events using either **DistributionCut** (for histogram/distribution metrics) or **TimeSeriesRatio** (for counter/gauge time-series metrics). ### How It Meets the Requirements - **Latency Tracking for Workload 1 (GKE):** GKE custom services do not have built-in default latency indicators. A **DistributionCut** SLI takes a latency distribution metric and establishes a numerical range (e.g., `< 200 ms`). The ratio of request samples falling within this acceptable range compared to all recorded samples defines the request-based latency SLI. - **Job Correctness for Workload 2 (Dataproc):** Dataproc exports job metrics such as `cluster/job/submitted_count` and `cluster/job/failed_count`. Using a **TimeSeriesRatio** structure (`goodTotalRatio`), Cloud Monitoring computes the ratio of good executions against total valid executions by setting `submitted_count` as the total service filter and `failed_count` as the bad service filter. ### Key Advantages - **Precise mathematical formulation:** Measures true ratios of `(good events) / (total valid events)` across disparate metric formats. - **Native integration:** Integrates directly with Cloud Monitoring SLO error-budget calculations and burn-rate alerting. - **Flexibility across workload types:** Adapts cleanly to both continuous microservices and discrete batch processing pipelines. ### Why This Is Optimal This approach directly aligns with SRE best practices and Google Cloud's API structures for service monitoring, allowing both distribution-based latency and counter-based batch job correctness to be monitored within a single, unified SLO framework.

Cloud Monitoring Sli Formulation Gke Dataproc | Professional Cloud DevOps Engineer

Cloud Monitoring Sli Formulation Gke Dataproc

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.

An SRE team is configuring Service Level Objectives (SLOs) in Google Cloud Monitoring for two distinct workloads:

Workload 1: A user-facing microservice running on Google Kubernetes Engine (GKE) that requires an SLI tracking whether request latency remains under 200 milliseconds.
Workload 2: A batch processing pipeline running on Cloud Dataproc that requires an SLI tracking the correctness of batch jobs (successful versus failed submissions).

You need to define quantifiable, request-based Service Level Indicators (SLIs) in Cloud Monitoring that accurately represent the ratio of good events to valid total events for both workloads.

Which configuration approach should the SRE team use?

Configure a standard Availability SLI using default Cloud Service Mesh metrics for Workload 1, and configure an uptime check with a windowed goodness criterion for Workload 2.

Configure a Windows-based SLI using arithmetic mean latency for Workload 1, and configure an alerting policy that calculates the 5-minute moving average of Dataproc failed jobs for Workload 2.

Configure a custom DistributionCut SLI specifying an acceptable latency range below 200 ms for Workload 1, and configure a custom TimeSeriesRatio SLI specifying cluster/job/submitted_count for the total filter and cluster/job/failed_count for the bad service filter for Workload 2.

Configure a TimeSeriesRatio SLI with a ratio of 99th-percentile CPU utilization for Workload 1, and configure a DistributionCut SLI filtering for cluster/job/duration below 100 seconds for Workload 2.

Professional Cloud DevOps Engineer

Cloud Monitoring Sli Formulation Gke Dataproc

Related questions