Try to keep values bounded to as small a set as possible. We don’t have perfect guidance as to what Loki can handle, but think single digits, or maybe 10’s of values for a dynamic label. This is less critical for static labels. For example, if you have 1,000 hosts in your environment it’s going to be just fine to have a host label with 1,000 values.
From my understanding, each combination of labels in Loki will create a new stream. So request=GET,host=my-host-1 will write to a different file than request=POST,host=my-host-1.
But what is a dynamic vs a static label? Searching “loki static vs dynamic labels” does not yield useful results.
My best guess is–if we describe labels as key, value pairs–then static labels are ones where the key is fixed but the value can be anything & dynamic labels are ones where both the key & value can be anything.
I think the keywords “static” and “dynamic” apply to the way you define label values, as all labels work in the same way. For example, labels such as service, host, level, and even request would be considered static as they have somewhat fixed cardinality. On the other hand, if you create labels for cookie values or user IP addresses their cardinality can be considered unbound (on the Loki scale).
As I understand, the main point of the documentation is that you should always have an overview of all possible label values. The majority of the streams should be constant, and not created and deleted every several minutes.
In addition, it is suggested to minimize your label usage. For example, in most of the scenarios querying logs based only on the request type would not make much sense so it is better to have them included as text and use line filters: {host="my-host-1"} |= "GET". Anyway, this would not create any major difference if you are running Loki on a low scale, but for bigger deployments, it would optimize resource usage.
