背景

近期發現自己實驗用的 Prometheus 效能出現瓶頸, 經常會出現如下告警:

• PrometheusMissingRuleEvaluations
• PrometheusRuleFailures

之後慢慢排查發現是由於 Prometheus 的某些 series 的高基數(High Cardinality)導致的. 本文是對 Prometheus 高基數問題的一次全面總結.

什麼是基數(Cardinality)?

基數的基本定義是指一個給定集合中的元素的數量。

在Prometheus和可觀察性的世界裡，標籤基數是非常重要的，因為它影響到你的監控系統的效能和資源使用。

下面這張圖, 可以清晰地反應基數的重要性:

簡單地說。基數 是指一個標籤的總體數值的計數。在上面的例子中，標籤status_code的基數是5，(即:1xx 2xx 3xx 4xx 5xx),environment的基數是2(即prod dev)，而指標server_responses的總體基數是10。

多少算高基數?

一般來說:

• 較低的基數 1:5的標籤值比率，
• 標準基數 1:80的標籤值比率
• 高基數 1:10000的標籤值比率。

還是上面的例子, 如果 status_code 是詳細的code, 如200 404..., 那它的基數就可能高達數百個, environment的基數再多一些, 指標server_responses的總體基數就會迅速膨脹.

高基數的典型案例

這還不夠形象, 再舉 2 個特別典型的例子:

1. 有一個指標叫做: http_request_duration_seconds_bucket
   1. 它有 instance label, 對應 100 個範例;
   2. 有 le label, 對應的是不同的 buckets, 有 10 個 buckets, 如(0.002 0.004 0.008 ... =+inf)
   3. 它還有 url 這個 label, 對應的是不通的 url:
      1. 即使規模很小, url 可能也會有 400 個 url
      2. 這裡還有個特別恐怖的隱患, 就是對於大規模系統來說, 這個 url 可能是近乎於無窮!!!
   4. 它還有 http_method 這個label, 對應有 5 個 http method
   5. 在這種情況下, 該指標的 label
      1. 小規模也會有: 100*10*400*5=2 000 000 200萬個 series