錯誤 1：高基數炸彈

這是 Prometheus 使用者經常會犯的一個錯，因為 Prometheus 時序是基于多標簽的，它非常靈活，有時你想新增一個標簽，從而將一個粗粒度的指標進行拆分，但切記添加的標簽的值應該做到盡量收斂，不然會導致同一指標名的標簽數量巨大而導致 Prometheus 嚴重的性能問題（OOM）。

舉個例子，您有一個只包含 method 標簽的時間序列 http_requests_total：

http_requests_total{method="POST"}
http_requests_total{method="GET"}
http_requests_total{method="PUT"}
http_requests_total{method="DELETE"}

這個時間序列定義沒問題，因為 HTTP 的 method 類型是有限的，但有一天，您可能想根據用戶 id 進行區分，類似這樣：

http_requests_total{method="POST",user_id="1"}
http_requests_total{method="POST",user_id="2"}
http_requests_total{method="POST",user_id="3"}
[…更多…]
http_requests_total{method="POST",user_id="16434313"}




http_requests_total{method="GET",user_id="1"}
http_requests_total{method="GET",user_id="2"}
http_requests_total{method="GET",user_id="3"}
[…更多…]
http_requests_total{method="GET",user_id="16434313"}
[…更多…]

假設您有非常多的不同用戶，所以此時就存在嚴重的高基數問題，這將導致 Prometheus 內存使用激增，直至 OOM。

所以請您牢記：指標上標簽的每一種唯一組合都會自動創建一個對應時間序列，Prometheus 都會對其進行攝取、索引、存儲和處理。

雖然針對單個標簽的不同值的數量沒有明確的限制，但因為不同值都是一個新的時間序列，您需要確保其數量保持在您 Prometheus 服務器容量之下（一個大型 Prometheus 單節點能夠處理數幾百萬個時間序列），所以你在設計時間序列的標簽的時候，需要確保它們的所有組合總數在您 Prometheus 服務器可以承受的范圍內。

對此，有一些標簽值我們要特別注意避免，例如：

公網 IP 或者郵件地址。

HTTP 請求 Path 全路徑，尤其這些路徑帶有動態 ID 等信息。

進程ID（除非是有限集合）。

有時您想在不完全刪除標簽的情況下解決標簽高基數的問題，那么我們就要想辦法減少其值的基數。例如，對于 /api/users/739567637385/posts/28388445 的 HTTP 請求, 我們將動態信息部分使用 user_id 和 post_id 占位符統一替換，所以整個 path 可以替換為 /api/users/{user_id}/posts/{post_id} ，從而有效減少 path 標簽的值數量。

錯誤 2：告警表達式中因聚合導致價值標簽丟失

在做告警的時候，我們往往會通過聚合計算去除不關心的一些標簽。例如，如果您想確定某個服務的總體錯誤率（跨所有標簽維度）是否過高，您可以編寫如下規則：

sum(rate(errors_total{job="my-job"}[5m])) > 10

這看上去沒問題，但默認情況下，sum() 聚合器會去掉時序的所有標簽。它不僅會刪除您想要聚合的維度（如實例、錯誤類型等），還會刪除一些比較通用的標簽，這些標簽對于 alertmanager 中進行告警的路由或靜默是有幫助的。特別是 job 標簽，因為不同 job 通常由不同的運維團隊負責。因此我們應該盡可能在聚合中保留此標簽：sum by(job) (rate(errors_total{job=”my-job”}[5m])) > 10

一個更好的選擇是通過使用 without() 聚合修飾符替換 by() 聚合修飾符，從而顯示排除不想要的標簽，而盡可能保留下一些你不確定需要刪除的標簽：

sum without(instance, type) (rate(errors_total{job="my-job"}[5m])) > 10

這樣，聚合時您沒有明確指定刪除的標簽在 Alertmanager 中仍然可以使用，這對于告警的聚合和路由非常有用，也能幫助您更好了解警報的來源。

錯誤 3：使用不帶任何限定范圍的（裸）選擇器

在編寫 PromQL 查詢（尤其是告警）的時候，我們需要格外小心，應該從關心的業務或服務的數據中進行查詢，而不是全局范圍。因為不同的業務可能使用了相同的指標名稱，它們甚至表達了不同的含義，隨著時間的推移，相同指標名稱的服務會越來越多，這可能會完全影響您的告警規則或者儀表盤數據。

為避免不小心從不相關的任務或者服務中查詢數據，我們一般使用 job 標簽來限定選擇器的范圍，確保其查詢的數據都是您關心的業務或服務。

例如，以下查詢就是一個不安全的“裸”選擇器，它可能會從您不期望的其他 job 中選擇具有相同指標名的數據：

rate(errors_total[5m]) > 10

我們可以使用 {job=”my-job”} 的選擇器從而將指標限定在 my-job 服務范圍：

rate(errors_total{job="my-job"}[5m]) > 10

這顯然是一個更安全的方式，它可以有效避免從無關服務中查詢數據，對您告警產生干擾，也能大大提升查詢性能。

錯誤 4：告警規則沒有使用 for 字段

for 字段主要用于告警規則評估，它允許您能夠指定任意告警需要在連續的規則評估周期中出現多長時間才從 pending 狀態變為 firing。大多數告警規則可能我們可以忽略該字段，只需要兩個評估周期即可觸發告警，但有時，我們為了排除抖動的干擾，比如一些 CPU 使用率，或者某個節點因為一兩次抓取異常就判定 down 了。

考慮一個警報規則，它使用 up 指標來查找無法成功抓取的目標，并省略了可選的 for 修飾符：

alert: InstanceDownexpr: up == 0

一次失敗的抓取（很容易發生）將導致觸發此規則。通常你希望讓你的警報規則不那么容易觸發，并至少等待幾分鐘，看看問題是否真的存在，然后再觸發通知：

alert: InstanceDownexpr: up == 0for: 5m # 一個實例只有真的掛掉或者無法訪問長達 5 分鐘才創建告警信息。

不帶 for 針對一些內置的帶有平均數計算的查詢表達式也同樣有問題，例如表示高錯誤率的告警：

alert: HighErrorRateexpr: rate(my_errors_total{job="my-job"}[5m]) > 10

這個規則將在第一次查詢到最近 5m 中該錯誤數的平均值 > 10 就立即創建告警，雖然 5m 的平均周期能夠帶來一定的穩健性，但是由于 Promtheus rate() 特性，我們考慮一下，一個完全新的服務或者一段時間未收集到數據會發生什么：

5 分鐘的 rate() 窗口只會考慮一些最近的樣本，實際上并不會對五分鐘的數據進行平均。

時間序列甚至根本還沒五分鐘數據，該規則也可能會立即創建告警。

因此我們可以使用 for 修飾符來解決此問題：

alert: HighErrorRateexpr: rate(my_errors_total{job="my-job"}[5m]) > 10for: 5m

幾乎大多數的告警規則都可以添加此參數，從而使使警報規則更加穩健。但請記住，這也會導致警報的反應時間變慢，因此找到這個平衡很重要。

錯誤 5：rate() 函數窗口時間太短

在太短的時間窗口內計算速率時，您是否曾對間隙或完全空的圖表感到沮喪，例如 rate(my_counter[1m])？rate() 和其他 PromQL 函數（如 increase()、irate()、deriv()）告訴您時間序列在給定時間窗口內上升或下降的速度，在輸入時間窗口下至少需要兩個樣本，從而能夠告訴你這兩個樣本之間的序列是如何發展的。如果將時間窗口設置得太小，則在該窗口下可能只有一個或零個樣本，在這種情況下，輸出結果為空。

例如，如果您采用 20s 的時間窗口對一個 15s 抓取間隔的指標進行 rate()，那么在這 20 秒時間窗口內很可能不會涵蓋兩個樣本，因此您會得到一個與實際結果差異很大的比率：

采取極端的做法：如果將 rate 窗口縮小到 16s，當兩個相距 15s 的點恰好落在任意對齊的 16s 窗口中時，您只會偶爾得到一個輸出點：

因此，您需要選擇一個足夠大的時間窗口——不僅僅是抓取間隔的 2 倍，因為您還需要面對偶爾抓取失敗和不幸的窗口對齊。所以通常我們選擇 rate 窗口大小至少為抓取間隔的 4 倍：

提示：使用 Grafana 時，可以使用 $__rate_interval 模板變量自動為您選擇一個安全間隔。

錯誤 6：rate() 相關函數用錯了指標類型

查詢函數與指標類型用錯的典型例子有：

rate() 函數用在 gauge 類型指標

rate()、irate() 和 increase() 函數被設計成為僅適用于 counter 類型指標。counter 類型是追蹤累計計數的指標，這些計數只會上升（永遠不會下降），除了在追蹤過程中偶爾因為重啟而重置為 0。為了在 rate 計算中盡可能消除計數器重置的影響，這些函數嘗試將提供的時間窗口內樣本的值的任何減小都解釋為重置并對其進行補償。這種計數器的重置檢測和補償意味著您只能從這些函數中獲得正數的結果（或 0）。

如果你不小心傳入了一個可以自然上升和下降的指標（比如內存使用量），PromQL 將無法判斷這個錯誤，而只會返回一個不正確的輸出值。這是因為每次您的儀表指標下降時，rate() 都會將其理解為計數器重置并且會錯誤地“糾正”它。

deriv() 函數用在 counter 類型指標

您可以認為 deriv() 函數大致等同于 rate()，但它作用于 gauge 類型。deriv() 告訴您在輸入時間窗口內 gauge 類型指標每秒上升或下降的速度。雖然并不常見，但這里與 rate() 相同的陷阱可能會給你帶來另外的困擾：因為 deriv() 函數沒有實現任何圍繞 counter 類型重置的邏輯（gauge 沒有這些），試圖使用 deriv() 計算一個在提供的窗口下有重置的 counter 的類型指標，就會得到一個不正確的結果，有時甚至是一個負數。

如何避免傳入錯誤類型的指標？

由于 PromQL 無法自動檢測這種不正確的用法，所以您在使用這些函數時必須格外小心。我們除了經驗和已有知識外，還可以依賴一些開源項目，例如 PromLens 查詢構建器這樣的工具來輔助您檢測是否傳了錯誤的指標類型：

結論

以上 6 點就是一些剛開始使用 Prometheus 的朋友經常會犯的錯誤，希望這些技巧對您使用 Prometheus 的有所幫助！

鏈接：https://blog.51cto.com/u_15576159/8963563

本文翻譯自文章 https://promlabs.com/blog/2022/12/11/avoid-these-6-mistakes-when-getting-started-with-prometheus，感覺作者總結比較深刻，都是 Prometheus 新人們經常犯的錯誤，故簡要翻譯一下，方便和大家一起審查與自省。







審核編輯：劉清