Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Update labels, add cardinality topic #15399

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

JStickler
Copy link
Contributor

What this PR does / why we need it:

Reorganizes and revises the Labels topic to take into account:

  • New default service_name label
  • Label defaults for OTEL
  • Provides additional guidance to help customers avoid known issues with labels

Adds a new topic for cardinality.

@JStickler JStickler added the type/docs Issues related to technical documentation; the Docs Squad uses this label across many repositories label Dec 12, 2024
@JStickler JStickler requested a review from a team as a code owner December 12, 2024 18:06

- deployment_environment = development
- host = server-1
- pod_name = myapp-abcdef
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pod_name is a tough one because I have seen users with unique hashes added to their podnames. In most cases if the name is static its fine. But there are cases like this:

NAME                                           READY   STATUS    RESTARTS   AGE
nginx-554b9c67f9-c5cv4                         1/1     Running   0          74s
nginx-554b9c67f9-hjkjq                         1/1     Running   0          74s
nginx-554b9c67f9-wbwdm                         1/1     Running   0          2m7s

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see pod name frequently called out as a poor label choice in Slack, which is why I put it on the list.

For Grafana Cloud Logs, see the [current OpenTelemetry guidance](https://grafana.com/docs/grafana-cloud/send-data/otlp/otlp-format-considerations/#logs).
{{< /admonition >}}

The default list of Resource Attributes to store as labels can be configured using `default_resource_attributes_as_index_labels` under the [distributor's otlp_config](https://grafana.com/docs/loki/<LOKI_VERSION>/configure/#distributor). If you are using Grafana Cloud, contact support to configure this setting.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if this has changed but you can also promote and exclude labels otel via the limits_config

limits_config:
  otlp_config:

- Unsupported characters in the label should be converted to an underscore. For example, the label `app.kubernetes.io/name` should be written as `app_kubernetes_io_name`.
- However, do not begin and end your label names with double underscores, as this naming convention is used for internal labels, for example, \__stream_shard__, that are hidden by default in the label browser, query builder, and autocomplete to avoid creating confusion for users.

In Loki, you do not need to add labels based on the content of the log message.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slight repeat of line 140 but its good for emphasis


High cardinality causes Loki to create many streams, especially when labels have many unique values, and when those values are short-lived (for example, active for seconds or minutes). This causes Loki to build a huge index, and to flush thousands of tiny chunks to the object store.

Loki was not designed or built to support high cardinality label values. In fact, it was built for exactly the opposite. It was built for very long-lived streams and very low cardinality in the labels. In Loki, the fewer labels you use, the better.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels slightly a repeat of line 22 but

@Jayclifford345
Copy link
Contributor

Really great write up on labels and cardinality. These are just a few points I noticed but they are only suggestions :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/L type/docs Issues related to technical documentation; the Docs Squad uses this label across many repositories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants