prometheus雜碎

一個監控及告警的系統，內含一個TSDB(時序數據庫)。在我而言是一個數採程序

重要成員分三塊

• exploter:實際是外部接口，讓各個程序實現這個接口，供普羅米修斯定時今後接口中取數
• alert：告警模塊
• prometheus：其實是數採模塊+存儲模塊，可是它的存儲不是持久化的

 

普羅米修斯的數據是一個值時間序列，例如

website_request_count{method="GET",path="/home/index",query="id=2"} 0.001

website_request_count是一個監控指標，花括號中的每一個值是label標籤，最後的是此次監控的值，還有一個未出現的量就是時間戳。

與熟悉的數據庫相比起來，一個監控指標比如一個表，時間戳，值，與每一個lebel的名稱就是列。每一組label組成一個序列。一旦某個label不一致（包含label的數量，label的名稱和值）都會被視爲不一樣的序列

普羅米修斯的數據類型分四種

• count:計數器類型，只增不減
• gauge：儀表盤類型，數值可增可減
• Hisgram：直方圖類型，按照必定區間給各個段分組統計值，每一個段爲一個bucket
• summary：摘要類型，按分位數統計各個分組結果

Hisgram與summary比較類似，應用場景也相似：主要源於數據分佈不均的狀況下（極值delta較大或出現利羣值時），平均數已經沒法準確反映數據的總體狀況，故須要對數據進行分組，按各個分組的統計值反應數據的總體狀況。其中Hisgram是按照必定的區間來給數據分段，默認範圍是{.005, .01, .025, .05, .075, .1, .25, .5, .75, 1, 2.5, 5, 7.5, 10}，它只能給數據分段，並不能得出這部分數據的中位數，4分位數等，若須要則要在服務端處理，而summary則能夠在客戶端已得出值。兩種數據類型都帶有_sum與_count兩個指標。

從刮擦數據的結果中能夠得出此數據的數據類型

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.

# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173

prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002

prometheus_tsdb_wal_fsync_duration_seconds_count 216

每一組指標頂端都有兩行註釋，第一行是對於這個指標的描述，第二行則是指明瞭這個指標的數據類型

 

 

普羅米修斯的查詢中輸入監控指標則能夠兩種形式（圖表和數據）展現結果，該結果會包含全部序列的值（即出現過的label和值的集合）

若是要對某些label進行篩選，則能夠下面形式

up{instance="helloworld"}

此時會查出全部instance爲helloworld的序列

Prometheus既然包含了一個TSDB，對這部分數據則提供了一個查詢語言叫ProuQL，下面則簡單提一些內置函數

sum,avg，按某個指標進行求和運算，如sum(up),avg(up);

有時候會出現相似這樣的寫法 sum by(job) (up)或者sum with out(job) (up) 這樣的寫法，與實際上都是相似於SQL的grouop by，by則針對job 這個label的值分組統計up的值，而with out則除了job lebel外全部label都拿來做分組條件。

up[5m]寫法 方括號中表明5分鐘，能夠是1分鐘1m或者1小時1h。此寫法會得出一個向量集合，所謂向量實際是一個結果中帶了兩個值，自己指標的值和時間戳，中間以@做爲分隔，這樣的寫法一般結合rate，irate和delta函數。

rate（up[5m]）,求up指標5m鍾內每兩個量變化率的平均值，是一個平均變化率，假設一組數，a1@t1,a2@t2,a3@t3,……an@tn

rate=（ ∑ (a2-a1)/(t2-t1)+(a3-a2)/(t3-t2)）/n

irate（up[5m]）則是求5m這批數據中，相鄰最近的兩個值之間的變化率，是一個瞬時變化率

delta(up[5m])則是求這5m這批數據中，收尾兩個值的相差值

up{job=~"^123$"}此處job表示是按照正則匹配(出現了「=~」)，然後面則跟着對應的正則表達式，^和$僅僅是正則中的開始與結束符號而已。

 

prometheus的配置採用yaml

scrape_config主要是配置各個刮擦任務，每一個刮擦任務爲一個job，每一個job的能夠有獨立的刮擦週期，並有不一樣的刮擦類型，能夠有普通的static_configs，還有其餘針對不一樣exporter的配置，如azure_sd_config，kubernetes_sd_config等，此處要提的是relable這個配置項，relable的配置項的內容能夠影響着跨擦結果，裏面的label不屬於刮擦數據的內容，可是它有可能會被增長到刮擦的結果中而存到庫裏面去。

每一個relable配置項有如下幾個屬性

action:表明relable的行爲，包含

replace:若是值匹配了regex，則把source_labels替換，替換的label值看replacement而定，替換的label名按target_label而定；

keep：若是label名匹配了 regex的，此條數據才保留

drop：若是label名匹配了regex的，此條數據則被捨棄掉，與上面的相反

hashmad：做用未明

labelmap：通常結果須要多個label通過正則運算後拼湊組合生成新的值的會用這種，label值結果會按replacement生成；

labeldrop：與drop相似，但它捨棄的只是label而已且是拿label值與regex匹配；

labelkeep：與labeldrop相反

regex：正則表達式，默認值是（.*）；

source_labels：一個數組，用於處理的各個原始label;

spearetor:默認值是 ";"

target_label:處理後新的label名

replacement：默認值是$1，replace和labelmap按這個來生成結果，後面是數字代表第幾個與regex匹配的結果

 

接下來談的是prometheus的服務發現，在prometheus界面中有Target與Service Discovery兩個菜單，這兩個菜單內容與服務發現極有關係。回顧上述關於scrape的配置內容，咱們配置的只有static_config，此處通常設置一個target則往一個節點處刮擦數據。因爲他是靜態，而對於動態的則是基於服務發現的，凡是刮擦類型中帶sd的（service-discover）均有服務發現的功能，該job中的全部節點都無需經過手動配置而加入被刮擦的集合中，如kubernetes_sd_config，按照官網介紹，根據role屬性的不一樣設置而對k8s的不一樣對象進行scrape,如設成service，則scrape回來的數據包含這些label：

__meta_kubernetes_namespace

__meta_kubernetes_service_name

__meta_kubernetes_service_label_

__meta_kubernetes_service_annotation_

__meta_kubernetes_service_port_name

__meta_kubernetes_service_port_protocol

__meta_kubernetes_service_port_number

經過service discover界面看出果然存在若干個被發現的服務（一行表明一個服務），

 

 

還記得relabel中的drop action,這裏一個發現了7個服務，可是被drop掉的有6個，最終被保存下來的服務的數據僅有一個序列，這個在Taget頁面中獲得展現，Target就是展現被篩選事後剩餘的須要真正監控的服務。