一文學會 Prometheus：開源系統監視和警報工具包

作者 | 阿文，責編 | 郭芮

頭圖 | CSDN 下載自東方IC

出品 | CSDN（ID：CSDNnews）

Prometheus是最初在SoundCloud上構建的開源系統監視和警報工具包 。自2012年成立以來，許多公司和組織都採用了Prometheus，這個項目發展到今天，已經全面接管了 Kubernetes 項目的整套監控體系。

Prometheus 項目與 Kubernetes 項目一樣，也來自於 Google 的 Borg 體系，它的原型系統，叫作 BorgMon，是一個幾乎與 Borg 同時誕生的內部監控系統。

Prometheus 優勢

Prometheus非常適合記錄任何純數字時間序列。它既適合以機器為中心的監視，也適合監視高度動態的面向服務的體系結構。在微服務世界中，它對多維數據收集和查詢的支持是一種特別的優勢。

Prometheus的設計旨在提高可靠性，使其成為中斷期間要使用的系統，從而使您能夠快速診斷問題。每個Prometheus服務器都是獨立的，而不依賴於網絡存儲或其他遠程服務。當基礎結構的其他部分損壞時，您可以依靠它，而無需建立廣泛的基礎結構來使用它。

Prometheus 不適合哪些場景？

普羅米修斯重視可靠性。即使在故障情況下，也始終可以查看有關係統的可用統計信息。但是如果您需要100％的準確性（例如按請求計費），則Prometheus並不是一個很好的選擇，因為所收集的數據可能不會足夠詳細和完整。在這種情況下，最好使用其他系統來收集和分析計費數據，並使用Prometheus進行其餘的監視。

Prometheus 架構

下圖是 Prometheus 和它的組件的整體架構：

從圖中可看到包含以下主要組件：

• Prometheus Server: 用於收集和存儲時間序列數據。Prometheus Server是Prometheus組件中的核心部分，負責實現對監控數據的獲取，存儲以及查詢。Prometheus Server可以通過靜態配置管理監控目標，也可以配合使用Service Discovery的方式動態管理監控目標，並從這些監控目標中獲取數據。其次Prometheus Server需要對採集到的監控數據進行存儲，Prometheus Server本身就是一個時序數據庫，將採集到的監控數據按照時間序列的方式存儲在本地磁盤當中。最後Prometheus Server對外提供了自定義的PromQL語言，實現對數據的查詢以及分析。

• Client Library: 客戶端庫，為需要監控的服務生成相應的 metrics 並暴露給 Prometheus server。當 Prometheus server 來 pull 時，直接返回實時狀態的 metrics。

• Push Gateway: 主要用於短期的 jobs。由於這類 jobs 存在時間較短，可能在 Prometheus 來 pull 之前就消失了。為此，這些 jobs 可以直接向 Prometheus server 端推送它們的 metrics。

• Exporters: 用於暴露已有的第三方服務的 metrics 給 Prometheus。Exporter將監控數據採集的端點通過HTTP服務的形式暴露給Prometheus Server，Prometheus Server通過訪問該Exporter提供的Endpoint端點，即可獲取到需要採集的監控數據。

• Alertmanager: 從 Prometheus server 端接收到 alerts 後，會進行去除重複數據，分組，並路由到對方的接受方式，發出報警。常見的接收方式有：電子郵件，pagerduty 等。

• WEB UI：Prometheus Server內置的Express Browser UI，通過這個UI可以直接通過PromQL實現數據的查詢以及可視化。一些其他的工具。

特點

Prometheus的主要特點是：

• 多維數據模型（有metric名稱和鍵值對確定的時間序列）

• 靈活的查詢語言

• 不依賴分佈式存儲

• 通過pull方式採集時間序列，通過http協議傳輸

• 支持通過中介網關的push時間序列的方式

• 監控數據通過服務或者靜態配置來發現

• 支持圖表和dashboard等多種方式

Prometheus包含多個組件，其中有許多是可選的，例如：

• Prometheus主服務器，用來收集和存儲時間序列數據

• 應用程序client代碼庫

• 短時jobs的push gateway

• 基於Rails/SQL的GUI dashboard

• 特殊用途的exporter（包括HAProxy、StatsD、Ganglia等）

• 用於報警的alertmanager

• 命令行工具查詢

• 大多數的組件都是用Go來完成的，使得它們方便構建和部署。

下載運行

直接去GitHub 下載最新的版本：

• 官網網站 https://prometheus.io/

下載後解壓並進入到目錄，執行：

[root@k8s prometheus-2.15.0.linux-amd64]# ls
console_libraries consoles data LICENSE NOTICE prometheus prometheus.yml promtool tsdb
[root@k8s prometheus-2.15.0.linux-amd64]# ./prometheus

啟動後程序會輸出一些日誌，默認監聽的端口是9090，使用的是prometheus目錄下的prometheus.yaml 配置文件，程序啟動時首選會啟動prometheus，然後啟動TSDB(時序數據庫)：

level=info ts=2019-12-24T06:34:56.601Z caller=main.go:294 msg="no time or size retention was set so using the default time retention" duration=15d
level=info ts=2019-12-24T06:34:56.601Z caller=main.go:330 msg="Starting Prometheus" version="(version=2.15.0, branch=HEAD, revision=ec1868b0267d13cb5967286fd5ec6afff507905b)"
level=info ts=2019-12-24T06:34:56.601Z caller=main.go:331 build_context="(go=go1.13.5, user=root@240f2f89177f, date=20191223-12:03:32)"
level=info ts=2019-12-24T06:34:56.601Z caller=main.go:332 host_details="(Linux 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 k8s (none))"
level=info ts=2019-12-24T06:34:56.601Z caller=main.go:333 fd_limits="(soft=1024, hard=4096)"
level=info ts=2019-12-24T06:34:56.602Z caller=main.go:334 vm_limits="(soft=unlimited, hard=unlimited)"
level=info ts=2019-12-24T06:34:56.604Z caller=main.go:648 msg="Starting TSDB ..."
level=info ts=2019-12-24T06:34:56.604Z caller=web.go:506 component=web msg="Start listening for connections" address=0.0.0.0:9090
level=info ts=2019-12-24T06:34:56.607Z caller=head.go:584 component=tsdb msg="replaying WAL, this may take awhile"
level=info ts=2019-12-24T06:34:56.612Z caller=head.go:632 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=2
level=info ts=2019-12-24T06:34:56.616Z caller=head.go:632 component=tsdb msg="WAL segment loaded" segment=1 maxSegment=2
level=info ts=2019-12-24T06:34:56.617Z caller=head.go:632 component=tsdb msg="WAL segment loaded" segment=2 maxSegment=2
level=info ts=2019-12-24T06:34:56.618Z caller=main.go:663 fs_type=EXT4_SUPER_MAGIC
level=info ts=2019-12-24T06:34:56.618Z caller=main.go:664 msg="TSDB started"
level=info ts=2019-12-24T06:34:56.619Z caller=main.go:734 msg="Loading configuration file" filename=prometheus.yml
level=info ts=2019-12-24T06:34:56.620Z caller=main.go:762 msg="Completed loading of configuration file" filename=prometheus.yml
level=info ts=2019-12-24T06:34:56.620Z caller=main.go:617 msg="Server is ready to receive web requests."

此時通過瀏覽器訪問，可以看到如下界面，這就是prometheus 的控制檯：

配置文件

prometheus.yml 是prometheus 的配置文件，你可以使用如下命令來指定配置文件啟動 prometheus：

prometheus --config.file=prometheus.yml

它的默認配置如下：

# cat prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

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

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus'

# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.

static_configs:
- targets: ['localhost:9090']

包括了：

• global 全局配置

• alerting 用來接收prometheus發出的告警，然後按照配置文件的要求，將告警用對應的方式發送出去。

• rule_files 指定加載的告警規則文件

• scrape_configs 指定prometheus要監控的目標

其中global是一些常規的全局配置，這裡只列出了兩個參數：

• scrape_interval: 15s #每15s採集一次數據

• evaluation_interval: 15s #每15s做一次告警檢測

scrape_configs指定prometheus要監控的目標，在scrape_config 中每個監控目標是一個 job，但job的類型有很多種。可以是最簡單的static_config，即靜態地指定每一個目標，例如上面的：

- job_name: prometheus
static_configs:
- targets: ['localhost:9090']
 

默認的配置文件scrape_configs 定義了一個job 對 prometheus 自身進行監控。你可以訪問ip:9090/metrics 來訪問 prometheus 自身的監控數據：

我們用瀏覽器訪問<code>http://host:9090/metrics/<code>，即可看到一個instance向外暴露的監控指標。除了註釋外，其它每一行都是一個監控指標項，大部分指標形如：

go_info{version="go1.10.3"} 1

這裡<code>go_info/<code>即為度量指標名稱，<code>version/<code>為這個度量指標的標籤，<code>go1.10.3/<code>為這個度量指標version標籤的值，<code>1/<code>為這個度量指標當前採樣的值，一個度量指標的標籤可以有0個或多個標籤。這就是上面說到的監控指標數據模型。

可以看到有些度量指標的形式如下：

go_memstats_frees_total 131961

按prometheus官方建議的規範，以<code>_total/<code>為後綴的度量指標一般類型是counter計數器類型。

有些度量指標的形式如下：

go_memstats_gc_sys_bytes 213408

這種度量指標一般類型是gauge測量器類型。

有些度量指標的形式如下：

prometheus_http_response_size_bytes_bucket{handler="/metrics",le="100"} 0prometheus_http_response_size_bytes_bucket{handler="/metrics",le="1000"} 0prometheus_http_response_size_bytes_bucket{handler="/metrics",le="10000"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="100000"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="1e+06"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="1e+07"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="1e+08"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="1e+09"} 46prometheus_http_response_size_bytes_bucket{handler="/metrics",le="+Inf"} 46prometheus_http_response_size_bytes_sum{handler="/metrics"} 234233prometheus_http_response_size_bytes_count{handler="/metrics"} 46

這種就是histogram柱狀圖類型。

還有的形式如下：

go_gc_duration_seconds{quantile="0"} 7.3318e-05go_gc_duration_seconds{quantile="0.25"} 0.000118693go_gc_duration_seconds{quantile="0.5"} 0.000236845go_gc_duration_seconds{quantile="0.75"} 0.000337872go_gc_duration_seconds{quantile="1"} 0.000707002go_gc_duration_seconds_sum 0.003731953go_gc_duration_seconds_count 14

這種就是summary總結類型。

更多關於配置相關的說明，可以閱讀官網文檔：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus 的一些概念

Jobs和Instances(任務和實例)

就Prometheus而言，pull拉取採樣點的端點服務稱之為instance。多個這樣pull拉取採樣點的instance, 則構成了一個job。

例如, 一個被稱作api-server的任務有四個相同的實例。

job: api-server instance 1：1.2.3.4:5670 instance 2：1.2.3.4:5671 instance 3：5.6.7.8:5670 instance 4：5.6.7.8:5671

自動化生成的標籤和時間序列

當Prometheus拉取一個目標, 會自動地把兩個標籤添加到度量名稱的標籤列表中，分別是：

• job: 目標所屬的配置任務名稱api-server。

• instance: 採樣點所在服務: host:port 如果以上兩個標籤二者之一存在於採樣點中，這個取決於honor_labels配置選項。

對於每個採樣點所在服務instance，Prometheus都會存儲以下的度量指標採樣點：

• up{job=”[job-name]", instance="instance-id”}: up值=1，表示採樣點所在服務健康; 否則，網絡不通, 或者服務掛掉了

• scrape_duration_seconds{job=”[job-name]", instance=”[instance-id]"}: 嘗試獲取目前採樣點的時間開銷

• scrape_samples_scraped{job=”[job-name]", instance=”[instance-id]"}: 這個採樣點目標暴露的樣本點數量

up度量指標對服務健康的監控是非常有用的。數據模型

Prometheus從根本上存儲的所有數據都是時間序列: 具有時間戳的數據流只屬於單個度量指標和該度量指標下的多個標籤維度。除了存儲時間序列數據外，Prometheus也可以利用查詢表達式存儲5分鐘的返回結果中的時間序列數據

metrics和labels(度量指標名稱和標籤)

每一個時間序列數據由metric度量指標名稱和它的標籤labels鍵值對集合唯一確定。

這個metric度量指標名稱指定監控目標系統的測量特徵（如：<code>http_requests_total/<code>- 接收http請求的總計數）. metric度量指標命名ASCII字母、數字、下劃線和冒號，他必須配正則表達式<code>[a-zA-Z_:][a-zA-Z0-9_:]*/<code>。標籤開啟了Prometheus的多維數據模型：對於相同的度量名稱，通過不同標籤列表的結合, 會形成特定的度量維度實例。(例如：所有包含度量名稱為<code>/api/tracks/<code>的http請求，打上<code>method=POST/<code>的標籤，則形成了具體的http請求)。這個查詢語言在這些度量和標籤列表的基礎上進行過濾和聚合。改變任何度量上的任何標籤值，則會形成新的時間序列圖標籤label名稱可以包含ASCII字母、數字和下劃線。它們必須匹配正則表達式<code>[a-zA-Z_][a-zA-Z0-9_]*/<code>。帶有<code>_/<code>下劃線的標籤名稱被保留內部使用。

標籤labels值包含任意的Unicode碼。

有序的採樣值

有序的採樣值形成了實際的時間序列數據列表。每個採樣值包括：

• 一個64位的浮點值

• 一個精確到毫秒級的時間戳 一個樣本數據集是針對一個指定的時間序列在一定時間範圍的數據收集。

小結：指定度量名稱和度量指標下的相關標籤值，則確定了所關心的目標數據，隨著時間推移形成一個個點，在圖表上實時繪製動態變化的線條’’

Notation(符號)

表示一個度量指標和一組鍵值對標籤，需要使用以下符號：

[metric name]{[label name]=[label value], …}

例如，度量指標名稱是<code>api_http_requests_total/<code>， 標籤為<code>method="POST"/<code>,<code>handler="/messages"/<code>的示例如下所示：

api_http_requests_total{method="POST”, handler=”/messages”}

這些命名和OpenTSDB使用方法是一樣的。

metrics類型Prometheus 提供了四個核心的metrics類型。這四種類型目前僅在客戶庫和wire協議中區分。Prometheus服務還沒有充分利用這些類型。不久的將來就會發生改變。

Counter(計數器)

counter是一個累計度量指標，它是一個只能遞增的數值。計數器主要用於統計服務的請求數、任務完成數和錯誤出現的次數等等。計數器是一個遞增的值。反例：統計goroutines的數量。

Gauge(測量器)

gauge是一個度量指標，它表示一個既可以遞增, 又可以遞減的值。

測量器主要測量類似於溫度、當前內存使用量等，也可以統計當前服務運行隨時增加或者減少的Goroutines數量

Histogram(柱狀圖)

histogram，是柱狀圖，在Prometheus系統中的查詢語言中，有三種作用：

• 對每個採樣點進行統計，打到各個分類值中(bucket)

• 對每個採樣點值累計和(sum)

• 對採樣點的次數累計和(count)

度量指標名稱: <code>[basename]/<code>的柱狀圖, 上面三類的作用度量指標名稱：

• [basename]_bucket{le="上邊界”}, 這個值為小於等於上邊界的所有采樣點數量

• [basename]_sum

• [basename]_count

小結：所以如果定義一個度量類型為Histogram，則Prometheus系統會自動生成三個對應的指標。

使用histogram_quantile函數, 計算直方圖或者是直方圖聚合計算的分位數閾值。一個直方圖計算Apdex值也是合適的, 當在buckets上操作時，記住直方圖是累計的。

總結：類似histogram柱狀圖，summary是採樣點分位圖統計，(通常的使用場景：請求持續時間和響應大小)。它也有三種作用：

• 對於每個採樣點進行統計，並形成分位圖。（如：正態分佈一樣，統計低於60分不及格的同學比例，統計低於80分的同學比例，統計低於95分的同學比例）

• 統計班上所有同學的總成績(sum)

• 統計班上同學的考試總人數(count)

帶有度量指標的<code>[basename]/<code>的<code>summary/<code>在抓取時間序列數據展示。

• 觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示為<code>[basename]{分位數="[φ]"}/<code>

• <code>[basename]_sum/<code>， 是指所有觀察值的總和

• <code>[basename]_count/<code>, 是指已觀察到的事件計數值

自定義監控上報

系統自帶的 exporter

在prometheus的世界裡70%的場景並不需要專門寫埋點邏輯代碼，因為已經有現成的各類exporter了，只要找到合適的exporter，啟動exporter就直接暴露出一個符合prometheus規範的服務端點了。

exporter列表參見這裡（https://prometheus.io/docs/instrumenting/exporters/），另外官方git倉庫（https://github.com/prometheus）裡也有一些exporter。

舉例，在某個宿主機上運行node_exporter後，以Centos為例，安裝：

# curl -Lo /etc/yum.repos.d/_copr_ibotty-prometheus-exporters.repo https://copr.fedorainfracloud.org/coprs/ibotty/prometheus-exporters/repo/epel-7/ibotty-prometheus-exporters-epel-7.repo
# yum install node_exporter

然後執行：

node_exporter

如圖所示：

用瀏覽器訪問<code>http://${host_ip}:9100/metrics/<code>即可看到node_exporter暴露出的這個宿主機各類監控指標數據：

然後在prometheus的配置文件里加入以下一段：

scrape_configs:
......
- job_name: 'node_monitor_demo'
static_configs:
- targets: ['${host_ip}:9100']

然後在prometheus的web管理控制檯裡就可以查詢到相應的監控指標了。在<code>http://${HOST}:9090/graph/<code>界面裡輸入<code>go_memstats_alloc_bytes{instance="${host_ip}:9100"}/<code>點擊<code>Execute/<code>按鈕即可。

將 ${host_ip} 替換成你的IP

如圖：

在控制檯中，切換到Graph 可以看到對應的監控圖標，在圖標列中可以顯示對應job 的監控指標：

編寫自定義的監控代碼

假如你的監控指標很特殊，需要自己寫埋點上報邏輯代碼，也是比較簡單的。已經有各個語言的Client Libraries（https://prometheus.io/docs/instrumenting/clientlibs/）了，照著示例寫就可以了。

 
新勳章，新獎品，高流量，還有更多福利等你來拿
☞AI 換臉項目 ALAE 登頂 Github，AI 換臉又升級？
☞吊打面試官系列：你會「遞歸」麼？
☞蔣凡“罰酒三杯”，這些被價值觀幹掉的阿里人表示不服
☞用 Python 實現手機自動答題，這下百萬答題遊戲誰也玩不過我！ 
☞IDEA 驚天 bug：進程已結束，退出代碼 1073741819
☞當 DeFi 遇上 Rollup，將擦出怎樣的火花？