深入淺出 Prometheus

背景

對很多人來說,未知、不確定、不在掌控的東西,會有潛意識的逃避。當我第一次接觸 Prometheus 的時候也有類似的感覺。對初學者來說, Prometheus 包含的概念太多了,門檻也太高了。

概念:Instance、Job、Metric、Metric Name、Metric Label、Metric Value、Metric Type(Counter、Gauge、Histogram、Summary)、DataType(Instant Vector、Range Vector、Scalar、String)、Operator、Function

馬雲說:“雖然阿里巴巴是全球最大的零售平臺,但阿里不是零售公司,是一家數據公司”。Prometheus 也是一樣,本質來說是一個基於數據的監控系統。

日常監控

假設需要監控 WebServerA 每個 API 的請求量爲例,需要監控的維度包括:服務名(job)、實例 IP(instance)、API 名(handler)、方法(method)、返回碼 (code)、請求量(value)。

如果以 SQL 爲例,演示常見的查詢操作:

查詢 method=put 且 code=200 的請求量(紅框):

SELECT * from http_requests_total WHERE code=”200” AND method=”put” AND created_at BETWEEN 1495435700 AND 1495435710;

查詢 handler=prometheus 且 method=post 的請求量(綠框):

SELECT * from http_requests_total WHERE handler=”prometheus” AND method=”post” AND created_at BETWEEN 1495435700 AND 1495435710;

查詢 instance=10.59.8.110 且 handler 以 query 開頭 的請求量(綠框):

SELECT * from http_requests_total WHERE handler=”query” AND instance=”10.59.8.110” AND created_at BETWEEN 1495435700 AND 1495435710;

通過以上示例可以看出,在常用查詢和統計方面,日常監控多用於根據監控的維度進行查詢與時間進行組合查詢。如果監控 100 個服務,平均每個服務部署 10 個實例,每個服務有 20 個 API,4 個方法,30 秒收集一次數據,保留 60 天。那麼總數據條數爲:100(服務)* 10(實例)* 20(API)* 4(方法)* 86400(1 天秒數)* 60(天)/ 30(秒)= 138.24 億條數據,寫入、存儲、查詢如此量級的數據是不可能在 MySQL 類的關係數據庫上完成的。因此 Prometheus 使用 TSDB 作爲存儲引擎。

存儲引擎

TSDB 作爲 Prometheus 的存儲引擎完美契合了監控數據的應用場景。

那麼 TSDB 是怎麼實現以上功能的呢?

"labels"[{
 "latency":        "500"
}]
"samples":[{
 "timestamp": 1473305798,
 "value": 0.9
}]

原始數據分爲兩部分 label,samples。前者記錄監控的維度(標籤: 標籤值),指標名稱和標籤的可選鍵值對唯一確定一條時間序列(使用 series_id 代表);後者包含包含了時間戳(timestamp)和指標值(value)。

series
^
│. . . . . . . . . . . .   server{latency="500"}
│. . . . . . . . . . . .   server{latency="300"}
│. . . . . . . . . .   .   server{}
│. . . . . . . . . . . . 
v
<-------- time ---------->

TSDB 使用 timeseries:doc:: 爲 key 存儲 value。爲了加速常見查詢查詢操作:label 和 時間範圍結合。TSDB 額外構建了三種索引:Series, Label Index 和 Time Index。

以標籤 latency 爲例:

數據計算

強大的存儲引擎爲數據計算提供了完美的助力,使得 Prometheus 與其他監控服務完全不同。Prometheus 可以查詢出不同的數據序列,然後再加上基礎的運算符,以及強大的函數,就可以執行 metric series 的矩陣運算(見下圖)。

如此,Promtheus 體系的能力不弱於監控界的 “數據倉庫”+“計算平臺”。因此,在大數據的開始在業界得到應用,就能明白,這就是監控未來的方向。

一次計算,處處查詢

當然,如此強大的計算能力,消耗的資源也是挺恐怖的。因此,查詢預計算結果通常比每次需要原始表達式都要快得多,尤其是在儀表盤和告警規則的適用場景中,儀表盤每次刷新都需要重複查詢相同的表達式,告警規則每次運算也是如此。因此,Prometheus 提供了 Recoding rules,可以預先計算經常需要或者計算量大的表達式,並將其結果保存爲一組新的時間序列, 達到 一次計算,多次查詢 的目的。

原文鏈接:https://www.cyningsun.com/02-22-2020/hidden-secret-to-understanding-prometheus.html

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/vqaFtr_DiU22Fvd6m7wG7w