上篇提問

• 時間序列的時間戳該怎麼決定？
• Prometheus 和 OpenMetrics 的時間序列的型態有哪些？
• Recording Rule 如何自我參照？

時間序列的時間戳該怎麼決定？

本節的問題有兩個︰

• 如果兩相關時間序列時間戳沒對應到的話，要怎麼運算呢？
• 我們該對樣本的時間戳做什麼規範？

顯然如果時間序列的時間戳沒對應到，運算上會難以理解。所以 Prometheus 會盡一切可能讓拉進來的時間序列的時間戳對應到。也因此一般標的 /metric 的 http 端口所返回的樣本值不建議加時間戳，由 Prometheus 將數值拉出來後，再加上拉的時間戳，甚至會在 ms 尺度微調，以確保時間對上。如果標的端硬限制時間戳，Prometheus 在微調不了的情況下，會丟棄這個樣本值。
因為 Prometheus 的定位是監控系統，而不是 100% 正確的時間序列資料庫，所以這麼做是可以被接受的。

然而有些時候我們不得已非得固定樣本的時間戳，例如在多個 Prometheus 之間同步樣本值時，就需要固定樣本的時間戳。不能說 A Prometheus 從標的拉來的樣本時間戳是 2021-01-01 00:00:00，而B Prometheus 從 A Prometheus 拉時，時間戳變成 2021-01-01 00:00:01。
這種情況下 B Prometheus 需要開啟 OOO (Out of Order) 模式，這樣 B Prometheus 就不會因為收到亂序的樣本而丟棄。

OOO 的詳細行為之後在 PromQL 篇章說明。

Prometheus 和 OpenMetrics 的時間序列的型態有哪些？

本節的問題有兩個︰

• OpenMetrics 的各型態分別是什麼？
• Prometheus Metrics 的型態 跟 OpenMetrics 一樣嗎？
• OpenMetrics 裡的保留標籤名 le 和 quantile 是做什麼的？
• float64 的樣本值精度夠用嗎？

OpenMetrics 指標族的八種型態

Gauge

一個隨時間變化的數值，例如 CPU 使用率。

Counter

一個隨時間遞增的數值，例如 HTTP 請求次數。一個樣本包含

• total 也就是累計值
• created　也就是創建時間
  create 的用途是為了在樣本值被重置時，可以知道這個樣本值是什麼時候被重置的。在監控面版上就不用因為機器重啟而看到一個突然的斷點。

StateSet

一個列舉值，例如服務的狀態。表示成 0, 1 的話，只能有一個值是 1，其他都是 0。

# HELP service_status The status of the service.
# TYPE service_status StateSet
service_status{service_status="ok"} 1
service_status{service_status="deploying"} 0
service_status{service_status="unknown"} 0

Info

一個固定的值，例如服務的版本號。

vesion_info{version_info="1.0.0"} 1

Histogram

一個直方圖，表達每個數值區間有多少累積數量。例如 HTTP 請求的耗時。樣本也需包含創建時間。
標籤 le 代表小於等於，例如 le="0.1" 代表小於等於 0.1 秒的累積數量。

# HELP http_request_duration_seconds The HTTP request latencies in seconds.
# TYPE http_request_duration_seconds Histogram
http_request_duration_seconds_bucket{le="0.1"} 10
http_request_duration_seconds_bucket{le="0.2"} 50
http_request_duration_seconds_bucket{le="0.4"} 110
http_request_duration_seconds_bucket{le="0.8"} 150
http_request_duration_seconds_bucket{le="1.6"} 160

GaugeHistogram

同為直方圖，但每個數值區間的值可以增減。例如還在處理中的連線延時。

ongoing_http_request_duration_seconds_bucket{le="0.1"} 1
ongoing_http_request_duration_seconds_bucket{le="0.2"} 5
ongoing_http_request_duration_seconds_bucket{le="0.4"} 11
ongoing_http_request_duration_seconds_bucket{le="0.8"} 15
ongoing_http_request_duration_seconds_bucket{le="1.6"} 16

Summary

一個直方圖，表達每個偏差值的對應數值。例如 HTTP 請求的耗時。

# HELP http_request_duration_seconds The HTTP request latencies in seconds.
# TYPE http_request_duration_seconds Summary
http_request_duration_seconds{quantile="0.5"} 0.2
http_request_duration_seconds{quantile="0.9"} 0.3
http_request_duration_seconds{quantile="0.99"} 0.5

這個計算一般由標的統計（使用算力進行資訊壓縮）後，http 只會返回統計完的結果。統計窗口的長度也是由標的端實作，一般預設是 10 秒。

Unknown

所有不符合以上型態的單一序列都是 Unknown。它是用來表示 OpenMetrics 不認識的指標。

Prometheus 標的函式庫的四種型態

Counter, Gauge, Histogram, Summary 都符合 OpenMetrics 只是這些型態分類只用在 Prometheus 的標的函式庫。Prometheus 本身不區分型態。

至於第五種型態，Native Histogram 還不是很泛用。它是 Prometheus 獨有的新型態，動態分組的直方圖。既不符合 OpenMetrics 也甚至不符合 Prometheus 既有的時間序列結構，必須用特別的 flag 開啟，標的函式庫也要另外支援以 protobuf 傳輸資料。

Prometheus 與 OpenMtrics 的異同

一個值得注意的點是是 Prometheus 只有 float，OpenMetrics 有 bool 和　int。
Prometheus 認為樣本值只有 float64 的精度對於監控來說是夠用的。以下情況實務上不容易發生：

• 一個計數樣本值 > 2^53
• 我們對它 +1，結果值沒有變化

因為 2^53 次方以一秒幾百萬的速度，也要兩百多年才會達到。所以 float64 的精度對於監控來說是夠用的。

Recording Rule 如何自我參照？

本節的問題有兩個︰

• 若 Recording Rule 參照其他 Recording Rule 生出的指標，時間戳會𨒂遲嗎？
• Recording Rule 可以參照自身嗎？

Recording Rule 的樣本生成和從 http 拉樣本值的一樣，都是由 Prometheus 訂時間隔觸發。會根據當下的指標值做運算，即使用到自己也沒問題。
如果運算太花時間，超過了下一次觸發的時間，下一次運算就不會發生。就像 http 超時一樣。
然而官方建議時可以設一個時間偏移量，以確保 Recording Rule 的運算不會因為來源資料還沒拉到而算出錯不可靠的指標值。