Cloud Monitoring Custom Metric Cardinality Design

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 DevOps team is instrumenting an e-commerce application to export custom metrics to Google Cloud Monitoring using the Cloud Monitoring API. A previous version of the application caused severe cardinality explosion and quota exhaustion in Cloud Monitoring.

You need to define a new custom MetricDescriptor and label schema that strictly adheres to Google Cloud specifications while preventing high cardinality and optimizing resource consumption. Which design strategy should you implement?

Modify the existing MetricDescriptor in-place whenever new transaction tracking labels are needed, relying on automatic schema migration to update existing time series.

Include user_id and transaction_id directly as STRING labels in the custom MetricDescriptor to enable granular per-user filtering directly inside Cloud Monitoring metric dashboards.

Define low-cardinality labels such as payment_method and status_code using supported LabelDescriptor value types (STRING, BOOL, or INT64), while recording high-cardinality identifiers like user_id and order_id in Cloud Logging or Cloud Trace.

Generate dynamic label keys named after the unique user_id at runtime and set the LabelDescriptor value type to DOUBLE to capture latency numbers.

Professional Cloud DevOps Engineer

Cloud Monitoring Custom Metric Cardinality Design

Related questions