章節1-Prometheus基礎(1)

目錄

• 1、Prometheus安裝部署
  • 1. 簡介
    • 監控的目的
    • Prometheus的優點
  • 2. Prometheus工做流程：
    • 2.1 服務端
    • 2.2 客戶端
    • 2.3metrics主要數據類型
  • 3. 安裝部署Prometheus Server
  • 4. 配置(more)
    • 4.1 配置文件(mroe)
    • 4.2 prometheus.yml的樣例
• 2、使用Node Exporter採集主機運行數據
  • 1. 部署
  • 2. 熟悉Node Exporter監控指標
  • 3. 從Node Exporter收集監控數據
• 3、使用PromQL查詢監控數據

---

本文參考：
《Prometheus官方文檔》，或網盤下載《Prometheus操做指南.pdf》(提取碼：1l8m)

1、Prometheus安裝部署

1. 簡介

Prometheus受啓發於Google的Brogmon監控系統（類似的Kubernetes是從Google的Brog系統演變而來），從 2012年開始由前Google工程師在Soundcloud以開源軟件的形式進行研發，而且於2015年早期對外發布早期版本。 2016年5月繼Kubernetes以後成爲第二個正式加入CNCF基金會的項目，同年6月正式發佈1.0版本。2017年末發佈 了基於全新存儲層的2.0版本，能更好地與容器平臺、雲平臺配合。 Prometheus做爲新一代的雲原生監控系統，目前已經有超過650+位貢獻者參與到Prometheus的研發工做上，而且 超過120+項的第三方集成。

監控的目的

• 長期趨勢分析：經過對監控樣本數據的持續收集和統計，對監控指標進行長期趨勢分析。例如，經過對磁盤空間
• 增加率的判斷，咱們能夠提早預測在將來什麼時間節點上須要對資源進行擴容。
• 對照分析：兩個版本的系統運行資源使用狀況的差別如何？在不一樣容量狀況下系統的併發和負載變化如何？經過 監控可以方便的對系統進行跟蹤和比較。
• 告警：當系統出現或者即將出現故障時，監控系統須要迅速反應並通知管理員，從而可以對問題進行快速的處理 或者提早預防問題的發生，避免出現對業務的影響。
• 故障分析與定位：當問題發生後，須要對問題進行調查和處理。經過對不一樣監控監控以及歷史數據的分析，可以 找到並解決根源問題。
• 數據可視化：經過可視化儀表盤可以直接獲取系統的運行狀態、資源使用狀況、以及服務運行狀態等直觀的信 息。

與常見監控系統比較
對於經常使用的監控系統，如Nagios、Zabbix的用戶而言，每每並不能很好的解決上述問題。

Prometheus的優點

Prometheus是一個開源的完整監控解決方案，其對傳統監控系統的測試和告警模型進行了完全的顛覆，造成了基於 中央化的規則計算、統一分析和告警的新模型。 相比於傳統監控系統Prometheus具備如下優勢：

易於管理

Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數據庫，緩存等等)。惟一須要的就是 本地磁盤，所以不會有潛在級聯故障的風險。

Prometheus基於Pull模型的架構方式，能夠在任何地方（本地電腦，開發環境，測試環境）搭建咱們的監控系統。 對於一些複雜的狀況，還可使用Prometheus服務發現(Service Discovery)的能力動態管理監控目標。

監控服務的內部運行狀態

Pometheus鼓勵用戶監控服務的內部狀態，基於Prometheus豐富的Client庫，用戶能夠輕鬆的在應用程序中添加 對Prometheus的支持，從而讓用戶能夠獲取服務和應用內部真正的運行狀態。

強大的數據模型

全部採集的監控數據均以指標(metric)的形式保存在內置的時間序列數據庫當中(TSDB)。全部的樣本除了基本的指 標名稱之外，還包含一組用於描述該樣本特徵的標籤。

以下所示：

http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

每一條時間序列由指標名稱(Metrics Name)以及一組標籤(Labels)惟一標識。每條時間序列按照時間的前後順序 存儲一系列的樣本值。

表示維度的標籤可能來源於你的監控對象的狀態，好比code=404或者content_path=/api/path。也可能來源於 的你的環境定義，好比environment=produment。基於這些Labels咱們能夠方便地對監控數據進行聚合，過濾， 裁剪。

強大的查詢語言PromQL
Prometheus內置了一個強大的數據查詢語言PromQL。 經過PromQL能夠實現對監控數據的查詢、聚合。同時 PromQL也被應用於數據可視化(如Grafana)以及告警當中。

經過PromQL能夠輕鬆回答相似於如下問題：

• 在過去一段時間中95%應用延遲時間的分佈範圍？
• 預測在4小時後，磁盤空間佔用大體會是什麼狀況？
• CPU佔用率前5位的服務有哪些？(過濾)

高效
對於監控系統而言，大量的監控任務必然致使有大量的數據產生。而Prometheus能夠高效地處理這些數據，對於單 一Prometheus Server實例而言它能夠處理：

• 數以百萬的監控指標
• 每秒處理數十萬的數據點。

可擴展
Prometheus是如此簡單，所以你能夠在每一個數據中心、每一個團隊運行獨立的Prometheus Sevrer。Prometheus 對於聯邦集羣的支持，可讓多個Prometheus實例產生一個邏輯集羣，當單實例Prometheus Server處理的任務 量過大時，經過使用功能分區(sharding)+聯邦集羣(federation)能夠對其進行擴展。

易於集成
使用Prometheus能夠快速搭建監控服務，而且能夠很是方便地在應用程序中進行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等語言的客戶端SDK，基於這些SDK能夠快速讓應用程序歸入到 Prometheus的監控當中，或者開發本身的監控數據收集程序。同時這些客戶端收集的監控數據，不只僅支持 Prometheus，還能支持Graphite這些其餘的監控工具。

同時Prometheus還支持與其餘的監控系統進行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。

Prometheus社區還提供了大量第三方實現的監控數據採集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。

可視化
Prometheus Server中自帶了一個Prometheus UI，經過這個UI能夠方便地直接對數據進行查詢，而且支持直接 以圖形化的形式展現數據。同時Prometheus還提供了一個獨立的基於Ruby On Rails的Dashboard解決方案 Promdash。最新的Grafana可視化工具也已經提供了完整的Prometheus支持，基於Grafana能夠建立更加精美的 監控圖標。基於Prometheus提供的API還能夠實現本身的監控可視化UI。

開放性
一般來講當咱們須要監控一個應用程序時，通常須要該應用程序提供對相應監控系統協議的支持。所以應用程序會與 所選擇的監控系統進行綁定。爲了減小這種綁定所帶來的限制。對於決策者而言要麼你就直接在應用中集成該監控系 統的支持，要麼就在外部建立單獨的服務來適配不一樣的監控系統。

而對於Prometheus來講，使用Prometheus的client library的輸出格式不止支持Prometheus的格式化數據， 也能夠輸出支持其它監控系統的格式化數據，好比Graphite。

所以你甚至能夠在不使用Prometheus的狀況下，採用Prometheus的client library來讓你的應用程序支持監控 數據採集。

Architecture
This diagram illustrates the architecture of Prometheus and some of its ecosystem components:

---

Prometheus是一個開放性的監控解決方案，用戶能夠很是方便的安裝和使用Prometheus而且可以很是方便的對其 進行擴展。爲了可以更加直觀的瞭解Prometheus Server，接下來咱們將在本地部署並運行一個Prometheus Server實例，經過Node Exporter採集當前主機的系統資源使用狀況。 並經過Grafana建立一個簡單的可視化儀 錶盤。

---

2. Prometheus工做流程：

2.1 服務端

Prometheus服務端以一個進程方式啓動，若是不考慮參數和後臺運行的話，只須要解壓安裝包以後運行./prometheus腳本便可啓動，程序默認監聽在9090端口。每次採集到的數據叫作metrics。這些採集到的數據會先存放在內存中，而後按期再寫入硬盤，若是服務從新啓動的話會將硬盤數據寫回到內存中，因此對內存有必定消耗。Prometheus不須要重視歷史數據，因此默認只會保留15天的數據。

2.2 客戶端

Prometheus客戶端分爲pull和push兩種方式。若是是pull形式的話則是服務端主動向客戶端拉取數據，這樣須要客戶端上安裝exporters（導出器）做爲守護進程，官網上也提供了不少exporters能夠下載使用，好比使用最多的node_exporters，幾乎把系統自身相關數據所有采集了，很是全面，node_exporter默認監聽9100端口。

若是是push形式的話客戶端須要安裝pushgateway插件，而後運須要運維人員用腳本把監控數據組織成鍵值形式提交給pushgateway，再由它提交給服務端。它適合於現有exporters沒法知足需求時，本身靈活定製。

2.3metrics主要數據類型

Gauges：最簡單、使用最多的指標，獲取一個返回值，這個返回值沒有變化規律，不能確定它必定是增加或是減小的狀態，採集回來是多少就是多少。好比硬盤容量、CPU內存使用率都適合使用Gauges數據類型。

Counters：計數器。數據從0開始累計，理想狀態下應該是永遠增加或者是不變。適合統計機器開機時間、HTTP訪問量

Histograms：和summary同樣屬於高級指標，用於統計數據的分佈狀況。好比最小值、最大值、中間值。這個類型不太好理解，好比說統計一天的日誌，大部分用戶響應時間都是正常的，只有少許用戶異常，若是這個時候取平均值的話，這少許用戶的異常狀況就會被掩蓋過去，而Histograms能夠分別統計出所有用戶的響應時間，好比0-1秒的用戶有多少、1-2秒的用戶有多少（其實有點像Kibana）

3. 安裝部署Prometheus Server

Prometheus基於Golang編寫，編譯後的軟件包，不依賴於任何的第三方依賴。用戶只須要下載對應平臺的二進制 包，解壓而且添加基本的配置便可正常啓動Prometheus Server。

環境

• 系統環境：Centos 7.2
• 軟件版本：prometheus-2.13.1.linux-amd64.tar.gz
• 下載地址：https://prometheus.io/download/

安裝

tar -xzvf prometheus-2.13.1.linux-amd64.tar.gz
mkdir /usr/local/prometheus
mv prometheus-2.13.1.linux-amd64 /usr/local/prometheus

建立數據目錄

mkdir -p /data/prometheus/data

用戶受權

useradd prometheus -s /sbin/nologin
chown -R prometheus:prometheus /usr/local/prometheus /data/prometheus

添加啓動服務
編輯/usr/lib/systemd/system/prometheus.service，配置以下：

[Unit]
Description=prometheus
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus/data
Restart=on-failure
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target

啓動

systemctl daemon-reload
systemctl enable prometheus.service
systemctl start prometheus.service

驗證
WEB地址：http://ip:9090

4. 配置(more)

Prometheus能夠在運行時從新加載其配置。若是新配置格式不正確，則更改將不會應用。經過向Prometheus進程發送SIGHUP或向/-/reload端點發送HTTP POST請求來觸發配置從新加載（--web.enable-lifecycle啓用該標誌時）。這還將從新加載全部已配置的規則文件。

yaml文件書寫的要求以下：

• 大小寫敏感
• 使用縮進表示層級關係
• 縮進時不容許使用Tab鍵，只容許使用空格。
• 縮進的空格數目不重要，只要相同層級的元素左側對齊便可

4.1 配置文件(mroe)

要指定要加載的配置文件，請使用該--config.file標誌。
該文件以YAML格式寫入，由如下所述的方案定義。方括號表示參數是可選的。對於非列表參數，該值設置爲指定的默認值。

通用佔位符定義以下：

• <boolean>：能夠接受值的布爾值true或false
• <duration>：與正則表達式匹配的持續時間 [0-9]+(ms|[smhdwy])
• <labelname>：與正則表達式匹配的字符串 [a-zA-Z_][a-zA-Z0-9_]*
• <labelvalue>：一串unicode字符
• <filename>：當前工做目錄中的有效路徑
• <host>：由主機名或IP後跟可選端口號組成的有效字符串
• <path>：有效的網址路徑
• <scheme>：能夠採用值http或https
• <string>：常規字符串
• <secret>：是祕密的常規字符串，例如密碼
• <tmpl_string>：使用前已模板擴展的字符串

其餘佔位符分別指定。
在這裏能夠找到有效的示例文件。
全局配置指定在全部其餘配置上下文中有效的參數。它們還用做其餘配置部分的默認設置。

global:
  # 默認狀況下抓取目標的頻率.
  [ scrape_interval: <duration> | default = 1m ]

  # 抓取超時時間.
  [ scrape_timeout: <duration> | default = 10s ]

  # 評估規則的頻率.
  [ evaluation_interval: <duration> | default = 1m ]

  # 與外部系統通訊時添加到任什麼時候間序列或警報的標籤
  #（聯合，遠程存儲，Alertma# nager）.
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# 規則文件指定了一個globs列表. 
# 從全部匹配的文件中讀取規則和警報.
rule_files:
  [ - <filepath_glob> ... ]

# 抓取配置列表.
scrape_configs:
  [ - <scrape_config> ... ]

# 警報指定與Alertmanager相關的設置.
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 與遠程寫入功能相關的設置.
remote_write:
  [ - <remote_write> ... ]

# 與遠程讀取功能相關的設置.
remote_read:
  [ - <remote_read> ... ]

4.2 prometheus.yml的樣例

(標籤部份內容不是必須的，能夠了解)

global:
  scrape_interval: 15s #抓取數據的頻率，默認15秒。該配置也可配置在每一個job_name中
  evaluation_interval: 15s #監控規則評估頻率，好比設置了當內存使用大於70%發出報警的規則，而後每15秒來執行一次這個規則

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

scrape_configs:
  - job_name: 'prometheus-server' #做業名，能夠理解爲組名，其下能夠有多個實例配置
    static_configs:
    - targets: ['localhost:9090'] #節點的地址，能夠寫多個地址
# params: #過濾器
# collect[]:
# - cpu #只採集CPU數據
  - job_name: 'www'
    static_configs:
    - targets: ['ip:9100','ip:9100']
      labels: #自定義標籤，能夠經過標籤進行統一管理
        idc:beijing #增長一個idc標籤，內容爲beijing
#使用正則替換標籤
  - job_name: 'node'
    static_configs:
    - targets: ['ip:9100','ip:9100']
    metric_relable_configs: #經過正則重命名標籤
    - action: replace #replace替換是默認動做。此外還有keep（只參加匹配標籤的實例）、drop（不採集匹配正則的實例）、labelkeep\labeldrop(對標籤進行過濾處理而非實例)等動做
      source_labels: ['job'] #原標籤，job是默認就會產生的標籤，這裏job標籤的值是node
      regex: (.*) #正則匹配，這裏匹配job標籤內的內容，也就是node
      replacement: beijing #替換成什麼內容，若是寫$1就是將正則裏的內容拿過來
      target_label: idc #把替換到的內容賦值給idc標籤
    - action: labeldrop #刪除標籤
      regex: job #把原有的job標籤刪除不顯示

---

2、使用Node Exporter採集主機運行數據

在Prometheus的架構設計中，Prometheus Server並不直接服務監控特定的目標，其主要任務負責數據的收集， 存儲而且對外提供數據查詢支持。所以爲了可以可以監控到某些東西，如主機的CPU使用率，咱們須要使用到 Exporter。Prometheus週期性的從Exporter暴露的HTTP服務地址（一般是/metrics）拉取監控樣本數據。 從上面的描述中能夠看出Exporter能夠是一個相對開放的概念，其能夠是一個獨立運行的程序獨立於監控目標之外， 也能夠是直接內置在監控目標中。只要可以向Prometheus提供標準格式的監控樣本數據便可。

這裏爲了可以採集到主機的運行指標如CPU, 內存，磁盤等信息。咱們可使用Node Exporter(prometheus客戶端)。

1. 部署

Node Exporter一樣採用Golang編寫，而且不存在任何的第三方依賴，只須要下載，解壓便可運行。能夠從 https://prometheus.io/download/，獲取最新的node exporter版本的二進制包。

curl -OL https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -zxf node_exporter-0.18.1.linux-amd64.tar.gz

配置system啓動

mv node_exporter-0.18.1.linux-amd64 /usr/local/node_exporter
ln -s /usr/local/node_exporter/node_exporter /usr/local/bin/node_exporter

編輯/usr/lib/systemd/system/node_exporter.service，配置以下：

[Unit]
Description=Prometheus node_exporter
Wants=network-online.target
After=network-online.target

[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter --log.level=error
ExecStop=/usr/bin/killall node_exporter
MemoryLimit=300M #限制內存使用最多300M
CPUQuota=100% #限制CPU使用最多一個核

[Install]
WantedBy=default.target

# 如今從新加載systemd系統。
systemctl daemon-reload
# 而後啓動node_exporter服務並使其在系統啓動時每次啓動。
systemctl start node_exporter
systemctl enable node_exporter

啓動成功後，能夠看到如下輸出：

INFO[0000] Listening on :9100 source="node_exporter.go:170"

訪問http://localhost:9100/能夠看到如下頁面：

2. 熟悉Node Exporter監控指標

訪問http://localhost:9100/metrics，能夠看到當前node exporter獲取到的當前主機的全部監控數據，如 下所示：
每個監控指標以前都會有一段相似於以下形式的信息：

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 4.13190739e+06
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
 node_load1 0.0103125

變動：0.15版本node_cpu在0.18版本中變動命名爲node_cpu_seconds_total

其中HELP用於解釋當前指標的含義，TYPE則說明當前指標的數據類型。在上面的例子中node_cpu的註釋代表當前指 標是cpu0上idle進程佔用CPU的總時間，CPU佔用時間是一個只增不減的度量指標，從類型中也能夠看出node_cpu 的數據類型是計數器(counter)，與該指標的實際含義一致。又例如node_load1該指標反映了當前主機在最近一分 鍾之內的負載狀況，系統的負載狀況會隨系統資源的使用而變化，所以node_load1反映的是當前狀態，數據可能增 加也可能減小，從註釋中能夠看出當前指標類型爲儀表盤(gauge)，與指標反映的實際含義一致。

除了這些之外，在當前頁面中根據物理主機系統的不一樣，你還可能看到以下監控指標：

• node_boot_time：系統啓動時間
• node_cpu：系統CPU使用量
• nodedisk*：磁盤IO
• nodefilesystem*：文件系統用量
• node_load1：系統負載
• nodememeory*：內存使用量
• nodenetwork*：網絡帶寬
• node_time：當前系統時間
• go_*：node exporter中go相關指標
• process_*：node exporter自身進程相關運行指標

3. 從Node Exporter收集監控數據

爲了可以讓Prometheus Server可以從當前node exporter獲取到監控數據，這裏須要修改Prometheus配置文 件。編輯prometheus.yml並在scrape_configs節點下添加如下內容:

scrape_configs:
  - job_name: 'prometheus_97'
    static_configs:
      - targets: ['localhost:9090']
  # 採集node_exporter監控數據
  - job_name: 'node_97'
    static_configs:
      - targets: ['localhost:9100']

從新啓動Prometheus Server

訪問http://localhost:9090，進入到Prometheus Server。若是輸入"up"而且點擊執行按鈕之後，而且Prometheus可以正常從node_exporter獲取數據，則會看到如下結果：

up{instance="localhost:9090",job="prometheus"} 1
up{instance="localhost:9100",job="node"} 1

其中「1」表示正常，反之「0」則爲異常。

---

3、使用PromQL查詢監控數據

Prometheus UI是Prometheus內置的一個可視化管理界面，經過Prometheus UI用戶可以輕鬆的瞭解 Prometheus當前的配置，監控任務運行狀態等。 經過 Graph 面板，用戶還能直接使用 PromQL 實時查詢監控數據。

切換到 Graph 面板，用戶可使用PromQL表達式查詢特定監控指標的監控數據。以下所示，查詢主機負載變化情 況，可使用關鍵字 node_load1 能夠查詢出Prometheus採集到的主機負載的樣本數據，這些樣本數據按照時間先 後順序展現，造成了主機負載隨時間變化的趨勢圖表：

PromQL是Prometheus自定義的一套強大的數據查詢語言，除了使用監控指標做爲查詢關鍵字覺得，還內置了大量的 函數，幫助用戶進一步對時序數據進行處理。例如使用 rate() 函數，能夠計算在單位時間內樣本數據的變化狀況即 增加率，所以經過該函數咱們能夠近似的經過CPU使用時間計算CPU的利用率：

// before v0.15
rate(node_cpu[2m])
// after v0.18 
rate(node_cpu_seconds_total[2m])

這時若是要忽略是哪個CPU的，只須要使用without表達式，將標籤CPU去除後聚合數據便可：

avg without(cpu) (rate(node_cpu_seconds_total[2m]))

那若是須要計算系統CPU的整體使用率，經過排除系統閒置的CPU使用率便可得到:

經過PromQL咱們能夠很是方便的對數據進行查詢，過濾，以及聚合，計算等操做。經過這些豐富的表達書語句，監控 指標再也不是一個單獨存在的個體，而是一個個可以表達出正式業務含義的語言。

---

  [sleepy↓]