直方圖和摘要
直方圖和摘要是更復雜的指標型別。出於歷史原因，直方圖存在兩種變體：經典直方圖和原生直方圖，後者甚至還有多種子變體。本文件旨在幫助您理解所有這些指標型別之間的差異、如何正確使用它們，以及如何為您的用例選擇正確的指標型別。
本文件中最重要的一課很簡單：如果可以，請使用原生直方圖，並優先於經典直方圖和摘要。
當您發現無法簡單使用原生直方圖時，事情就會變得複雜。最常見的情況是，您可能需要處理包含經典直方圖或摘要的現有指標，或者您使用的埋點庫尚未支援原生直方圖。此外，在少數特定用例中，您可能更喜歡摘要或經典直方圖。
透過本文件，您應該能夠應對相關的障礙和細微之處。
概述
從歷史上看，Prometheus 世界中的樣本只是一個帶時間戳的浮點值。這個值可以被解釋為計數器或儀表，也就是說，大多數時候 Prometheus 不維護“靜態型別”的概念，您只需要知道您正在處理哪種指標（透過計數器名稱應以 _total 結尾的約定來輔助）。
但是除了計數器和儀表之外，還有更多的指標型別。特別是，需要表示觀測值（在 Prometheus 術語中通常簡稱為“觀測”）的分佈。主要有兩種不同的方法：
- 被埋點程式在預配置的時間視窗（例如，最近十分鐘）內計算一系列預配置的分位數（例如，中位數或第 90 百分位數），並將其作為附加指標暴露出來。Prometheus 以一種名為 summary（摘要）的指標型別實現了這種方法。根據所使用的演算法，預計算的分位數通常非常準確。但這種計算對被埋點程式有資源開銷。此外，如果您需要另一個時間視窗或另一個百分位數，您無法在以後“重新計算”分位數，最重要的是，您無法聚合分位數（例如，計算由多個複製工作節點支援的服務的總第 90 百分位數延遲）。
- 被埋點程式以一種更基本的方式表示分佈，這種方式以後可用於計算任意時間視窗上的任意分位數。最重要的是，這種分佈的表示方式可以相互聚合。這種表示形式有時稱為 digest（摘要）。Prometheus 以一種名為 histogram（直方圖）的指標型別實現了這種方法，其中觀測值被計數到桶中，就像您從直方圖 的一般概念中瞭解到的那樣。
在這兩種方法中，Prometheus 還會收集觀測值的計數和總和（詳見下文）。
兩種方法共同的需求是每個樣本收集大量的數值，而不僅僅是像以前那樣一個浮點值。
- 在任何情況下，都是觀測值的計數和總和。
- 對於摘要，是預計算的分位數。
- 對於直方圖，是一組包含其填充計數和邊界的桶。
這些新型指標也稱為 複合型別。
在最初的方法中，Prometheus 保留了其簡單的時間戳浮點值資料模型，並將這些大量的數值對映到各自的時間序列中，透過特定的標籤進行區分。透過這種方式，建立了摘要和經典直方圖。在這兩種型別中，觀測值的計數和總和都分別在獨立的時間序列中跟蹤。類似地，摘要的每個預計算分位數和直方圖的每個桶都在其自己的時間序列中跟蹤。PromQL 運算子和函式作用於這些獨立的時間序列，具體細節將在下文詳細解釋。
一方面，這種方法執行良好。它在保持資料模型簡單的同時，滿足了許多用例。另一方面，它也存在許多限制，尤其是在直方圖方面。因此，在 Prometheus 存在很久之後，引入了原生直方圖。原生直方圖樣本是“值的組合”，其中單個樣本包含觀測值的計數和總和，以及動態數量的帶有其填充計數和邊界的桶。在 Prometheus TSDB 中，一個直方圖會產生一個原生直方圖樣本的時間序列，而不是一堆獨立的時間序列。PromQL 運算子和函式現在必須作用於這些複合樣本，而不是之前獨立的浮點時間序列。
您可以在原生直方圖的規範中閱讀所有相關內容，但請注意這是一份非常技術性和詳細的文件。如果您繼續在此處閱讀，您可以期待更易於理解且側重於使用的解釋。
如果您對 Prometheus 走向複合型別原生表示的歷程感興趣，可以在部落格文章中瞭解更多資訊。
埋點庫支援
摘要通常受到所有庫的支援，但有些庫可能只跟蹤觀測值的計數和總和，而忽略分位數計算。（無分位數的摘要仍然是摘要的合法用途，詳見下文。）
經典直方圖的支援也廣泛存在，但原生直方圖的支援仍然很少。目前，後者需要透過 protobuf 格式進行暴露，將支援限制在支援 protobuf 的庫，例如 Java 和 Go 庫。基於文字格式的支援正在作為 OpenMetrics v2 的一部分進行中。事情應該很快會有進展，所以請務必檢查您的庫提供了什麼。
即使您的埋點程式只暴露經典直方圖，您仍然可以配置 Prometheus 將它們作為原生直方圖攝入。這將以 具有自定義桶邊界的原生直方圖（NHCB）的形式發生。與常見的原生直方圖（其特點是所謂的標準指數桶）相比，這些 NHCB 存在一些限制，但它們的儲存效率仍遠高於純經典直方圖。NHCB 在 PromQL 中的處理方式與其他原生直方圖相同，因此以後遷移到“真正”的原生直方圖將很容易。
透過 Open Telemetry 攝入
也許您甚至沒有使用 Prometheus 埋點庫，但您的指標來自遵循 Open Telemetry (OTel) 標準的收集器。當將 OTel 指標攝入到 Prometheus 相容的後端時，“普通”的 OTel 直方圖可以在 Prometheus 端轉換為經典直方圖或 NHCB（提示：優先選擇後者），而 OTel 的 指數直方圖 總是轉換為常見的原生直方圖（帶有標準指數桶）。
觀測值的計數和總和
直方圖和摘要都記錄觀測值，通常是請求持續時間或響應大小。在所有變體中（即使是無分位數的摘要），它們都跟蹤觀測值的數量 和 觀測值的總和，使您能夠計算觀測值的 平均值。
為此，您通常首先計算所需持續時間內的 rate，然後將“總和的 rate”除以“計數的 rate”。
對於原生直方圖（包括 NHCB），您分別使用 histogram_sum 和 histogram_count 函式提取觀測值的總和和計數。例如，要從名為 http_request_duration_seconds 的原生直方圖計算過去 5 分鐘的平均請求持續時間，請使用以下 PromQL 表示式：
histogram_sum(rate(http_request_duration_seconds[5m]))
/
histogram_count(rate(http_request_duration_seconds[5m]))
對於平均值的計算，還有一個使用 histogram_avg 函式的更短版本。以下表達式與上面等效：
histogram_avg(rate(http_request_duration_seconds[5m]))
對於摘要或經典直方圖，您有單獨的時間序列用於觀測值的總和和計數，分別用魔法字尾 _sum 和 _count 標記。因此，一個名為 http_request_duration_seconds 的摘要或經典直方圖將產生序列 http_request_duration_seconds_sum 和 http_request_duration_seconds_count，計算過去 5 分鐘平均請求持續時間的表示式將如下所示：
rate(http_request_duration_seconds_sum[5m])
/
rate(http_request_duration_seconds_count[5m])
上述兩個表示式中的分母本身也很有用。它表示過去 5 分鐘內每秒處理的請求數。另一種說法是，http_request_duration_seconds_count 序列的行為與 HTTP 請求的計數器完全相同（如果您沒有直方圖或摘要來替換它，您會稱之為 http_requests_total）。Prometheus 中計數器的關鍵特性是它總是遞增，除非發生計數器重置。
如果您的觀測值從不為負，則 http_request_duration_seconds_sum 序列也總是遞增（除非發生計數器重置）。然而，如果混入了負觀測值，觀測值的總和也可能下降，從而打破 PromQL 所做的假設。這種下降在上述 rate(http_request_duration_seconds_sum[5m]) 計算中會被錯誤地視為計數器重置，從而導致結果失真。請注意，這個問題隻影響摘要和經典直方圖。原生直方圖（包括 NHCB）是作為一個整體進行 rate 計算的，因此能正確檢測計數器重置。在少數情況下，如果您無法避免負觀測值且只能使用摘要或經典直方圖，您可以使用兩個單獨的摘要或直方圖，一個用於正觀測值，一個用於負觀測值（後者帶反轉符號），然後使用適當的 PromQL 表示式在以後合併結果。
觀測值的總和和計數都是可加的，因此您可以輕鬆聚合——在 rate 之後，但在除法之前，並且無論底層指標型別是什麼。以下是計算每個 job 平均請求持續時間的表示式：
原生直方圖
sum by (job) (histogram_sum(rate(http_request_duration_seconds[5m])))
/
sum by (job) (histogram_count(rate(http_request_duration_seconds[5m])))
摘要或經典直方圖
sum by (job) (rate(http_request_duration_seconds_sum[5m]))
/
sum by (job) (rate(http_request_duration_seconds_count[5m]))
分桶
直方圖本質上是分桶計數器，因此將直方圖與摘要區分開來的最明顯用例是計算落在特定觀測值桶中的觀測值。
如果您使用經典直方圖埋點程式碼，您將配置固定的桶邊界。如果您讓 Prometheus 以經典方式攝入這些經典直方圖，那麼以這種方式配置的每個桶都會建立一個以 _bucket 為字尾的序列，無論該桶是否被填充。更多的桶在各種查詢中為您提供更多選項和準確性（詳見下文），但“每個桶一個序列”的成本相當高。
如果您將經典直方圖作為 NHCB 攝入，未填充的桶成本可忽略不計，即使是已填充的桶也以更高效的方式處理，因為每個 NHCB 都由單個複合樣本序列表示（而不是每個桶、觀測值的總和和計數都由單獨的浮點序列表示）。
然而，提前選擇合適的桶可能具有挑戰性。並且以後更改桶會造成很大的干擾（您將在下文看到）。如果您直接使用原生直方圖埋點程式碼，您不需要明確選擇任何桶邊界，而是配置一個期望的解析度。桶是根據指數分桶模式動態建立的，涵蓋從 -Inf 到 +Inf 的整個浮點數範圍。更高的解析度會導致更高的資源使用，但通常您可以在相同的資源成本下達到比經典直方圖高得多的解析度。埋點庫還提供各種策略來限制填充桶的數量，例如定期重置直方圖或自適應解析度降低。有關詳細資訊，請參閱您正在使用的埋點庫的文件。
要根據原生直方圖查詢落在某個範圍內的觀測值的分數，請使用如下表達式：
histogram_fraction(0, 0.3, sum by (job) (rate(http_request_duration_seconds[5m])))
這計算了每個 job 在過去 5 分鐘內持續時間在 0ms 到 300ms 之間的 HTTP 請求的比例。（這裡 300ms 表示為 0.3 秒，因為在 Prometheus 中您應始終使用基本單位。）請注意 sum 如何透過對所涉及直方圖中相應的桶求和來進行正確聚合。如果直方圖具有不同的桶佈局，它們會首先進行協調。對於通常的指數分桶模式，這可以平穩工作，本質上是回退到所有相關直方圖中的最低共同解析度。在時間上（在 rate 計算中使用的 5 分鐘範圍內）協調不同的桶佈局也是如此。對於 NHCB，其效果在很大程度上取決於不同桶佈局的細節。很可能協調後的聚合直方圖只剩下一個桶，包含所有觀測值。由於可能產生的嚴重影響，如果 NHCB 需要協調，查詢結果會獲得一個資訊級別的註解。這也是具有動態指數桶的原生直方圖更容易處理的原因之一。
如果恰好在 0.3 處有一個桶邊界，則計算出的分數是準確的。在沒有桶邊界的常見情況下，使用插值法返回一個估計的分數。這種估計在更高的桶解析度下會更準確。如果您提前知道，例如，您的 SLO 是在 300ms 內處理 95% 的請求，您可以使用經典直方圖的固定桶邊界來進行準確計算。然而，如果您的 SLO 以後發生變化，相應地更改固定桶佈局將非常繁瑣。（您必須更改程式碼的埋點。並且您將遇到如上所述協調不同桶佈局的問題。）如果您選擇具有動態指數桶的原生直方圖，您將不會在 0.3 處獲得精確的桶邊界，但憑藉適當的解析度，插值估計仍然會相當準確。作為回報，您可以自由更改範圍邊界，這不僅在您的 SLO 發生變化時有所幫助，而且還可以探索諸如“我們能否根據上一季度的資料維持更嚴格的 SLO？”之類的問題。
在也作為經典直方圖攝入的純經典直方圖的傳統情況中，相應的 PromQL 表示式看起來大相徑庭：
sum by (job) (rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
/
sum by (job) (rate(http_request_duration_seconds_count[5m]))
le 標籤名代表“小於或等於”。此標籤的值是累積桶的上限（即，此桶包含所有小於或等於 0.3 的觀測值——包括負觀測值，我們假設在觀測請求持續時間的情況下不會發生這種情況）。
請注意，此表示式嚴格要求在 0.3 處配置一個桶邊界。如果所涉及的直方圖沒有該邊界的桶，則不應用插值。相反，根本不返回任何估計結果。如果只有部分涉及的直方圖具有這樣的桶，則返回不完整的結果，但沒有任何警告，這是一種非常糟糕的情況。（提示：避免這種“純經典”情況。如果可以，請將經典直方圖作為 NHCB 攝入。或者首先使用原生直方圖進行埋點。）
Apdex 分數
當您閱讀關於在特定持續時間範圍內處理的請求比例時，您可能會想起Apdex 分數 。對於這個分數，您設定一個目標請求持續時間和可容忍請求持續時間（通常是目標請求持續時間的 4 倍）。假設您的目標請求持續時間是 300ms，可容忍請求持續時間是 1.2s。如果您想計算過去 5 分鐘內每個 job 的 Apdex 分數，原生直方圖（包括 NHCB）的 PromQL 表示式是直截了當的。只需將持續時間目標內的請求比例加上目標持續時間與可容忍持續時間之間請求比例的一半：
histogram_fraction(0, 0.3, sum by (job) (rate(http_request_duration_seconds[5m])))
+
histogram_fraction(0.3, 1.2, sum by (job) (rate(http_request_duration_seconds[5m]))) / 2
在“純經典”情況下，您必須在精確邊界處存在桶（作為回報，它會給您提供準確的計算）。相應的 PromQL 表示式看起來大相徑庭，因為經典桶是累積的：
(
sum by (job) (rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
+
sum by (job) (rate(http_request_duration_seconds_bucket{le="1.2"}[5m]))
)
/
2
/
sum by (job) (rate(http_request_duration_seconds_count[5m]))
（為簡單起見，上述表示式沒有明確將失敗請求從計算的滿意和可容忍部分中排除，而嚴格正確的 Apdex 計算則需要這樣做。）
分位數
您可以使用摘要和直方圖來計算所謂的 φ-分位數，其中 0 ≤ φ ≤ 1。φ-分位數是在 N 個觀測值中排名第 φ*N 的觀測值。φ-分位數示例：0.5-分位數稱為中位數。0.95-分位數也稱為第 95 百分位數。
摘要和直方圖之間的本質區別在於，摘要在埋點程式內計算流式 φ-分位數並直接暴露它們，而直方圖暴露分桶的觀測值計數，並且從直方圖的桶中計算分位數是在 Prometheus 伺服器上使用 histogram_quantile() 函式進行的。直方圖又分為原生直方圖和經典直方圖。下表列出了不同方法的一些影響。
| 原生直方圖 | 經典直方圖 | 摘要 | |
|---|---|---|---|
| 埋點期間所需配置 | 選擇所需的解析度，並可能選擇限制桶數量的策略。 | 選擇適合觀測值預期範圍和所需查詢的桶。 | 選擇所需的 φ-分位數和滑動視窗。其他 φ-分位數和滑動視窗無法在以後計算。 |
| 埋點成本 | 觀測值很便宜，因為它們只需要增加計數器。 | 觀測值很便宜，因為它們只需要增加計數器。 | 由於流式分位數計算，觀測值相對昂貴。 |
| 查詢效能 | 伺服器必須從複雜的直方圖樣本中計算分位數。如果即席計算耗時過長（例如在大型儀表盤中），您可以使用記錄規則。 | 伺服器必須從大量的桶序列中計算分位數。如果即席計算耗時過長（例如在大型儀表盤中），您可以使用記錄規則。 | 快速（伺服器上沒有分位數計算，並且聚合無論如何都不可能，詳見下文）。 |
| 每個直方圖/摘要的時間序列數量 | 一個（帶有複合樣本型別）。 | _sum、_count，以及每個配置的桶一個。 | _sum、_count，以及每個配置的分位數一個。 |
| 分位數誤差（詳見下文） | 受限於配置的解析度。 | 誤差受限於分位數所在桶的寬度。 | 可配置，通常非常低。 |
| φ-分位數和滑動時間視窗的規範 | 使用PromQL 表示式即席查詢。 | 使用PromQL 表示式即席查詢。 | 在埋點期間預配置。 |
| 聚合 | 使用PromQL 表示式即席查詢，桶始終相容。 | 使用PromQL 表示式即席查詢，前提是桶邊界沒有變化。 | 不可聚合 . |
如上所述，經典直方圖可以被 Prometheus 伺服器攝入為一種特殊形式的原生直方圖，稱為 NHCB（具有自定義桶邊界的原生直方圖）。因此，它們與經典直方圖和普通原生直方圖共享一些特性。在埋點方面，它們的行為與經典直方圖完全相同。（事實上，它們與經典直方圖是相同的，因為 NHCB 僅在伺服器端將經典直方圖作為 NHCB 攝入時建立。）查詢效能和時間序列數量與普通原生直方圖相同，但分位數誤差與相應的經典直方圖相同。NHCB 在處理桶佈局更改方面比經典直方圖更優雅一些，但這仍然是一個問題（至少會透過註解標記出來）。
請注意表格中最後一項的重要性。讓我們回到在 300 毫秒內處理 95% 請求的 SLO。這次，您不想顯示在 300 毫秒內處理的請求百分比，而是第 95 百分位數，即您處理 95% 請求的請求持續時間。要做到這一點，您可以配置一個帶有 0.95 分位數和（例如）5 分鐘衰減時間的摘要，或者配置一個具有適當解析度的原生直方圖（例如，使用 Go 埋點庫，您可以將 NativeHistogramBucketFactor 的值設定為 1.1），或者配置一個圍繞 300 毫秒標記的經典直方圖，例如 {le="0.1"}、{le="0.2"}、{le="0.3"} 和 {le="0.45"}。如果您的服務以多個例項進行復制執行，您將從每個例項收集請求持續時間，然後您希望將所有內容聚合到整體的第 95 百分位數中。然而，聚合摘要中預計算的分位數很少有意義。在這種特定情況下，對分位數求平均值會產生統計學上無意義的值。
avg(http_request_duration_seconds{quantile="0.95"}) // BAD!
使用直方圖，聚合完全可以透過 histogram_quantile() 函式實現。
原生直方圖版本（包括 NHCB）
histogram_quantile(0.95, sum(rate(http_request_duration_seconds[5m]))) // GOOD.
經典直方圖版本
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))) // GOOD.
此外，如果您的 SLO 發生變化，您現在想繪製第 90 百分位數，或者您想考慮最近 10 分鐘而不是最近 5 分鐘的資料，您只需調整上述表示式，而無需重新配置被監控程式的埋點。
分位數估計誤差
分位數，無論是透過埋點二進位制檔案還是在 Prometheus 伺服器上計算，都是估計值。理解這種估計的誤差非常重要。
繼續上面的直方圖示例，想象一下您通常的請求持續時間幾乎都非常接近 220ms，換句話說，在一個高解析度的直方圖中，您會看到 220ms 處有一個非常尖銳的峰值，而“真實”的第 95 百分位數也接近 220ms。
使用 NativeHistogramBucketFactor 為 1.1（遵循 Go 埋點示例），這個峰值將落入的桶的下限大約為 0.210，上限大約為 0.229。（本文件特意避免解釋這些邊界是如何計算的詳細資訊。有關詳細資訊，請參閱前面提到的規範。）為簡單起見，我們假設所有請求都落入這個桶中。那麼 histogram_quantile 的插值邏輯將估計第 95 百分位數為 228ms（這裡再次省略計算細節）。然而，根據上述桶邊界，真實值可能在 210ms 和 229ms 之間的任何地方，具體取決於桶內請求的實際分佈。因此，這是一個相當準確的估計，即使在最壞情況下也是如此（真實值可能是 210ms 而不是 220ms，而估計值為 228ms）。
現在，讓我們將相同的邏輯應用於如上所述配置的經典直方圖。所有觀測值，以及第 95 百分位數，都將落入標記為 {le="0.3"} 的桶中，即從 200ms 到 300ms 的桶。在這種情況下，插值將估計為 295ms，並保證真實值介於 200ms 和 300ms 之間。不僅誤差範圍大得多，而且 295ms 的估計值與 220ms 的真實值相去甚遠，而在原生直方圖的情況下，估計值為 228ms。鑑於第 95 百分位數的 SLO 為 300ms，經典直方圖給您一種您非常接近突破它的印象，但實際上您做得仍然相當不錯。
我們思想實驗的下一步：後端路由的更改為所有請求持續時間增加了固定的 100ms。現在請求持續時間在 320ms 處有一個尖銳的峰值。
原生直方圖的相關桶範圍從 297ms 到 324ms（這裡再次只是給出數字，沒有說明它們是如何計算的），插值估計的第 95 百分位數為 323ms。這是一個近乎完美的猜測。
然而，經典直方圖將看到幾乎所有觀測值都落在 300ms 到 450ms 的桶中。第 95 百分位數估計為 443ms，與接近 320ms 的正確值相去甚遠。雖然您只略微超出了 SLO，但估計的第 95 分位數看起來糟糕得多。
摘要在這兩種情況下都能非常準確地計算出正確的百分位數，至少如果它使用合適的演算法（例如 Go 埋點庫使用的演算法 ——此演算法對於我們示例中的窄分佈會產生非常準確的結果）。不幸的是，如果您需要聚合來自多個例項的觀測值，則無法使用摘要。
幸運的是，由於您為經典直方圖選擇了適當的桶邊界，在這個觀測值分佈出現非常尖銳峰值的人為示例中，經典直方圖能夠正確識別您是否在 SLO 範圍內或之外（儘管它在告知您距離突破或維持 SLO 還有多遠方面表現不佳）。然而，分位數的實際值越接近 SLO（換句話說，您最感興趣的值），計算出的值就越準確。
現在讓我們再次修改實驗。在新設定中，請求持續時間的分佈在 150ms 處有一個峰值，但它不像以前那麼尖銳，並且只包含 90% 的觀測值。10% 的觀測值均勻分佈在 150ms 到 450ms 之間的長尾中。在這種分佈下，第 95 百分位數恰好在我們的 SLO 300ms 處。使用經典直方圖，在這種（人為設計的）情況下，計算出的值將是準確的，因為第 95 百分位數的值恰好與一個配置的桶邊界重合。即使是略微不同的值仍然是準確的，因為相關桶內的均勻分佈正是經典直方圖插值演算法所假設的。
摘要報告的分位數誤差在這裡變得更有趣。在 Go 埋點庫的情況下，摘要中分位數的誤差是在 φ 維度中配置的。在我們的例子中，我們可能配置了 0.95±0.01，即計算值將在第 94 到第 96 百分位數之間。上述分佈的第 94 分位數為 270ms，第 96 分位數為 330ms。摘要報告的第 95 百分位數計算值可以在 270ms 到 330ms 之間的任何位置，不幸的是，這正是明確在 SLO 內與明確在 SLO 之外的所有區別。
結論是：如果您使用摘要，您可以控制 φ 維度中的誤差。如果您使用直方圖，您可以透過選擇經典直方圖的適當桶佈局（困難）或選擇原生直方圖的桶解析度（容易）來控制觀測值維度中的誤差。對於寬分佈，φ 的微小變化會導致觀測值的巨大偏差。對於尖銳分佈，觀測值的小區間覆蓋了 φ 的大區間。
經驗法則是：
- 如果您可以使用原生直方圖，請使用與您的精度要求相匹配的解析度。這結合了所需的精度和透過 PromQL 表示式即時聚合和更改引數（百分位數、滑動視窗）的能力。
- 如果您不能使用原生直方圖，但需要聚合，則必須使用經典直方圖，這需要您設定適當的桶邊界，覆蓋正確的數值範圍，並在桶的成本和所需的準確性之間找到正確的平衡。
- 只有當不需要聚合時，您才能開始考慮摘要。主要優點是它以相對較低的總體成本提供非常準確的分位數估計（在 φ 維度中）。然而，在埋點時選擇所需分位數和滑動視窗的額外要求是摘要的另一個嚴重缺點。
視覺化
雖然摘要的預計算分位數可以像任何其他浮點時間序列一樣視覺化，但視覺化直方圖更為複雜。Prometheus UI 在 Table 檢視中顯示單個直方圖樣本的圖形表示。然而，在 Graph 檢視中，它只繪製經典直方圖的每個元件序列，或者——在原生直方圖的情況下——只繪製觀測值的總和。
直方圖隨時間變化的非常有用的視覺化是熱力圖。Prometheus UI 尚不支援熱力圖（參見跟蹤問題 ）。然而，流行的儀表盤工具如Perses 或Grafana 能夠基於 Prometheus 直方圖渲染熱力圖。經典直方圖的解析度通常不足以建立引人注目的熱力圖，但原生直方圖可實現的更高解析度能夠建立非常詳細的熱力圖。