Why does my labelExtractor produce no data even though matching log entries clearly exist?

Every key used in labelExtractors must also be explicitly declared in metricDescriptor.labels with a matching key and valueType, or the extractor has nothing to attach its extracted value to and is effectively a no-op. This is the most common reason a metric shows entries matching the filter but zero label breakdown in the resulting data.

What's the difference between a counter metric and a distribution metric here?

A counter (metricKind DELTA, valueType INT64) just counts how many log entries matched the filter in each interval, useful for error rates or event counts. A distribution metric tracks a numeric value extracted from each entry (like latency or payload size) across bucketOptions-defined ranges, letting you compute percentiles, not just a raw count, at the cost of needing a valid numeric value extractable from every matched entry.

Does version V1 vs V2 actually matter for a new metric?

Yes for anything with label-based breakdowns; V2 is the current metric version and has different (generally more generous) limits around label cardinality and metric descriptor behavior compared to legacy V1 metrics. New metrics should be created as V2 unless you have a specific compatibility reason not to.

GCP Log Metric Builder

MonitoringGCP

Build Cloud Logging metric filter configurations with label extractors and bucket options.

Cloud Logging Metrics Configuration

Build Cloud Logging metric filter configurations with label extractors, metric descriptors, and bucket options for custom metrics.

Required Fields

namefiltermetricDescriptor.metricKindmetricDescriptor.valueType

Generated Output

Output will appear here...

About This Tool

Build a Cloud Logging user-defined metric, either a counter metric (metricKind DELTA, valueType INT64) that just counts matching log entries, or a distribution metric that also tracks a numeric value's spread via bucketOptions. labelExtractors pull values out of matched log entries using EXTRACT for a direct field reference or REGEXP_EXTRACT for pattern-based extraction, and each labeled dimension must also be declared in metricDescriptor.labels or the extractor is silently ignored at metric-creation time. Version V2 is the current schema; a metric declared under the older V1 semantics behaves differently around label cardinality limits.

Real-World Scenario

A team builds a distribution metric intended to track error counts broken down by error_type, extracted via REGEXP_EXTRACT from a JSON payload field, and the metric shows the right total count in Cloud Monitoring but every single data point has an empty error_type label, making the per-category breakdown dashboard useless. Reviewing the metric definition shows error_type is used in labelExtractors but was never added to metricDescriptor.labels, so the extracted values have nowhere to attach. They use the builder to add the missing label declaration alongside the existing extractor, and after redeploying the metric definition, new log entries start populating the error_type breakdown correctly (existing historical data before the fix stays unlabeled).

When to Use This Tool

•Building a distribution metric with exponentialBuckets to track request latency parsed out of structured log entries, when the service doesn't already export a native latency metric to Cloud Monitoring.
•Adding a REGEXP_EXTRACT labelExtractor to pull a normalized error_type out of a free-text jsonPayload.error_type field, so error-rate dashboards can group by category instead of by raw, high-cardinality message text.
•Debugging why a labelExtractor isn't populating any values on the resulting metric, tracing it to the label being used in labelExtractors but never declared in metricDescriptor.labels.
•Scoping a metric's filter tightly to one resource.type and severity level, since an overly broad filter both slows down metric computation and risks blowing past per-metric label cardinality limits.

Pro Tips

TIP

A label declared in metricDescriptor.labels but never populated by any labelExtractor just shows up empty in every data point, which looks like a bug but is actually a metric definition that's half-wired, always pair every declared label with a matching extractor.

TIP

High-cardinality label values (like a raw user ID or a full unbounded error message string) can blow past per-metric time-series limits quickly, keeping a metric perpetually in a degraded or capped state, always extract a bounded, normalized category rather than raw high-cardinality text.

TIP

bucketOptions.exponentialBuckets parameters (numFiniteBuckets, growthFactor, scale) are set once at metric creation and aren't easy to retune without recreating the metric and losing bucket-comparable history, pick a bucket range that covers your actual expected value distribution up front.

How It Works Under the Hood

The builder requires name, filter, metricDescriptor.metricKind, and metricDescriptor.valueType to resolve, the minimum fields the Logging API needs to define a metric and know whether it's a simple counter or a value-bearing distribution; labelExtractors and bucketOptions are validated as well-formed JSON but their internal consistency (every extractor label also declared, bucket ranges matching real data) is on you to verify.

Frequently Asked Questions

Why does my labelExtractor produce no data even though matching log entries clearly exist?: Every key used in labelExtractors must also be explicitly declared in metricDescriptor.labels with a matching key and valueType, or the extractor has nothing to attach its extracted value to and is effectively a no-op. This is the most common reason a metric shows entries matching the filter but zero label breakdown in the resulting data.
What's the difference between a counter metric and a distribution metric here?: A counter (metricKind DELTA, valueType INT64) just counts how many log entries matched the filter in each interval, useful for error rates or event counts. A distribution metric tracks a numeric value extracted from each entry (like latency or payload size) across bucketOptions-defined ranges, letting you compute percentiles, not just a raw count, at the cost of needing a valid numeric value extractable from every matched entry.
Does version V1 vs V2 actually matter for a new metric?: Yes for anything with label-based breakdowns; V2 is the current metric version and has different (generally more generous) limits around label cardinality and metric descriptor behavior compared to legacy V1 metrics. New metrics should be created as V2 unless you have a specific compatibility reason not to.

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.