電子發(fā)燒友App
指標(biāo)是用來(lái)衡量性能、消耗、效率和許多其他軟件屬性隨時(shí)間的變化趨勢(shì)。它們?cè)试S工程師通過(guò)警報(bào)和儀表盤(pán)來(lái)監(jiān)控一系列測(cè)量值的演變（如CPU或內(nèi)存使用量、請(qǐng)求持續(xù)時(shí)間、延遲等）。指標(biāo)在IT監(jiān)控領(lǐng)域有著悠久的歷史，并被工程師廣泛使用，與日志和鏈路追蹤一起被用來(lái)檢測(cè)系統(tǒng)是否有不符合預(yù)期的表現(xiàn)。 在其最基本的形式中，一個(gè)指標(biāo)數(shù)據(jù)點(diǎn)是由以下三個(gè)部分構(gòu)成：
一個(gè)指標(biāo)名稱(chēng)
收集該數(shù)據(jù)點(diǎn)的時(shí)間戳
一個(gè)由數(shù)字表示的測(cè)量值
在過(guò)去的十年里，隨著系統(tǒng)變得越來(lái)越復(fù)雜，出現(xiàn)了維度度量的概念，也就是說(shuō)，度量還包括一組標(biāo)簽或標(biāo)識(shí)（即維度），以提供額外的上下文。支持維度指標(biāo)的監(jiān)控系統(tǒng)允許工程師通過(guò)查詢(xún)特定的指標(biāo)名稱(chēng)，并通過(guò)標(biāo)簽進(jìn)行過(guò)濾和分組，從而輕易地在多個(gè)組件和維度上匯總和分析一個(gè)指標(biāo)。 Prometheus定義了一個(gè)度量說(shuō)明格式和一個(gè)遠(yuǎn)程寫(xiě)入?yún)f(xié)議，社區(qū)和許多供應(yīng)商都采用這個(gè)協(xié)議來(lái)說(shuō)明和收集度量成為事實(shí)上的標(biāo)準(zhǔn)。OpenMetrics是另一個(gè)CNCF項(xiàng)目，它建立在Prometheus導(dǎo)出格式的基礎(chǔ)上，為收集度量標(biāo)準(zhǔn)提供了一個(gè)與廠商無(wú)關(guān)的標(biāo)準(zhǔn)化模型，旨在成為互聯(lián)網(wǎng)工程任務(wù)組（IEFT）的一部分。 最近，另一個(gè)CNCF項(xiàng)目OpenTelemetry出現(xiàn)了，它的目標(biāo)是提供一個(gè)新的標(biāo)準(zhǔn)，能夠統(tǒng)一指標(biāo)、鏈路跟蹤和日志的收集，使跨領(lǐng)域的遙測(cè)信號(hào)收集和關(guān)聯(lián)更容易。 我們希望你在讀完這些文章后，你能理解每個(gè)標(biāo)準(zhǔn)之間的差異，這樣你就能決定哪一個(gè)能更好地滿(mǎn)足你當(dāng)前（和未來(lái)）的需求。
1、Prometheus指標(biāo)
首先要做的事。Prometheus收集的指標(biāo)有四種，作為其暴露格式的一部分。
Counters
Gauges
Histograms
Summaries
Prometheus 使用拉取模型來(lái)收集這些指標(biāo)；也就是說(shuō)，Prometheus 主動(dòng)抓取暴露指標(biāo)的HTTP端點(diǎn)。這些端點(diǎn)可以是由被監(jiān)控的組件自然暴露，也可以通過(guò)社區(qū)建立的數(shù)百個(gè)Prometheus導(dǎo)出器之一暴露出來(lái)。Prometheus提供了不同編程語(yǔ)言的客戶(hù)端庫(kù)，你可以用它來(lái)監(jiān)控你的代碼。 由于服務(wù)發(fā)現(xiàn)機(jī)制和集群內(nèi)的共享網(wǎng)絡(luò)訪問(wèn)，拉取模型在監(jiān)控 Kubernetes 集群時(shí)效果很好，但用 Prometheus 監(jiān)控動(dòng)態(tài)的虛擬機(jī)集群、AWS Fargate 容器或 Lambda函數(shù)就比較困難了。 為什么呢？主要原因是交易確定要抓取的指標(biāo)端點(diǎn)，而且對(duì)這些端點(diǎn)的訪問(wèn)可能受到網(wǎng)絡(luò)安全策略的限制。為了解決其中的一些問(wèn)題，社區(qū)在2021年底發(fā)布了Prometheus Agent Mode，它只收集指標(biāo)并使用遠(yuǎn)程寫(xiě)入?yún)f(xié)議將其發(fā)送到監(jiān)控后端。
Prometheus 可以抓取 Prometheus 暴露格式和 OpenMetrics 格式的指標(biāo)。在這兩種情況下，指標(biāo)通過(guò)HTTP接口暴露，使用簡(jiǎn)單的基于文本的格式（更常用和廣泛支持）或更有效和強(qiáng)大的 Protobuf 格式。文本格式的一大優(yōu)勢(shì)是它的可讀性，這意味著你可以在瀏覽器中打開(kāi)它或使用像curl這樣的工具來(lái)檢索當(dāng)前暴露的指標(biāo)集。 Prometheus 使用一個(gè)非常簡(jiǎn)單的指標(biāo)模型，有四種指標(biāo)類(lèi)型，只在客戶(hù)端SDK中支持。所有的指標(biāo)類(lèi)型都是用一種數(shù)據(jù)類(lèi)型或由多個(gè)單一數(shù)據(jù)類(lèi)型的組合在暴露格式中表示。這個(gè)數(shù)據(jù)類(lèi)型包括一個(gè)指標(biāo)名稱(chēng)、一組標(biāo)簽和一個(gè)浮點(diǎn)數(shù)。時(shí)間戳是由監(jiān)控后端（例如 Prometheus）或代理在抓取指標(biāo)時(shí)添加的。 指標(biāo)名稱(chēng)和標(biāo)簽集的每個(gè)唯一組合定義了一條時(shí)間序列，而每個(gè)時(shí)間戳和浮點(diǎn)數(shù)定義了一個(gè)系列中的樣本（即一個(gè)數(shù)據(jù)點(diǎn)）。 一些慣例被用來(lái)表示不同的度量類(lèi)型。 Prometheus暴露格式的一個(gè)非常有用的特點(diǎn)是能夠?qū)⒃獢?shù)據(jù)與度量相關(guān)聯(lián)，以定義其類(lèi)型并提供描述。例如，Prometheus提供了這些信息，Grafana利用這些信息向用戶(hù)顯示額外的上下文信息，幫助他們選擇正確的度量并應(yīng)用正確的PromQL函數(shù)。
# HELP用來(lái)為指標(biāo)提供描述，# TYPE為指標(biāo)提供類(lèi)型。
現(xiàn)在，讓我們來(lái)更詳細(xì)地介紹一下每個(gè)Prometheus指標(biāo)類(lèi)型。
計(jì)數(shù)器（Counter）
Counter類(lèi)型指標(biāo)被用于單調(diào)增加的測(cè)量結(jié)果。因此它們總是累積的數(shù)值，值只能上升。唯一的例外是 Counter 重啟，在這種情況下，它的值會(huì)被重置為零。 Counter 的實(shí)際值通常本身并不十分有用。一個(gè)計(jì)數(shù)器的值經(jīng)常被用來(lái)計(jì)算兩個(gè)時(shí)間戳之間的 delta 或者隨時(shí)間變化的速率。 例如，Counter 的一個(gè)典型用例是記錄API調(diào)用次數(shù)，這是一個(gè)總是會(huì)增加的測(cè)量值。
# HELP http_requests_total Total number of http api requests
# TYPE http_requests_total counter
http_requests_total{api="add_product"} 4633433
指標(biāo)名稱(chēng)是http_requests_total，它有一個(gè)名為api的標(biāo)簽，值為add_product，Counter 的值為 4633433。
這意味著自從上次服務(wù)啟動(dòng)或Counter重置以來(lái)，add_product的 API 已經(jīng)被調(diào)用了 4633433 次。按照慣例，Counter 類(lèi)型的指標(biāo)通常以_total為后綴。
這個(gè)絕對(duì)數(shù)字并沒(méi)有給我們提供多少信息，但當(dāng)與 PromQL 的 rate 函數(shù)（或其他監(jiān)控后端的類(lèi)似函數(shù)）一起使用時(shí)，它可以幫助我們了解該API每秒收到的請(qǐng)求數(shù)。下面的 PromQL 查詢(xún)計(jì)算了過(guò)去5分鐘內(nèi)每秒的平均請(qǐng)求數(shù)。
rate(http_requests_total{api="add_product"}[5m])
為了計(jì)算一段時(shí)期內(nèi)的絕對(duì)變化，我們將使用 delta 函數(shù)，在 PromQL 中稱(chēng)為increate()：
increase(http_requests_total{api="add_product"}[5m])
這將返回過(guò)去5分鐘內(nèi)的總請(qǐng)求數(shù)，這相當(dāng)于用每秒的速率乘以間隔時(shí)間的秒數(shù)（在我們的例子中是5分鐘）：
rate(http_requests_total{api="add_product"}[5m]) * 5 * 60
其他你可能會(huì)使用 Counter 類(lèi)型指標(biāo)的例子：測(cè)量電子商務(wù)網(wǎng)站的訂單數(shù)量，在網(wǎng)絡(luò)接口上發(fā)送和接收的字節(jié)數(shù)，或者應(yīng)用程序中的錯(cuò)誤數(shù)量。如果它是一個(gè)會(huì)一直上升的指標(biāo)，那么就使用一個(gè)Counter。
下面是一個(gè)例子，說(shuō)明如何使用 Prometheus 客戶(hù)端庫(kù)在 Python 中創(chuàng)建和增加一個(gè)計(jì)數(shù)器指標(biāo)：
from prometheus_client import Counter
api_requests_counter = Counter(
'http_requests_total',
'Total number of http api requests',
['api']
)
api_requests_counter.labels(api='add_product').inc()
需要注意的是，由于Counter可以被重置為零，你要確保你用來(lái)存儲(chǔ)和查詢(xún)指標(biāo)的后端能夠支持這種情況，并且在Counter重啟的情況下仍然提供準(zhǔn)確的結(jié)果。
Prometheus 和兼容 PromQL 的 Prometheus 遠(yuǎn)程存儲(chǔ)系統(tǒng)，如 Promscale，可以正確處理 Counter 重啟。
儀表（Gauge）
Gauge 指標(biāo)用于可以任意增加或減少的測(cè)量。這是你可能更熟悉的指標(biāo)類(lèi)型，因?yàn)榧词箾](méi)有經(jīng)過(guò)額外處理的實(shí)際值也是有意義的，它們經(jīng)常被使用到。例如，測(cè)量溫度、CPU和內(nèi)存使用的指標(biāo)，或者隊(duì)列的大小都是Gauge。
例如，為了測(cè)量一臺(tái)主機(jī)的內(nèi)存使用情況，我們可以使用一個(gè)Gauge指標(biāo)，比如：
# HELP node_memory_used_bytes Total memory used in the node in bytes # TYPE node_memory_used_bytes gauge node_memory_used_bytes{hostname="host1.domain.com"} 943348382上面的指標(biāo)表明，在測(cè)量時(shí)，節(jié)點(diǎn) host1.domain.com 使用的內(nèi)存約為 900 MB。該指標(biāo)的值是有意義的，不需要任何額外的計(jì)算，因?yàn)樗嬖V我們?cè)摴?jié)點(diǎn)上消耗了多少內(nèi)存。 與使用?Counter?指標(biāo)時(shí)不同，rate和delta函數(shù)對(duì)Gauge沒(méi)有意義。然而，計(jì)算特定時(shí)間序列的平均數(shù)、最大值、最小值或百分比的函數(shù)經(jīng)常與 Gauge一起使用。 在 Prometheus 中，這些函數(shù)的名稱(chēng)是avg_over_time、max_over_time、min_over_time和quantile_over_time。要計(jì)算過(guò)去10分鐘內(nèi)在host1.domain.com 上使用的平均內(nèi)存，你可以這樣做：
avg_over_time(node_memory_used_bytes{hostname="host1.domain.com"}[10m])
要使用 Prometheus 客戶(hù)端庫(kù)在 Python 中創(chuàng)建一個(gè) Gauge 指標(biāo)，你可以這樣做：
from prometheus_client import Gauge
memory_used = Gauge(
'node_memory_used_bytes',
'Total memory used in the node in bytes',
['hostname']
)
memory_used.labels(hostname='host1.domain.com').set(943348382)
直方圖（Histogram）
Histogram 指標(biāo)對(duì)于表示測(cè)量的分布很有用。它們經(jīng)常被用來(lái)測(cè)量請(qǐng)求持續(xù)時(shí)間或響應(yīng)大小。 直方圖將整個(gè)測(cè)量范圍劃分為一組區(qū)間，稱(chēng)為桶，并計(jì)算每個(gè)桶中有多少測(cè)量值。 一個(gè)直方圖指標(biāo)包括幾個(gè)項(xiàng)目：
一個(gè)包含測(cè)量次數(shù)的Counter。指標(biāo)名稱(chēng)使用_count后綴。
一個(gè)包含所有測(cè)量值之和的Counter。指標(biāo)名稱(chēng)使用_sum后綴。
直方圖桶被暴露為一系列的Counter，使用指標(biāo)名稱(chēng)的后綴_bucket和表示桶的上限的le label。Prometheus中的桶是包含桶的邊界的，即一個(gè)上限為N的桶（即le label）包括所有數(shù)值小于或等于N的數(shù)據(jù)點(diǎn)。
例如，測(cè)量運(yùn)行在 host1.domain.com 實(shí)例上的 add_productAPI 端點(diǎn)實(shí)例的響應(yīng)時(shí)間的 Histogram 指標(biāo)可以表示為：
# HELP http_request_duration_seconds Api requests response time in seconds
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332
http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892
http_request_duration_seconds_bucket{api="add_product" instance="host1.domain.com" le="0"}
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.01"} 0
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.025"} 8
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.05"} 1672
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.1"} 8954
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.25"} 14251
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.5"} 24101
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="1"} 26351
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="2.5"} 27534
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="5"} 27814
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="10"} 27881
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="25"} 27890
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="+Inf"} 27892
上面的例子包括sum、counter和12個(gè)桶。sum和counter可以用來(lái)計(jì)算一個(gè)測(cè)量值隨時(shí)間變化的平均值。在PromQL中，過(guò)去5分鐘的平均請(qǐng)求響應(yīng)時(shí)間可以通過(guò)如下方式計(jì)算得到。
rate(http_request_duration_seconds_sum{api=”add_product”, instance=”host1.domain.com”}[5m]) / rate(http_request_duration_seconds_count{api=”add_product”, instance=”host1.domain.com”}[5m])
它也可以被用來(lái)計(jì)算各時(shí)間序列的平均數(shù)。下面的 PromQL 查詢(xún)將計(jì)算出所有API和實(shí)例在過(guò)去5分鐘內(nèi)的平均請(qǐng)求響應(yīng)時(shí)間。
sum(rate(http_request_duration_seconds_sum[5m])) / sum(rate(http_request_duration_seconds_count[5m]))
利用 Histogram，你可以在查詢(xún)時(shí)計(jì)算單個(gè)時(shí)間序列以及多個(gè)時(shí)間序列的百分位。在PromQL中，我們將使用histogram_quantile函數(shù)。Prometheus使用分位數(shù)而不是百分位數(shù)。
它們本質(zhì)上是一樣的，但是以0到1的比例表示的，而百分位數(shù)是以0到100的比例表示的。要計(jì)算在host1.domain.com上運(yùn)行的add_product API響應(yīng)時(shí)間的第99百分位數(shù)（0.99四分位數(shù)），你可以使用以下查詢(xún)。
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{api=”add_product”, instance=”host1.domain.com”}[5m]))
Histograms 的一大優(yōu)勢(shì)是可以進(jìn)行匯總。下面的查詢(xún)返回所有API和實(shí)例的響應(yīng)時(shí)間的第99個(gè)百分點(diǎn)?：
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
在云原生環(huán)境中，通常有許多相同組件的多個(gè)實(shí)例在運(yùn)行，能否跨實(shí)例匯總數(shù)據(jù)是關(guān)鍵。 Histograms有三個(gè)主要的缺點(diǎn)：首先，桶必須是預(yù)定義的，這需要一些前期的設(shè)計(jì)。如果你的桶沒(méi)有被很好地定義，你可能無(wú)法計(jì)算出你需要的百分比，或者會(huì)消耗不必要的資源。例如，如果你有一個(gè)總是需要超過(guò)一秒鐘的API，那么擁有上限（le label）小于一秒鐘的桶將是無(wú)用的，只會(huì)消耗監(jiān)控后端服務(wù)器的計(jì)算和存儲(chǔ)資源。另一方面，如果99.9%的API請(qǐng)求耗時(shí)少于50毫秒，那么擁有一個(gè)上限為100毫秒的初始桶將無(wú)法讓你準(zhǔn)確測(cè)量API的性能。
第二，他們提供的是近似的百分位數(shù)，而不是精確的百分位數(shù)。這通常沒(méi)什么問(wèn)題，只要你的桶被設(shè)計(jì)為提供具有合理準(zhǔn)確性的結(jié)果。
第三，由于百分位數(shù)需要在服務(wù)器端計(jì)算，當(dāng)有大量數(shù)據(jù)需要處理時(shí)，它們的計(jì)算成本會(huì)非常高。在Prometheus中減輕這種情況的一個(gè)方法是使用錄制規(guī)則來(lái)預(yù)先計(jì)算所需的百分位數(shù)。
下面的例子顯示了如何使用 Prometheus 的 Python 客戶(hù)端庫(kù)創(chuàng)建一個(gè)帶有自定義桶的直方圖指標(biāo)。
from prometheus_client import Histogram
api_request_duration = Histogram(
name='http_request_duration_seconds',
documentation='Api requests response time in seconds',
labelnames=['api', 'instance'],
buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10, 25 )
)
api_request_duration.labels(
api='add_product',
instance='host1.domain.com'
).observe(0.3672)
匯總（Summary）
像直方圖一樣，Summary指標(biāo)對(duì)于測(cè)量請(qǐng)求持續(xù)時(shí)間和響應(yīng)體大小很有用。
像直方圖一樣，匯總度量對(duì)于測(cè)量請(qǐng)求持續(xù)時(shí)間和響應(yīng)大小很有用。
一個(gè)Summary指標(biāo)包括這些指標(biāo)：
一個(gè)包含總測(cè)量次數(shù)的Counter。指標(biāo)名稱(chēng)使用_count后綴。
一個(gè)包含所有測(cè)量值之和的Counter。指標(biāo)名稱(chēng)使用_sum后綴。可以選擇使用帶有分位數(shù)標(biāo)簽的指標(biāo)名稱(chēng)，來(lái)暴露一些測(cè)量值的分位數(shù)指標(biāo)。由于你不希望這些量值是從應(yīng)用程序運(yùn)行的整個(gè)時(shí)間內(nèi)測(cè)得的，Prometheus客戶(hù)端庫(kù)通常會(huì)使用流式的分位值，這些分位值是在一個(gè)滑動(dòng)的（通常是可配置的）時(shí)間窗口上計(jì)算得到的。
例如，測(cè)量在 host1.domain.com 上運(yùn)行的 add_productAPI 端點(diǎn)實(shí)例的響應(yīng)時(shí)間的 Summary 指標(biāo)可以表示為：
# HELP http_request_duration_seconds Api requests response time in seconds
# TYPE http_request_duration_seconds summary
http_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332
http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0"}
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.5"} 0.232227334
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.90"} 0.821139321
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.95"} 1.528948804
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.99"} 2.829188272
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="1"} 34.283829292
上面這個(gè)例子包括總和和計(jì)數(shù)以及五個(gè)分位數(shù)。分位數(shù)0相當(dāng)于最小值，分位數(shù)1相當(dāng)于最大值。分位數(shù)0.5是中位數(shù)，分位數(shù)0.90、0.95和0.99相當(dāng)于在host1.domain.com上運(yùn)行的add_product API端點(diǎn)響應(yīng)時(shí)間的第90、95和99個(gè)百分位。 像直方圖一樣，Summary指標(biāo)包括總和和計(jì)數(shù)，可用于計(jì)算隨時(shí)間的平均值以及不同時(shí)間序列的平均值。 Summary提供了比Histogram更精確的百分位計(jì)算結(jié)果，但這些百分位有三個(gè)主要缺點(diǎn)
首先，客戶(hù)端計(jì)算百分位是很昂貴的。這是因?yàn)榭蛻?hù)端庫(kù)必須保持一個(gè)有序的數(shù)據(jù)點(diǎn)列表，以進(jìn)行這種計(jì)算。在Prometheus SDK中的實(shí)現(xiàn)限制了內(nèi)存中保留和排序的數(shù)據(jù)點(diǎn)的數(shù)量，這降低了準(zhǔn)確性以換取效率的提高。注意，并非所有的Prometheus客戶(hù)端庫(kù)都支持匯總指標(biāo)中的量值。例如，Python SDK就不支持。
第二，你要查詢(xún)的量值必須由客戶(hù)端預(yù)先定義。只有那些已經(jīng)提供了指標(biāo)的量值才能通過(guò)查詢(xún)返回。沒(méi)有辦法在查詢(xún)時(shí)計(jì)算其他百分位。增加一個(gè)新的百分位指標(biāo)需要修改代碼，該指標(biāo)才可以被使用。
第三，也是最重要的一點(diǎn)，不可能把多個(gè)Summary指標(biāo)進(jìn)行聚合計(jì)算。這使得它們對(duì)動(dòng)態(tài)現(xiàn)代系統(tǒng)中的大多數(shù)用例毫無(wú)用處，在這些用例中，通常我們對(duì)一個(gè)特定的組件感興趣，這個(gè)視角是全局的，它不與特定的實(shí)例關(guān)聯(lián)。
因此，想象一下，在我們的例子中，add_product 的 API 端點(diǎn)運(yùn)行在10個(gè)主機(jī)上，在這些服務(wù)之前有一個(gè)負(fù)載均衡器。我們沒(méi)有任何聚合函數(shù)可以用來(lái)計(jì)算add_product API 接口在所有請(qǐng)求中響應(yīng)時(shí)間的第99百分位數(shù)，無(wú)論這些請(qǐng)求被發(fā)送到哪個(gè)后端實(shí)例上。我們只能看到每個(gè)主機(jī)的第99個(gè)百分點(diǎn)。 同樣地，我們也只能知道某個(gè)接口，比如 add_productAPI 端點(diǎn)的（在某個(gè)實(shí)例上的）第99百分位數(shù)，而不能對(duì)不同的接口進(jìn)行聚合。
下面的代碼使用 Prometheus 的 Python 客戶(hù)端庫(kù)創(chuàng)建了一個(gè) Summary 指標(biāo)。
from prometheus_client import Summary
api_request_duration = Summary(
'http_request_duration_seconds',
'Api requests response time in seconds',
['api', 'instance']
)
api_request_duration.labels(api='add_product', instance='host1.domain.com').observe(0.3672)
上面的代碼沒(méi)有定義任何量化指標(biāo)，只會(huì)產(chǎn)生總和和計(jì)數(shù)指標(biāo)。Prometheus 的Python SDK 不支持 Summary 指標(biāo)中的分位數(shù)計(jì)算。
Histogram還是Summary？ 在大多數(shù)情況下，直方圖是首選，因?yàn)樗`活，并允許匯總百分位數(shù)。 在不需要百分位數(shù)而只需要平均數(shù)的情況下，或者在需要非常精確的百分位數(shù)的情況下，匯總是有用的。例如，在履行關(guān)鍵系統(tǒng)的合約責(zé)任的情況下。 下表總結(jié)了直方圖和匯總表的優(yōu)點(diǎn)和缺點(diǎn)。
編輯：黃飛
?
工商網(wǎng)監(jiān)
評(píng)論