[英]Kubernetes: Comparing RSS Memory Usage of Pods and Pod Memory Requirements in Prometheus / PromQL
[英]Prometheus query quantile of pod memory usage performance
我想獲得上次 x 次我的 pod 的 0.95 個百分位數 memory 使用情況。 但是,如果我使用“大”(7 / 10d)范圍,此查詢開始花費的時間太長。
我現在使用的查詢是:
quantile_over_time(0.95, container_memory_usage_bytes[10d])
大約需要 100 秒才能完成
為了簡潔起見,我刪除了額外的命名空間過濾器
我可以采取哪些步驟來提高此查詢的性能? (除了把機器做大)
我考慮過每 x 次(假設 30 分鍾)和 label 計算 0.95 個百分位數p95_memory_usage並在查詢中使用p95_memory_usage而不是container_memory_usage_bytes ,這樣我就可以將查詢必須通過的點數減少到 go。
但是,這不會扭曲價值觀嗎?
正如您已經觀察到的,總計分位數(隨着時間的推移或其他方式)並沒有真正起作用。
您可以嘗試使用記錄規則建立一段時間內內存使用情況的直方圖,看起來像一個“真實的”普羅米修斯直方圖(由_bucket
, _count
和_sum
指標組成),盡管這樣做可能很乏味。 就像是:
- record: container_memory_usage_bytes_bucket
labels:
le: 100000.0
expr: |
container_memory_usage_bytes > bool 100000.0
+
(
container_memory_usage_bytes_bucket{le="100000.0"}
or ignoring(le)
container_memory_usage_bytes * 0
)
對您感興趣的所有存儲桶大小重復上述步驟,然后添加_count
和_sum
指標。
直方圖可以聚合(隨時間推移或其他方式)而不會出現問題,因此您可以使用第二組記錄規則,以較低的分辨率(例如每小時或每天增加,每小時或每天分辨率)計算直方圖指標的增加。 最后,您可以在低分辨率直方圖(比原始時間序列少的樣本)上使用histogram_quantile
來計算分位數。
不過,這需要進行大量工作,並且會有一些缺點:您只會每小時/每天對分位數進行一次更新,而准確性可能會更低,具體取決於您定義的直方圖桶數。
否則(這只是在寫完上述所有內容后才出現的),您可以定義一個以較低分辨率(例如,每小時一次)運行的記錄規則,並記錄container_memory_usage_bytes
指標的當前值。 然后,您可以繼續在此較低分辨率指標上使用quantile_over_time
。 顯然,您將失去精度(因為您丟棄了大量樣本),並且分位數僅每小時更新一次,但這要簡單得多。 您只需要等待10天,看看結果是否足夠接近。 (o:
quantile_over_time(0.95, container_memory_usage_bytes[10d])
查詢可能會很慢,因為它需要考慮過去 10 天所有container_memory_usage_bytes
時間序列的所有原始樣本。 要處理的樣本數量可能非常大。 可以使用以下查詢進行估算:
sum(count_over_time(container_memory_usage_bytes[10d]))
請注意,如果quantile_over_time(...)
查詢用於在 Grafana 中構建圖形(又名range query
而不是instant query
),則必須乘以從sum(count_over_time(...))
返回的原始樣本數通過 Grafana 圖上的點數,因為 Prometheus 對顯示圖上的每個點單獨執行quantile_over_time(...)
。 通常 Grafana 需要大約 1000 個點來構建平滑圖。 因此,從sum(count_over_time(...))
返回的數字必須乘以 1000,以估計 Prometheus 需要處理以構建quantile_over_time(...)
圖的原始樣本數。 請參閱本文中的更多詳細信息。
減少查詢時長有以下解決方案:
[10d]
更改為[1d]
可將要處理的原始樣本數量減少 10 倍。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.