Your team manages microservices deployed on Google Kubernetes Engine (GKE) and collects telemetry using Google Cloud Managed Service for Prometheus with managed collection. A recent FinOps review in the Cloud Monitoring Metrics Management page reveals a major cost spike attributed to custom metric ingestion volume. Upon investigation, you identify two main drivers: The managed collector scrapes the application endpoints every 5 seconds. The application exposes an HTTP request counter metric that includes a high-cardinality user_id label dimension across millions of user sessions. You need to optimize observability costs by decreasing the scraping frequency to 30 seconds and stripping the high-cardinality user_id label before samples are ingested into the backend, without altering the application code. Which configuration should you apply to the PodMonitoring custom resource?

Under `spec.endpoints`, set `interval: 30s` and add a `metricRelabeling` rule with `action: labeldrop` and `regex: user_id`.: ### What Managed Service for Prometheus Metric Relabeling Is In Google Cloud Managed Service for Prometheus (GMP), **managed collection** relies on Kubernetes Custom Resources such as `PodMonitoring` and `ClusterPodMonitoring` to define scraping targets and ingestion configurations. The `metricRelabeling` section implements standard **Prometheus relabeling rules** (`metric_relabel_configs`) applied to scraped samples immediately before they are ingested into the global **Monarch** datastore. ### How It Meets the Requirements - **Adjusting Scraping Interval:** Updating `spec.endpoints[].interval` to `30s` reduces the collection frequency from 12 samples per minute to 2 samples per minute per time series, resulting in an immediate **83.3% reduction** in baseline sample ingestion rate. - **Filtering High-Cardinality Dimensions:** Setting `action: labeldrop` with `regex: user_id` in the `metricRelabeling` pipeline removes the `user_id` label from the scraped metric samples prior to storage. This aggregates the remaining dimensions and collapses millions of ephemeral time series into a small set of persistent streams. - **Zero Code Changes:** Applying this transformation directly in the Kubernetes operator configuration eliminates the need to refactor, recompile, or redeploy application source code. ### Key Advantages and Capabilities - **Sample-Based Cost Optimization:** Because GMP bills primarily on the number of metric samples ingested, combining lower scrape intervals with label dropping yields dramatic financial savings. - **Pre-Ingestion Filtering:** Metric relabeling occurs in memory on the local collector daemon before network transit and storage ingestion, preventing billable writes. - **Granular Control:** Allows fine-grained manipulation of Prometheus metrics using upstream actions like `keep`, `drop`, `labeldrop`, and `labelkeep`. - **Declarative GitOps Management:** `PodMonitoring` resources can be versioned and deployed automatically via standard Kubernetes CI/CD and Terraform workflows. ### Why This Is Optimal This configuration directly targets the two core drivers of observability costs in sample-metered environments: **sample ingestion frequency** and **active time series cardinality**. Modifying the `PodMonitoring` custom resource is the native, Google-recommended approach for managed collection on GKE.

Gmp Podmonitoring Scrape Interval Labeldrop | Professional Cloud DevOps Engineer

Gmp Podmonitoring Scrape Interval Labeldrop

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 team manages microservices deployed on Google Kubernetes Engine (GKE) and collects telemetry using Google Cloud Managed Service for Prometheus with managed collection. A recent FinOps review in the Cloud Monitoring Metrics Management page reveals a major cost spike attributed to custom metric ingestion volume.

Upon investigation, you identify two main drivers:

The managed collector scrapes the application endpoints every 5 seconds.
The application exposes an HTTP request counter metric that includes a high-cardinality user_id label dimension across millions of user sessions.

You need to optimize observability costs by decreasing the scraping frequency to 30 seconds and stripping the high-cardinality user_id label before samples are ingested into the backend, without altering the application code.

Which configuration should you apply to the PodMonitoring custom resource?

Under spec.endpoints, set interval: 30s and configure targetLabels.fromPod to exclude the user_id pod metadata label.

Under spec, set scrape_interval: 30s and add an Ops Agent processors block of type exclude_metrics matching metric_pattern: user_id.

Under spec.endpoints, set interval: 30s and configure PromQL recording rules in Cloud Monitoring to aggregate away user_id at query time.

Under spec.endpoints, set interval: 30s and add a metricRelabeling rule with action: labeldrop and regex: user_id.

Professional Cloud DevOps Engineer

Gmp Podmonitoring Scrape Interval Labeldrop

Related questions