1-Prometheus基本概念與部署

工作流程總結

1.Prometheus伺服器週期性地或在設定的時間段內，透過以下方式獲取內容：

• 從已經配置好的job或者exporter中拉取metric（指標）
• 接收從Pushgateway推送過來的metric
• 從其他的Prometheus伺服器中拉取metric

2.Prometheus伺服器獲取到資料後儲存在本地（也可以選擇遠端儲存），透過一定規則對資料進行清理和整理，並且把結果儲存到新的時間序列中。

3.Prometheus伺服器定時查詢已經定義好的規則，若發現滿足定義的觸發條件，便將alert資訊推送至已配置好的Alertmanager。

4.Alertmanager收到alert資訊後，根據配置檔案對接收到的alert資訊進行處理（聚合、去重、降噪），然後將它們轉換為網頁、電子郵件和其他通知方式發出告警。

5.最後透過Prometheus Web UI、Grafana視覺化收集查詢資料

摘錄來自 Prometheus監控技術與實踐

prometheus工作原理

服務發現：Prometheus週期性得以pull的形式對target進行指標採集，而監控目標集合是透過配置檔案中所定義的服務發現機制來動態生成的。
relabel：當服務發現得到所有target後，Prometheus會根據job中的relabel_configs配置對target進行relabel操作，得到target最終的label集合。
採集：進行完上述操作後，Prometheus為這些target建立採集迴圈，按配置檔案裡配置的採集間隔進行週期性拉取，採集到的資料根據Job中的metrics_relabel_configs進行relabel，然後再加入上邊得到的target最終label集合，綜合後得到最終的資料。
儲存： Prometheus不會將採集到的資料直接落盤，而是會將近2小時的series快取在記憶體中，2小時後，Prometheus會進行一次資料壓縮，將記憶體中的資料落盤。
服務發現 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 快取 ==> 2小時落盤。

優勢與不足

1.Prometheus的基本原理是透過HTTP協議週期性獲取被監控元件的狀態資訊，任意元件只要提供HTTP介面就可以接入監控系統內，使得prometheus的適應性很強
2.prometheus並不適合要求監控資料100%準確的場景

摘錄來自 Prometheus監控技術與實踐

二進位制安裝部署

tar -zxvf prometheus-2.4.0.linux-amd64.tar.gz -C /data
cd /data
chown -R prometheus:prometheus prometheus-2.4.0.linux-amd64
ln -sv prometheus-2.4.0.linux-amd64 prometheus
cd /data/prometheus

啟動

./prometheus

熱載入配置

指定配置檔案、啟動熱載入，後臺啟動

nohup ./prometheus --config.file=“/path/to/prometheus.yml" --web.enable-lifecycle &

重啟

curl -XPOST http://localhost:9090/-/reload

systemctl管理prometheus

vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus server
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/data/prometheus/prometheus
--config.file="/data/prometheus/prometheus.yml"
--storage.tsdb.path="/data/prometheus/data"
--storage.tsdb.retention=15d
--web.console.templates="/data/prometheus/consoles"
--web.console.libraries="/data/prometheus/console_libraries"
--web.max-connections=512
--web.external-url"http:// 192.168.24.17:9090"
--web.listen-address "0.0.0.0:9090"
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl start prometheus

system檔案內容介紹

［Unit］，提供服務描述資訊、啟動順序與依賴關係。
［Service］，服務的關鍵部分，設定服務執行時使用的一些具體引數。
［Install］，定義如何啟動，以及是否開機啟動。

常用資訊說明

［Unit］區塊有兩個常用選項：
·Description，服務資訊描述。
·After，服務類別描述，定義unit的啟動次序。

［Service］區塊常用選項：
·Type，設定程序啟動型別，其型別有：
·simple：預設值，執行ExecStart指定的命令，啟動為主程序。
·forking：程序將在啟動過程中使用fork()系統呼叫，建立後父程序立即退出，而子程序將作為該服務的主程序繼續執行。
·oneshot：與simple類似，不同之處在於該程序必須在systemd啟動後繼單元之前退出。
·dbus：類似於simple，但會等待D-Bus訊號後啟動。
·notify：當前服務啟動完畢，通知systemd再繼續往下執行。
·idle：其他任務執行完畢，當前服務才會執行。
·User、Group：設定服務執行的使用者和使用者組。
·EnvironmentFile：環境配置檔案。
·ExecStart：設定啟動服務要執行的命令或指令碼。
·ExecStartPre：在ExecStart之前執行的命令，語法規則與ExecStart=完全相同。
·ExecStartPost：在ExecStart之後執行的命令，語法規則與ExecStart=完全相同。
·ExecReload：可選指令，設定服務被要求重新載入配置時所執行的命令列。
·ExecStop：可選指令，設定停止服務要執行的命令或指令碼。
·Restart：服務程序正常退出、異常退出、被殺死、超時時，是否重新啟動該服務，可以設定如下值：
·no（預設值）：退出後不會重啟。
·on-success：只有正常退出時（退出狀態碼為0），才會[…]”
·on-abnormal：只有被訊號終止和超時，才會重啟。
·on-abort：只有在收到沒有捕捉到的訊號而終止時，才會重啟。
·on-watchdog：只有超時退出時，才會重啟。
·always：不管是什麼退出原因，總是重啟。

［Install］區塊常用選項：
·Alias：可用於啟動的別名。
·WantedBy：表示該服務所在的Target，即所在服務組。

摘錄來自 Prometheus監控技術與實踐

相關概念

指標（metric）
1.具體要監控的東西，由指標名稱和標籤構成，例如CPU速率、分割槽使用率
2.[a-zA-Z_:][a-zA-Z0-9_:]*是有效指標的正規表示式
3.指標名稱可以由字母、數字、下劃線和冒號組成，但應該以字母開頭一個指標由以下幾個欄位組成：
·指標名稱。
·任意數量的標籤，當然也可以是零個，表示為鍵值（key-value）陣列。
·當前指標值。
·可選的指標標準時間戳。

標籤（label）
1.標籤名稱可以包含字母、數字和下劃線，需要以字母a-z或A-Z開頭，然後跟字母、數字和下劃線。
2.標籤的有效匹配正規表示式為[a-zA-Z_][a-zA-Z0-9_]*。
3.以__（雙下劃線）開頭的標籤名稱，只能在系統內部使用”
4.新的標籤會建立新的時間序列

樣本（sample）
1.樣本是按照某個時序以時間維度採集的資料，有序的樣本形成了實際的時間序列資料列表
2.每個樣本包括三部分內容：
·指標
·一個float64型別值（value）。
·毫秒級精度的時間戳（timestamp）。
3.對於沒有按照順序收集的樣本，Prometheus會將其丟棄。

時間序列（Time Series）：時間序列是根據指標名稱和標籤的組合唯一確定的資料序列。它表示隨著時間推移，相同指標名稱和標籤組合對應的測量值的演化。時間序列是Prometheus中儲存和查詢指標資料的基本單位。

作業（job）：Prometheus的採集任務由配置檔案中一個個的Job組成，一個Job裡包含該Job下的所有監控目標的公共配置，比如使用哪種服務發現去獲取監控目標，比如抓取時使用的證書配置，請求引數配置等等。

relabel_configs：每個Job都可以配置一個或多個relabel_config，relabel_config會對Target的label集合進行處理，可以根據label過濾一些
Target或者修改，增加，刪除一些label。relabel_config過程發生在Target開始進行採集之前，針對的是透過服務發現得到的label集合。
metrics_relabel_configs： 每個Job還可以配置一個或者多個metrics_relabel_config，其配置方式和relabel_configs一模一樣，但是其用於處理的是從Target採集到的資料中的label。

Series：一個Series就是指標名 label集合，在皮膚中，表現為一條曲線。

head series： Prometheus會將近2小時的Series快取在記憶體中，稱為head series。
特別注意relable和metrics_relable的區別，前者在抓取前進行，修改的是target的標籤，後者在儲存前進行，修改的是metric的標籤

target：能夠被prometheus監控的目標，稱為target

指標圖例

指標的型別

測量型（gauge）
1.測量值是一個瞬時資料，數值可以上下增減
2.重啟程序後，重置為0
3.典型應用有CPU、記憶體、磁碟的使用率

計數型（counter）
1.最常用
2.從0開始只增不減的數字，可以重置為零
3.典型應用有系統執行時間、裝置收發包位元組數、登入次數

直方圖（histogram）
1.用於表示在一段時間範圍內對資料進行取樣，對指定區間以及總數進行分組統計。
2.典型應用有請求持續時間、響應大小等等
3.在Prometheus系統中的查詢語言中，它有三種作用：
·對每個取樣點進行統計，對應到各個分類值中及bucket（可稱為“桶”）
·對每個取樣點值累計和（sum）
·對取樣點的次數累計和（count）

摘要型（summary）
1.Summary即機率圖，類似於Histogram，常用於跟蹤與時間相關的資料。
2.典型的應用包括請求持續時間、響應大小等。
3.Summary同樣提供樣本的count和sum功能；還提供quantiles功能，可以按百分比劃分跟蹤結果，例如，quantile取值0.95，表示取樣本里面的95%資料。Histogram需要透過_bucket計算quantile，而Summary直接儲存了quantile的值”<basename>

prometheus核心元件

1.prometheus伺服器
2.client library
3.expertor
4.pushgateway
5.altermanager

指標摘要

指標摘要通常來說， 單個指標對我們價值很小， 往往需要聯合並視覺化多個指標， 這其中需要應用一些數學變換。 例如， 我們可能會將統計函式應用於指標或指標組， 一些可能應用的常見函式包括：
·計數： 計算特定時間間隔內的觀察點數。
·求和： 將特定時間間隔內所有觀察點的值累計相加。
·平均值： 提供特定時間間隔內所有值的平均值。
·中間數： 數值的幾何中點， 正好50％的數值位於它前面， 而另外50％則位於它後面。
·百分位數： 度量佔總數特定百分比的觀察點的值。
·標準差： 顯示指標分佈中與平均值的標準差， 這可以測量出資料集的差異程度。 標準差為0表示資料都等於平均值， 較高的標準差意味著資料分佈的範圍很廣。
·變化率： 顯示時間序列中資料之間的變化程度

告警要考慮的因素

要建立一個出色的通知系統， 需要考慮以下基礎資訊：
·哪些問題需要通知
·誰需要被告知
·如何告知他們
·多久告知他們一次
·何時停止告知以及何時升級到其他人

Prometheus Relabel機制
https://blog.csdn.net/lovely_nn/article/details/123043447

relabel機制的意義

在 Prometheus 中，Relabel（重標記）機制是為了動態地修改或過濾採集到的監控資料（或樣本），以便對資料進行更準確的處理、儲存、展示或分析。
這機制的存在和意義主要基於以下幾點：

1. 資料清洗與修正：採集到的監控資料可能會包含不一致、不準確或需要修正的部分。Relabel 可以用來清洗和修正這些資料，確保其準確性和可信度。
2. 標準化資料格式：不同來源的監控資料可能具有不同的資料格式或標籤。Relabel 可以用於標準化這些資料，使其符合統一的資料格式，便於後續處理。
3. 過濾和排除不需要的資料：有時候，我們可能只對特定的資料感興趣，Relabel 可以幫助我們過濾掉不需要的資料，減少資料儲存和處理的負擔。
4. 動態標記：在執行時，可以根據特定規則動態地為資料新增、修改或刪除標籤，這種動態標記可以基於已有的標籤或者資料內容。

relabel的型別

relabel_config （常用）
在被prometheus抓取之前修改，針對的是target

metric_relabel_configs （常用）
在被prometheus儲存之前修改，針對的是Metric

alert_relabel_configs
在被髮送到alertmanager之前，針對的是alert

write_relabel_configs
寫到遠端儲存的樣本

工作步驟

1. separator 分隔符將 source_labels 中的標籤列表值連線起來
2. regex 正規表示式與上一步連線的字串進行匹配
3. replacement 引用上面的regex正規表示式捕獲組，透過($1, $2, ...)將它們的值進行替換
4. 把經過正規表示式替換的 replacement 字串作為 target_label 標籤的新值儲存起來

relabel_config配置語法

[ source_labels: '[' [, ...] ']' ]
[ separator: | default = ; ]
[ target_label: ]
[ regex: | default = (.*) ]
[ modulus: ]
[ replacement: | default = $1 ]
[ action: <relabel_action> | default = replace ]

欄位說明
action
執行的 relabeling 動作，可選值包括 replace、keep、drop、hashmod、labelmap、labeldrop 、labelkeep，預設值為 replace
separator
分隔符，一個字串，用於在連線源標籤 source_labels 時分隔它們，預設為;
source_labels
源標籤，使用配置的分隔符串聯的標籤名稱列表，並與提供的正規表示式進行匹配
target_label
目標標籤，當使用 replace 或者 hashmod 動作時，應該被覆蓋的標籤名
regex
正規表示式，用於匹配串聯的源標籤，預設為 (.*)，匹配任何源標籤
modulus
模數，串聯的源標籤雜湊值的模，主要用於 Prometheus 水平分片
replacement
寫在目標標籤上，它可以參考由 regex 捕獲的正規表示式捕獲組

關於relabel_config的action型別說明：
replace：設定或替換/覆蓋標籤值，是預設的action
keep：滿足特定條件的例項物件進行採集，其他的不採集
drop：滿足特定條件的例項不採集，其他的採集
labeldrop：對抓取的例項特定標籤進行刪除，其他的保留
labelkeep：對抓取的例項特定標籤進行保留，其他標籤刪除
labelmap：將源標籤的值對映到一組新的標籤中去
hashmod：對服務的整體目標進行分片

白盒/黑盒監控
黑盒監控，主要關注的是現象，一般都是正在發生的東西，例如出現一個告警，某檔案系統不可寫入，那麼這種監控就是站在使用者的角度能看到的監控，重點在於能對正在發生的故障進行告警。
白盒監控，主要關注的是原因，也就是系統內部暴露的一些指標，將資料採集後統一發給監控系統。

Prometheus的監控採集形式（白盒）
Exporter target的agent端
Instrumentation target內建prometheus相容的指標暴露器
Pushgateway 短期的，不易於實現的，自定義的監控

監控的維度
系統層監控 CPU，記憶體
中介軟體/基礎設施應用的監控 Nginx，MongDB
應用層的監控 程式碼的狀態、效能
業務層的監控 系統登陸、註冊數

聚合函式表示式

([parameter,])[without|by()]
先分組，後聚合