本文來自Prometheus官網手冊1、Prometheus官網手冊2 和 Prometheus簡介java
每個時間序列數據由metric度量指標名稱和它的標籤labels鍵值對集合惟一肯定。python
這個metric度量指標名稱指定監控目標系統的測量特徵(如:http_requests_total
- 接收http請求的總計數)。 git
注意:冒號保留用於用戶定義的錄製規則。 它們不該被exporter或直接儀表使用。github
labbels開啓了Prometheus的多維數據模型:對於相同的度量名稱,經過不一樣標籤列表的結合, 會造成特定的度量維度實例。(例如:全部包含度量名稱爲/api/tracks
的http請求,打上method=POST
的標籤,則造成了具體的http請求)。這個查詢語言在這些度量和標籤列表的基礎上進行過濾和聚合。改變任何度量上的任何標籤值,則會造成新的時間序列圖。golang
metric度量指標可能包含ASCII字母、數字、下劃線和冒號,他必須配正則表達式[a-zA-Z_:][a-zA-Z0-9_:]*。
正則表達式
label標籤名稱能夠包含ASCII字母、數字和下劃線。它們必須匹配正則表達式[a-zA-Z_][a-zA-Z0-9_]*
。api
帶有_
下劃線的標籤名稱被保留內部使用,標籤labels值包含任意的Unicode碼。ruby
具體詳見metrics和labels命名最佳實踐。函數
樣本造成了實際的時間序列數據列表。每一個採樣值包括:spa
表示一個度量指標和一組鍵值對標籤,須要使用如下符號:
[metric name]{[label name]=[label value], ...}
例如,度量指標名稱是api_http_requests_total
, 標籤爲method="POST"
, handler="/messages"
的示例以下所示:
api_http_requests_total{method="POST", handler="/messages"}
這些命名和OpenTSDB使用方法是同樣的。
Prometheus客戶端庫提供了四種核心的metrics類型,這四種類型目前僅在客戶端庫和wire協議中區分。Prometheus服務尚未充分利用這些類型,未來可能會發生改變。
counter 是表示單個單調遞增計數器的累積度量,其值只能在重啓時增長或重置爲零。 例如,您可使用計數器來表示所服務的請求數,已完成的任務或錯誤。
不要使用計數器來暴露可能減小的值。例如,不要使用計數器來處理當前正在運行的進程數,而是使用gauge。
客戶端使用計數器的文檔:
gauge是一個度量指標,它表示一個既能夠遞增, 又能夠遞減的值。
測量器主要測量相似於溫度、當前內存使用量等,也能夠統計當前服務運行隨時增長或者減小的Goroutines數量
客戶端使用計量器的文檔:
直方圖對觀察結果進行採樣(一般是請求持續時間或響應大小等),並將其計入可配置存儲桶中。它還提供全部觀察值的總和。基本度量標準名稱爲<basename>的直方圖在scrape期間顯示多個時間序列:
<basename>_bucket{le="<upper inclusive bound>"}
<basename>_sum
<basename>_count
,和<basename>_bucket{le="+Inf"}
相同使用histogram_quantile函數, 計算直方圖或者是直方圖聚合計算的分位數閾值。 一個直方圖計算Apdex值也是合適的, 當在buckets上操做時,記住直方圖是累計的。詳見直方圖和總結
客戶庫的直方圖使用文檔:
相似histogram柱狀圖,summary是採樣點分位圖統計(一般是請求持續時間和響應大小等)。雖然它還提供觀察的總數和全部觀測值的總和,但它在滑動時間窗口上計算可配置的分位數。基本度量標準名稱<basename>
的summary
在scrape期間公開了多個時間序列:
<basename>{quantiles="[φ]"}
<basename>_sum
, 是指全部觀察值的總和<basename>_count
, 是指已觀察到的事件計數值有關φ-分位數,Summary用法和histogram圖差別的詳細說明,詳見histogram和summaries
有關summaries
的客戶端使用文檔: