You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This documentation recommends keeping cardinality low, which is good advice, but its definition of "low" is bizarre.
As a general guideline, try to keep the cardinality of your metrics below 10, and for metrics that exceed that, aim to limit them to a handful across your whole system. The vast majority of your metrics should have no labels.
If you have a metric that has a cardinality over 100 or the potential to grow that large, investigate alternate solutions such as reducing the number of dimensions or moving the analysis away from monitoring and to a general-purpose processing system.
I have never seen a metric with cardinality below 10 in the wild, A simple latency metric that uses default prometheus bucketing and runs on 9 hosts will hit 100. This gives new engineers a very incorrect idea of what prometheus is capable of and I think it should be changed.
The text was updated successfully, but these errors were encountered:
Doc: https://prometheus.io/docs/practices/instrumentation/
This documentation recommends keeping cardinality low, which is good advice, but its definition of "low" is bizarre.
I have never seen a metric with cardinality below 10 in the wild, A simple latency metric that uses default prometheus bucketing and runs on 9 hosts will hit 100. This gives new engineers a very incorrect idea of what prometheus is capable of and I think it should be changed.
The text was updated successfully, but these errors were encountered: