Cloud Monitoring Custom Metric Cardinality Design

What Custom Metric Descriptors and Low-Cardinality Labels Are

In Google Cloud Monitoring, a MetricDescriptor defines the schema and metadata for a specific metric type (for example, custom.googleapis.com/checkout/transaction_count). Each metric is uniquely identified by the combination of its metric type and specific key-value pairs for all labels defined in its descriptor. The LabelDescriptor dictates the key name and data type (STRING, BOOL, or INT64) for each dimension.

How It Meets the Requirements

• Prevents Cardinality Explosion: Each distinct set of label values creates a separate time series. Using bounded, low-cardinality values such as payment_method (e.g., credit_card, paypal) and status_code (e.g., 200, 500) keeps the total number of active time series manageable and prevents exceeding Cloud Monitoring API rate limits and memory quotas.
• Adheres to Cloud Monitoring Specifications: The design uses valid label data types (STRING, BOOL, or INT64) and ensures valid label key syntax ([a-zA-Z][a-zA-Z0-9_]*).
• Preserves Diagnostic Context: High-cardinality fields like user_id, order_id, and transaction_id are redirected to Cloud Logging or distributed traces via Cloud Trace (or OpenTelemetry exemplars), where high-cardinality lookups are fully supported without inflating time series storage.

Key Advantages and Capabilities

• Fast Query Performance: Aggregations across bounded time series execute rapidly in Cloud Monitoring dashboards and alerting policies.
• Resource Efficiency: Eliminates excessive metric ingestion costs and avoids hitting time series creation limits.
• Correlated Observability: Enables linking summary metrics in Cloud Monitoring directly to detailed traces and structured logs for root-cause analysis.

Why This Is Optimal

Cloud Monitoring time series storage is optimized for time-series aggregation, not per-transaction record indexing. Separating metrics (telemetry aggregation) from logs and traces (event investigation) follows Google Cloud observability best practices.