Apply labeling strategy to logs on Grafana Labs

Labels tell you where

Thu, 06 Aug 2026 10:05:27 -0400

Labels tell you where

Loki, which powers Grafana Cloud Logs, takes the idea of a fewest labels principle further than metrics by indexing only your labels, not the log content, so every label combination splits your logs into another stream to index and store.

Good log labels describe the origin or context of the log; for example, application, namespace, environment, cluster, or region. These are static, bounded, and what you actually filter by when you start a search. Loki performs best with few labels, and the fewer streams you create, the smaller the index and the faster your queries.

Use dynamic labels sparingly

Thu, 06 Aug 2026 10:05:27 -0400

Use dynamic labels sparingly

A dynamic label is a label whose value is extracted from a log line’s content at ingestion or query time, which means the label values can vary. This variance can cause a single stream to split into many streams instead of being fixed, or static. For example, if your app writes level=error into each log line, promoting that value to a level label makes it dynamic. Turning an HTTP status class like 2xx or 5xx from access logs into a label is another common case. Use dynamic labels rarely, and only when all of the following are true:

The value set is low-cardinality, ideally tens of values.
The values are long lived, such as the first segment of an HTTP path, not ephemeral IDs.
Users actually query by the label frequently.

Otherwise, don’t index it. Loki’s filter expressions, which search log content at query time, are fast. {app="api"} |= "level=error" performs comparably to a level label for many workloads, without splitting your streams. Don’t add a label until you know you need it.

The decision framework

Thu, 06 Aug 2026 10:05:27 -0400

The decision framework

For any piece of log data, ask where it belongs.

If you filter by it in almost every query, and it’s bounded, make it a label. Example: env, app.
It’s high-cardinality but you query it often, attach it as structured metadata. It’s queryable with a label filter expression, such as {job="example"} | pod="myservice-abc1234-56789", without being indexed or creating streams. Examples: pod names, process IDs, trace IDs.
Everything else, leave it in the log line and extract it at query time with parsers like json or logfmt, or search it with filter expressions.

Audit what your clients send

Thu, 06 Aug 2026 10:05:27 -0400

Audit what your clients send

Collectors and agents can attach dynamic labels you didn’t choose. Use the fewest labels test on whatever Alloy, Fluentd, or your Docker driver is applying. To see your streams and find high-cardinality labels, run:

logcli series '{}' --since=1h --analyze-labels

A label with thousands of unique values found in nearly every stream, such as a requestId, should be removed from labels and queried with a filter expression instead.

If many teams send logs and you can’t audit or change every client, apply the same approach you learned for metrics: route logs through gateway collectors your admin team owns, enforce label policy at that layer, and manage those gateway configurations centrally with Fleet Management.

Resources

Thu, 06 Aug 2026 10:05:27 -0400

Apply labeling strategy to logs on Grafana Labs

Labels tell you where

Labels tell you where

Use dynamic labels sparingly

Use dynamic labels sparingly

The decision framework

The decision framework

Audit what your clients send

Audit what your clients send

Resources

Documentation

Community