### 1.前言

#### 背景

衡量一個公司技術成熟與否的重要因素是一個公司的運維繫統的水準，運維繫統的核心便是監控與報警，諸多初創公司或傳統行業區別於成熟大廠的主要方面便是難以建立快速有效的監控與質量體系抑或是他們本身便不夠重視。今天我們要討論的便是一款優秀的監控報警框架。

#### Prometheus

Prometheus 是什麼？簡而言之，Prometheus 是一款基於 Google 內部 Borgmon 監控系統理念衍生出的一種非 Google 官方的開源的監控報警框架。

然而這款“非官方”的報警框架，在 2015 年正式加入 Cloud Native Computing Foundation（雲原生計算基金會），搖身一變成為一款炙手可熱的“生態級”監控框架，與 K8s，gRPC，Docker 結合，變成了實現“堅持和整合開源技術來編排容器作為微服務架構”這一願景不可或缺的一環。

Prometheus 有什麼區別於其他基於 TSDB（時序資料庫）的監控產品之處呢？選擇 Prometheus 的原因又是什麼？

經過幾天的搭建調研，筆者總結出以下幾點：

* 靈活而強大的查詢語句（PromQL）：在同一個查詢語句，可以對多個 Metrics 進行乘法、加法、連線、取分數位等操作
* 易於管理： Prometheus Server 是一個單獨的二進位制檔案，可直接在本地工作，不依賴於分散式儲存
* 高效：平均每個取樣點僅佔 3.5 bytes，且一個 Prometheus Server 可以處理數百萬的 Metrics
* 使用 pull 模式採集時間序列資料，程式碼侵入低
* 低成本實現高配置化 Metics 配置（Push Gateway），這是我認為最為主要的一點，Metics 的個性化推送有相應的 SDK，支援 Golang、Java、Python 等語言
* 低成本部署，第一次搭建完成 Prometheus 之後，我們會發現，原來部署是如此的 easy，所有的元件都是一個二進位制檔案，並且原生支援 Docker 容器化部署，易於擴充套件

其餘優點或不足，需各位在使用之餘慢慢發現了。

附官網：https://prometheus.io/

無需贅言，我們現在開始從 0 搭建一套 Prometheus 系統，為大家演示一下其用法與接入流程。

### 2. Prometheus 工作流程

引用官方一張圖

![](http://img.blog.itpub.net/blog/2019/01/11/4644ec1c95b477ad.png?x-oss-process=style/bb)

簡單來說，其工作流程與所有監控系統類似：收集的 Client->處理的 Sever->報警系統/ UI 展示系統。

#### Client

其中收集的 Client 可以分為兩大類：

* PushGateway
* 其他的 Exporter

為何如此區分，PushGateway 可以理解為一個通用的 Metics 接收的 Sever，其不止承擔由 Sever 端 pull 各種 Metics 的作用，同樣可以接收由各種渠道（指令碼，業務系統）傳送來的 point，這種場景非常適合於進行業務監控。PushGateway 的用法筆者將在下文詳述。

而其他的 Exporter 是指 Prometheus 官方推出的各種Exporter，例如，節點硬體監控（CPU，記憶體等）-node_exporter，MySQL 監控 -MySQL Server Exporter 等等，或是由一些第三方推出的監控客戶端等。具體的 Exporter 種類可見：https://prometheus.io/docs/instrumenting/exporters/

#### Sever

Prometheus 的 Sever 本質上只有一個二進位制檔案，部署十分方便，同時由一個 yml 配置檔案來管控 Sever 的所有行為，Prometheus 的 Sever 需要從各個 Client 拉取 Metics，這個過程支援服務發現，同時把拉取到的點錄入時序資料庫，並輸出一個 API 以供查詢和 UI 展示

#### 報警/UI

Prometheus 官方推出的報警系統名為 AlertManager，這個模組不做具體的報警規則的配置和錄入，只是實現從 Sever 端接收到 alert 之後將報警資訊透過配置的報警手段和聚合策略，將報警資訊聚合之後傳送，支援電郵、Webhook 等手段。具體的報警的閾值與規則的錄入仍在 Sever 端的配置檔案中。

Prometheus 的 Sever 在啟動時會自帶一個 Bootstrap 風格的 UI 用於展現，但此 UI 可謂相當醜陋，難用，只能支援基本功能，而 Prometheus 支援將資料錄入 Grafana，這真是極好的。

### 3. Prometheus 的部署與演示驗證

#### 1. 硬體準備

為了更貼近於生產環境與多節點等環境，筆者沒有選擇在 macOS 系統下操作而是在[滴滴雲](https://blog.didiyun.com)上選取了兩臺按時長計費的雲伺服器進行驗證。

配置為：

* Centos-7.4 4C8G 40G-HDD雲盤 1M頻寬 IP地址：116.85.10.244  用於搭建 Sever 端
* Centos-7.4 4C8G 40G-HDD雲盤 1M頻寬 IP地址：116.85.10.243  用於搭建 Exporter 與模擬業務服務

#### 2. 初級實戰

事實上，僅搭建一個 Sever 端，即可跑通整個 Prometheus 的流程，因為 Sever 預設會從本機收取 Sever 自我本身執行的狀態，自監控，同時 Sever 端會預設提供一個 UI。

那麼，初級實戰，便是先搭起一個 Sever。

Prometheus 官方提供了很多種部署的方法。比較常用的有三種：

* 直接下載 tar 包、解壓縮、執行、開箱即用

> mkdir test-for-prometheus

> cd test-for-prometheus

> wget https://github.com/prometheus/prometheus/releases/download/v2.6.0-rc.0/prometheus-2.6.0-rc.0.linux-amd64.tar.gz

> tar xf prometheus-2.6.0-rc.0.linux-amd64.tar.gz

> cd prometheus-2.6.0-rc.0.linux-amd64

> ./prometheus  --config.file=prometheus.yml

* 下載原始碼，編譯後執行（適用於想擼原始碼的人）

> yum clean all

> \#需求 1.5 版本以上的 Go

> yum install -y go

> mkdir -p \$GOPATH/src/github.com/prometheus

> cd $GOPATH/src/github.com/prometheus

> git clone https://github.com/prometheus/prometheus.git

> cd prometheus

> make build

> ./prometheus --config.file=prometheus.yml

* 拉取 Docker 映象，使用容器的方式啟動，Docker 倉庫為：https://hub.docker.com/r/prom/

> yum clean all

> \#對 Docker 版本無硬性要求，滴滴雲的 yum 源預設裝 1.13 的，這個版本不算新，但注意測試的時候的 Docker 版本需要和線上一致

> yum install -y docker

> service docker start

> docker pull prom/prometheus

> docker docker run -d -p 9090:9090 --name prometheus prom/prometheus

無論採用哪種方法，很容易便可以將一個簡易的 Sever 搭建成功，並採用系統預設的配置項。

系統預設的配置檔案如下：

#全域性配置
	global:
	  scrape_interval:     15s #預設抓取間隔, 15秒向目標抓取一次資料。
	  evaluation_interval: 15s #Evaluate rules every 15 seconds. The default is every 1 minute.
	  #scrape_timeout is set to the global default (10s).

#這個標籤是在本機上每一條時間序列上都會預設產生的，主要可以用於聯合查詢、遠端儲存、Alertmanger時使用。
	  external_labels:
		monitor: 'codelab-monitor'

#Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
	  rule_files:
	  # - "first.rules"
	  # - "second.rules"

# 這裡就表示抓取物件的配置
	# 這裡是抓去promethues自身的配置
	scrape_configs:
	#job name 這個配置是表示在這個配置內的時間序例。
	  - job_name: 'prometheus'
	    #metrics_path defaults to '/metrics'
	    #scheme defaults to 'http'.
	    #重寫了全域性抓取間隔時間，由15秒重寫成5秒。
	    scrape_interval: 5s
	    static_configs:
	      - targets: ['localhost:9090']
	
注意：縮排必須合規(下層比上層縮排2個空格)

配置檔案分為兩大塊，global 與 scrape_configs 具體的註釋在上文也有解釋，讀者可詳細閱讀理解。

預設的配置檔案中有針對 Prometheus 程式本身的監控收集配置，預設收集地址是 localhost:9090，事實上，預設 UI 的訪問地址亦是如此，我們嘗試使用地址訪問預設 UI。

![](http://img.blog.itpub.net/blog/2019/01/11/b8d22e1cb4c77656.png?x-oss-process=style/bb)

預設 UI 已開啟，選取下拉框可以看到：

![](http://img.blog.itpub.net/blog/2019/01/11/1629ef0e2a5c2ea9.png?x-oss-process=style/bb)

已經有自身程式監控的相關資訊可以查詢了。

#### 3. 中級實戰

當然，只搭建一個 Sever 是毫無意義的，沒有任何有價值的資訊產出，我們需要一些有價值的監控資訊，上文提到 Prometheus 官方提供有很多不同型別的 Exporter，筆者選取最簡單的 node_exporter 進行部署，使其能夠產生資料，並能夠被 Sever 收集。

node_exporter 的部署與 Sever 部署步驟相仿，仍然是上述三大方法，此處略去。

筆者選用直接開箱方式部署（部署機器 116.85.10.243）：
> wget https://github.com/prometheus/node_exporter/releases/download/v0.14.0/node_exporter-0.14.0.linux-amd64.tar.gz

> tar -xvzf node_exporter-0.14.0.linux-amd64.tar.gz

> cd node_exporter-0.14.0.linux-amd64

> ./node_exporter &

好了，一個簡單的 node_exporter 部署成功，預設的拉取埠為 9100，我們測試一下，手動執行:
		
		curl http://localhost:9100/metrics

得到一長串類似於“node_vmstat_nr_mlock 0”的結果，代表我們已經部署成功。

接下來需要修改 Sever 的配置檔案：
	
	#全域性配置
	global:
	  scrape_interval:     15s #預設抓取間隔, 15秒向目標抓取一次資料。
	  evaluation_interval: 15s #Evaluate rules every 15 seconds. The default is every 1 minute.
	  #scrape_timeout is set to the global default (10s).

#這個標籤是在本機上每一條時間序列上都會預設產生的，主要可以用於聯合查詢、遠端儲存、Alertmanger時使用。
	  external_labels:
		monitor: 'codelab-monitor'

#Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
	  rule_files:
	  # - "first.rules"
	  # - "second.rules"

# 這裡就表示抓取物件的配置
	# 這裡是抓去promethues自身的配置
	scrape_configs:
	#job name 這個配置是表示在這個配置內的時間序例。
	  - job_name: 'prometheus'
	    #metrics_path defaults to '/metrics'
	    #scheme defaults to 'http'.
	    #重寫了全域性抓取間隔時間，由15秒重寫成5秒。
	    scrape_interval: 5s
	    static_configs:
	      - targets: ['localhost:9090']
	      
	    #下列新增
	  - job_name: 'node'  # 一定要全域性唯一, 採集對應節點的 metrics，需要在對應節點安裝 node_exporter
	    scrape_interval: 10s
	    static_configs:
	      - targets: ['116.85.10.243:9100']  #需採集node 的 endpoint，我的收集節點在另外一個機器上

OK，修改完畢之後將程式殺掉或者替換 Docker 目錄 `/etc/prometheus` 下的配置檔案，筆者的方法是直接掛載目錄，`docker run ` 的命令變為：
	
	docker run -d -p 9090:9090 -v /root/test-for-prometheus:/etc/prometheus --name prometheus prom/prometheus

其中 `/root/test-for-prometheus` 為筆者存放配置檔案的位置。

這裡有一個讓我困惑不解的地方在於，如果未接入服務發現，每接入一個類似的監控，都需要更改配置檔案並重啟服務，至少目前筆者未發現更好方式。

重啟服務後，重新訪問 UI。在 status-target 下會發現多出了一個 Node 的節點，則代表部署成功。

![](http://img.blog.itpub.net/blog/2019/01/11/1d933506097c6d5e.png?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/2019/01/11/f4bfdf49f254912f.png?x-oss-process=style/bb)

同時在 Graph 頁面下拉框中多出了很多關於 Node 的監控項，並在選取後可以看到相應的取值。

![](http://img.blog.itpub.net/blog/2019/01/11/27272811dac6a22b.png?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/2019/01/11/91c2a0440edc9f1c.png?x-oss-process=style/bb)

#### 4. 進階實戰

一個成熟的監控系統自然是不滿足於只監控機器的狀態和 HTTP 碼等硬性指標的，要想監控業務指標，我們還需要一個神奇的元件 -- PushGateway。

上文有提到過，PushGateway 用於接收業務自定義的 Metics 打點，並而且 Prometheus 已經提供了針對於各種語言的 SDK，那我們來實驗一下。

首先，需要將 PushGateway 服務打起來，與上述兩個服務的搭建相仿，這次筆者採用的是 Docker 部署形式，由於 PushGateway 明顯帶有 Sever 的一些特質，所以筆者將其部署在 Sever 機器（116.85.10.244）上。
	
	docker pull prom/pushgateway
	docker run -p 9091:9091 prom/pushgateway
	docker ps
	
成功啟動 PushGateway。同樣的，更改 Sever 端的配置檔案，在檔案底部加上如下配置：
	
	- job_name: 'gateway'
    scrape_interval: 10s
    static_configs:
      - targets: ['116.85.10.244:9091']

重啟服務後，重新訪問 UI，發現 targets 內多出了一個收集項：

![](http://img.blog.itpub.net/blog/2019/01/11/443227037296aa0f.png?x-oss-process=style/bb)

Gateway 搭建成功。

接下來要做的是向 Gateway 中推送資料。因筆者使用的是 Go 語言，所以便打算用 Go 語言實現了一個簡單的 Sever。PushGateway 所有語言的 SDK 在https://prometheus.io/docs/instrumenting/pushing/ 可以找到。

首先做好先期準備：
	
	go get github.com/prometheus/client_golang/prometheus

這是 Prometheus 的 Golang Client 倉庫，內含資訊十分龐大，有完整的 API 文件，在此不再細說。

然後需要搭建一個簡單業務，並嵌入 SDK，筆者採用了 Martini 框架搭建一個簡單的 Web 服務，讀者完全可以採用自己的方式，這裡主要詳述 PushGateway 的 SDK 使用方法，程式碼如下：
	
	package main

import (
	"fmt"
	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/push"
	)

func main() {

//構建一個業務介面
		r := Custom()
		r.Post("/prometheus/collect", postPrometheusData)
		r.m.RunOnAddr(":9001")

}
	func postPrometheusData() {
		completionTime := prometheus.NewGauge(prometheus.GaugeOpts{
			Name: "db_backup_last_completion_timestamp_seconds",
			Help: "The timestamp of the last successful completion of a DB backup.",
		})
		completionTime.SetToCurrentTime()
		err := push.New("http://116.85.10.244:9091", "db_backup").
		Collector(completionTime).Grouping("db", "customers").Push()
		fmt.Println(err)
	}

注意這裡用到了

> github.com/prometheus/client_golang/prometheus

> github.com/prometheus/client_golang/prometheus/push

這兩個包，前者是定義各種 Prometheus 資料型別的基礎包，後者是專門用於推送的包，Prometheus 還提供 Promhttp 包，可直接基於此對外提供 HTTP 服務，個人覺得適用性不高所以未做嘗試，讀者感興趣可詳細閱讀https://godoc.org/github.com/prometheus/client_golang/prometheus 中的各種用法。

執行 build&run，執行我們的業務服務並測試呼叫：
	
	curl -X POST 116.85.10.243:9001/prometheus/collect

發現介面無恙，同時觀察監控 UI，發現在下拉框中多出了一個名為 `db_backup_last_completion_timestamp_seconds` 的監控項：

![](http://img.blog.itpub.net/blog/2019/01/11/61d83488086ef562.png?x-oss-process=style/bb)

並且點開圖表之後顯示出值即是我們寫入的值：

![](http://img.blog.itpub.net/blog/2019/01/11/fe5698a7d1f25b9a.png?x-oss-process=style/bb)

自此，大功告成，一個簡易的業務+硬核監控已經搭建成功。

### 後記

透過搭建 Prometheus 的整個流程，筆者有一個非常深切的感受，搭建成本真的是非常的低。Prometheus 深度擁抱 Docker 與極簡配置主義，對硬體差異適應性非常之好，有一定基礎之人，花費半天至一天的時間，便可以從零搭建成功，很適合一些初創公司和快速上線的專案，是一個值得深入研究的優秀開源專案。

下次筆者會和大家分享 Prometheus 接入服務發現、Grafana、PromQL 與其報警系統 AlertManager 的故事，我們下次不見不散。

雲伺服器搭建 Prometheus 與實戰（上）

相關文章