prometheus服務監控

注：文檔僅記錄在linux下進行的一系列操做；
安裝前準備：前端

安裝wget，用於下載文件，命令： yum install wget -y
安裝lrzsz，用於上傳文件資料，命令： yum install lrzsz -y
若是要跨機器訪問須要開啓端口號，在root用戶下使用命令（0000表示要開啓的端口號）： firewall-cmd --zone=public --add-port=0000/tcp --permanent 重啓防火牆： firewall-cmd --reload

Prometheus介紹：

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

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

Prometheus基於Pull模型的架構方式，能夠在任何地方（本地電腦，開發環境，測試環境）搭建咱們的監控系統。對於一些複雜的狀況，還可使用Prometheus服務發現(Service Discovery)的能力動態管理監控目標。
全部採集的監控數據均以指標(metric)的形式保存在內置的時間序列數據庫當中(TSDB)。全部的樣本除了基本的指標名稱之外，還包含一組用於描述該樣本特徵的標籤。linux

每一條時間序列由指標名稱(Metrics Name)以及一組標籤(Labels)惟一標識。每條時間序列按照時間的前後順序存儲一系列的樣本值。表示維度的標籤可能來源於你的監控對象的狀態，好比code=404或者content_path=/api/path。也可能來源於的你的環境定義，好比environment=produment。基於這些Labels咱們能夠方便地對監控數據進行聚合，過濾，裁剪。git

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

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

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

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

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

Prometheus生態結構：

Prometheus 生態結構圖以下所示： spring

prometheus 獲取服務數據的方式有兩種：pull和push兩種模式，默認支持pull模式，配置簡單，操做容易，配合一系列的Exporter能夠很容易獲取metircs接口數據，push模式須要pushgateway的支持，且須要本身實現一些操做，包括數據添加、更新、刪除操做的數據到prometheus的pushgateway中，官方對push模式這樣說的： sql

使用Pushgateway有幾個陷阱：

經過單個Pushgateway監控多個實例時，Pushgateway成爲單點故障和潛在瓶頸。
您經過up 指標（每次刮除時生成）丟失了Prometheus的自動實例運行情況監控。
Pushgateway永遠不會忘記推送到它的系列，並將永遠暴露給Prometheus，除非這些系列是經過Pushgateway的API手動刪除的。

Prometheus對比Zabbix：

Zabbix	Prometheus
後端用C開發，界面用PHP開發，定製化難度很高。	後端用golang開發，前端是Grafana，JSON編輯便可解決定製化難度較低
集羣規模上限爲 10000 個節點	支持更大的集羣規模，速度也更快
更適合監控物理機環境	更適合雲環境的監控，對OpenStack，Kubernetes有更好的集成
監控數據存儲在關係型數據庫內，如 MySQL，很難從現有數據中擴展維度	監控數據存儲在基於時間序列的數據庫內，便於對已有數據進行新的聚合
安裝簡單，zabbix-server 一個軟件包中包括了全部的服務端功能	安裝相對複雜，監控、告警和界面都分屬於不一樣的組件
圖形化界面比較成熟，界面上基本上能完成所有的配置操做	界面相對較弱，不少配置須要修改配置文件
發展時間更長，對於不少監控場景，都有現成的解決方案	2015 年後開始快速發展，但發展時間較短，成熟度不及Zabbix

Prometheus工做流程：

一、Prometheus Server 按期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 Push Gateway 發過來的 metrics，或者從其餘的 Prometheus Server 中拉 metrics。二、Prometheus Server 在本地存儲收集到的 metrics，並運行已定義好的預警規則，記錄新的時間序列或者向 Alertmanager 推送警報。三、Alertmanager 根據配置文件，對接收到的警報進行處理，發出告警。四、在圖形界面（Grafana）中，採集數據，將其可視化。

Prometheus客戶端庫主要提供四種主要的 metric 類型：

Counter(計數器)： - 說明：Counter是一個累積度量，它表示一個單調遞增的 Metrics，其值只能在重啓時遞增或重置爲零； - 場景：可使用Counter來表示http的請求數、已完成的任務數或錯誤數、下單數。
Gauge(測量儀)： - 說明：當前值的一次快照(snapshot)測量，可增可減。 - 場景：磁盤使用率，當前同時在線用戶數。
Histogram(直方圖)： - 說明：經過區間統計樣本分佈。 - 場景：請求延遲時間的統計。例如統計 0200ms、200ms400ms、400ms~800ms 區間的請求數有多。
Summary(彙總)： - 說明：根據樣本統計出百分位。 - 場景：請求延遲時間的統計。例如統計 95%的請求延遲 < xxx ms ，99%的請求延遲 < xxx ms。

Prometheus安裝：

下載prometheus文件，在Linux系統中，使用cd命令進入目標目錄下，例如：/usr/local/src/prometheus；下載連接爲：https://prometheus.io/download/ 如圖所示，下載紅色框中的文件：

解壓下載文件，使用tar -zxvf prometheus-*.tar.gz命令進行解壓縮。解壓後以下圖所示，紅色框中的爲執行文件：

![](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jZG4ubmxhcmsuY29tL3l1cXVlLzAvMjAxOS9wbmcvMTgyNTQwLzE1NjMyNDgwNjUwNDktMWU0MWFmMzYtNWQ0MS00MzYyLWFhNzAtZjc4MDVmODgyNTYzLnBuZw#align=left&display=inline&height=188&originHeight=146&originWidth=567&status=done&width=732)

進入到premotheus根目錄下，執行命令：sudo ./Prometheus 啓動服務（啓動prometheus須要/prometheus/data權限），能夠看到下圖所示信息即表示啓動成功；

![](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jZG4ubmxhcmsuY29tL3l1cXVlLzAvMjAxOS9wbmcvMTgyNTQwLzE1NjMyNDgwNjUxNDAtYjUxYzJhNzctZTdmMi00ODcxLThiNzAtMjdlMTE5MTgyOGNhLnBuZw#align=left&display=inline&height=248&originHeight=465&originWidth=1396&status=done&width=744)

另外後臺啓動服務使用命令：nohup ./prometheus > prometheus.log 2>&1 & 啓動以後，瀏覽器輸入http://192.168.xx.xx:9090 ，以下如所示：

在阿里雲的ESC部署的時候發現的問題及解決辦法：

按照上面的操做進行啓動的時候報錯，報錯信息以下： level=error ts=2019-07-23T02:03:30.555Z caller=main.go:731 err=「opening storage failed: lock DB directory: resource temporarily unavailable」 解決辦法：刪除解壓目錄下的 lock 文件
執行：rm -f [軟件的本地解壓目錄]/prometheus/data/lock
解決上面的問題後，啓動服務發現還有報錯，報錯信息以下：

level=error ts=2019-07-23T02:30:49.107Z caller=main.go:731 err=「error starting web server: listen tcp 0.0.0.0:9090: bind: address already in use」

解決辦法：查找佔用9090端口的應用的PID，而後強制關閉執行：sudo netstat -antup 查找到佔用9090端口的應用的PID 執行：kill -9 \[具體的pid\]

Prometheus配置介紹：

Prometheus配置只有一個prometheus.yml文件，其內容以下圖所示：

讀配置文件即其中的註釋能夠知道默認的配置有四個，global全局配置，alerting預警，rule_files規則文件，scrape_configs下載配置；

在scrage_configs下看到默認配置了prometheus本身的監控配置，job_name是一個配置標識， static_config下有一個targets，這個配置監控服務的地址+端口號，promehteus會經過這個配置的url和默認的路徑」/metrics」，去對應的服務上pull監控的各類數據到prometheus中進行存儲。

Prometheus數據存儲配置：

數據存儲：prometheus採用自定義的存儲格式將樣本數據保存在本地磁盤當中，默認數據存儲在prometheus根目錄下的/data文件夾中，如圖所示：

存儲說明：Prometheus 按照兩個小時爲一個時間窗口，將兩小時內產生的數據存儲在一個塊（Block）中。每一個塊都是一個單獨的目錄，裏面含該時間窗口內的全部樣本數據（chunks），元數據文件（meta.json）以及索引文件（index）。其中索引文件會將指標名稱和標籤索引到樣板數據的時間序列中。此期間若是經過 API 刪除時間序列，刪除記錄會保存在單獨的邏輯文件 tombstone 當中。

當前樣本數據所在的塊會被直接保存在內存中，不會持久化到磁盤中。爲了確保 Prometheus 發生崩潰或重啓時可以恢復數據，Prometheus 啓動時會經過預寫日誌（write-ahead-log(WAL)）從新記錄，從而恢復數據。預寫日誌文件保存在 wal 目錄中，每一個文件大小爲 128MB。

wal 文件包括尚未被壓縮的原始數據，因此比常規的塊文件大得多。通常狀況下，Prometheus 會保留三個 wal 文件，但若是有些高負載服務器須要保存兩個小時以上的原始數據，wal 文件的數量就會大於 3 個。

Prometheus保存塊數據的目錄結構以下所示：

Prometheus 的本地存儲沒法持久化數據，沒法靈活擴展。爲了保持簡單性，定義兩個標準接口（遠程寫remote_write，遠程讀remote_read），讓用戶能夠基於這兩個接口對接將數據保存到任意第三方的存儲服務中，這種方式在 Promthues 中稱爲 Remote Storage。

Prometheus遠程存儲配置：

Prometheus遠程存儲的方式有不少種，可是部分只支持寫，並不支持讀，Elasticsearch就是其中一個，可是咱們能夠經過中間工具能夠實現將數據存儲到Elasticsearch和從Elasticsearch中讀取數據。在prometheus官網是這樣介紹遠程讀寫的：

prometheus遠程讀寫數據到Elasticsearch，須要一個對應的adapter來實現，Prometheus-es-adapter 就是實現這個功能的。

Prometheus遠程讀寫到Elasticsearch：

Prometheus-es-adapter在github上能夠拉取源碼：https://github.com/pwillie/prometheus-es-adapter.git，這個adapter是Go語言開發的，全部編譯運行須要Go語言環境。Go語言環境搭建這裏再也不描述，只說明編譯和運行的步驟。這裏特殊說明一點，go的倉庫在國外，可能有些依賴下載不下來，須要配置GOPRAXY環境變量，說明以下：

修改配置文件，添加go module和goproxy的配置：在Go語言環境配置好以後，由於驗證時沒有在root用戶下操做，因此配置的GOPATH爲/home/xxx/go，若是是在root用戶下操做，安裝Go環境以後，默認的GOPATH是/root/go，cd到GOPATH目錄下，若是沒有src目錄則在這個目錄下建立一個src文件夾，而後將prometheus-es-adapter 克隆/下載到/src下，也就是/home/xxx/go/src/，或者/root/go/src下，cd到prometheus-es-adapter下，修改/cmd/adapter/main.go文件，默認配置的es信息以下圖所示：

而後執行make build命令進行編譯，編譯完成以後，在當前目錄下會生成一個prometheus-es-adapter的可執行文件，這個文件在當前目錄下的/release/linux/amd64/文件夾，啓動這個可執行文件。

若是是docker啓動服務則須要修改docker-compose.yml文件，配置elasticsearch路徑、版本等信息，示例以下所示，其中藍色框中的是本身註釋掉的，這個暫且不須要，紅色框的是要修改的：

遠程讀/寫的配置很簡單，在prometheus.yml中添加remote_write的配置項便可，這裏演示配置遠程寫到Elasticsearch，示例以下：

#遠程寫
remote_write:
  - url: http://192.168.xx.xx:8000/write
#遠程讀
remote_read:
  - url: http://192.168.xx.xx:8000/read

Prometheus監控配置：

Node_exporter服務器監控：

在Prometheus的架構設計中，Prometheus Server並不直接服務監控特定的目標，其主要任務負責數據的收集，存儲而且對外提供數據查詢支持。所以爲了可以可以監控到某些東西，如主機的CPU使用率，咱們須要使用到Exporter。Prometheus週期性的從Exporter暴露的HTTP服務地址（一般是/metrics）拉取監控樣本數據。

爲了可以採集到主機的運行指標如CPU, 內存，磁盤等信息。咱們可使用Node Exporter。Node Exporter一樣採用Golang編寫，而且不存在任何的第三方依賴，只須要下載，解壓便可運行。

下載node_exporter能夠從https://prometheus.io/download/ 獲取最新的node exporter版本的二進制包。在prometheus官網提供不少exporter，下載下圖紅框中的文件，放到要安裝的目錄下，例如：/usr/local/src目錄下；
解壓縮文件，使用tar -zxvf node_exporter-0.18.1.linux-amd64.tar.gz命令，解壓文件，包含一個可執行文件，下圖紅色框中的文件：
進入到node_exporter根目錄，輸入命令：./node_exporter，啓動服務，能夠看到下圖所示信息即表示啓動成功。

另外能夠後臺啓動服務使用命令：nohup ./node_exporter > node_exporter.log 2>&1 &，啓動成功後，訪問http://192.168.xx.xx:9100能夠看到：
點擊mertrics能夠看到服務監控信息：

Node_exporter配置到Prometheus:

node_exporter的端口是9100，打開prometheus的配置文件prometheus.yml，在scrape_configs下面添加以下內容，注意這個要跟默認的job_name: 'prometheus’同級配置；

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
	#node_exporter
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

配置好以後，須要重啓prometheus服務，重啓完成，再次訪問http://192.168.xx.xx:9090點擊菜單欄status下的targets能夠看到，node_exporter已經出現，並顯示狀態爲UP；由於只部署了一個node_exporter因此看到的是node_exporter（1/1 up）;

點擊Endpoint下的url（由於全部的服務都在同一機器上，因此這裏配置的是localhost）能夠看到服務器的監控信息，也就是點擊http://192.168.xx.xx:9100 下的metrics一樣的頁面和內容。

Mysqld_exporter數據庫監控：

Mysqld_exporter和Node_exporter相似，也是官網提供的監控插件，在官網能夠下載到。

經過瀏覽器訪問prometheus官網https://prometheus.io/download/ 獲取最新的mysqld_exporter版本的二進制包。下載下圖紅框中的文件，放到要安裝的目錄下，例如：/usr/local/src目錄下；
解壓縮文件，使用tar -zxvf mysqld_exporter-0.12.0.linux-amd64.tar.gz命令，解壓文件，包含一個可執行文件，下圖紅色框中的文件（其中mysqld_exporter.log是後臺啓動指定建立的日誌文件，自己不包含此文件）：
啓動可執行文件，使用命令：./mysqld_exporter 看到下圖所示信息：

注意紅色框中的信息提示當前用戶目錄root下沒有.my.cnf文件，mysqld_exporter監控數據庫信息，須要數據庫相關的配置，包括url、端口號、用戶名和密碼，若是這個配置須要配置在當前用戶目錄下的.my.cnf文件中；

命令cd到用戶目錄下，當前用戶是root 就cd /home/root，而後使用命令：vi .my.cnf這個若是有會打開，若是沒有這個文件，保存時會建立。使用ls -la 命令可查看.my.cnf文件是否存在，打開此文件，配置數據庫相關信息：

[client]host=192.168.xx.xx
port=3306
user=root
password=root

編輯好以後進行保存，而後從新啓動mysqld_exporter服務：

此時能夠看到錯誤信息中出現了數據庫相關信息，可是拒絕鏈接，這個是由於數據庫沒有啓動，去後臺啓動數據庫服務後便可，正常鏈接後以下圖所示：

訪問http://192.168.xx.xx:9104 查看相關信息：

Mysqld_exporter配置到Prometheus：

配置好mysqld_exporter以後，在prometheus的配置文件prometheus.yml中加入mysqld_exporter的配置，配置信息以下所示：

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
  #mysqld_exporter
  - job_name: 'mysqld_exporter'
    static_configs:
      - targets: ['localhost:9104']

而後重啓prometheus服務，訪問http://192.168.xx.xx:9090點擊菜單欄status下的targets能夠看到有關mysqld_exporter的信息，而且狀態是UP。

點擊鏈接，能夠看到數據庫監控信息，如圖所示：

Java服務監控：

在服務中加入maven依賴：

<!-- actuator -->
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- prometheus-->
<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

在配置文件中配置相關信息：

##=====actuator=====##
management:
  endpoints:
    web:
      exposure:
        include: health,info,env,metrics,Prometheus

這裏include也能夠配置成*，表示全部，配置好以後，啓動服務，訪問http://192.168.xx.xx:8762/actuator可看到相關監控信息：

Java服務配置到Prometheus：

服務啓動後打開prometheus配置文件prometheus.yml，在配置文件中加入服務監控的相關配置，這裏須要注意，和前面的配置相比，多了一個metrics_path的配置項，這裏配置的是/actuator/promehteus, 配置信息以下所示：

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
  #spring-boot 這裏命名爲spring-boot
  - job_name: 'spring-boot'
    metrics_path: '/actuator/prometheus'
    static_configs:
		- targets: ['192.168.xx.xx:8762']

metrics_path說明：

prometheus處理監控信息的格式是固定的以下圖所示：

prometheus默認的監控接口是/metrics，訪問http://192.168.xx.xx:8762/actuator/metrics 看到以下信息：

上圖中的數據格式prometheus是沒法處理的，因此不能在prometheus配置中使用默認的接口，訪問http://192.168.xx.xx:8762/actuator/prometheus能夠看到：

這個是prometheus能夠處理的，因此要配置metrics_path爲/actuator/prometheus的接口。配置完成後，訪問http://192.168.xx.xx:9090 點擊菜單欄status下的targets能夠看到有關spring_boot的信息，而且狀態是UP，若是沒有配置metrics_path，服務狀態則是DOWN。

Prometheus告警配置:

Prometheus 告警配置參考prometheus.yml配置文檔中的描述能夠知道，告警規則能夠是外部的YAML文件。在Prometheus中一條告警規則主要由如下幾部分組成：

告警名稱：用戶須要爲告警規則命名，固然對於命名而言，須要可以直接表達出該告警的主要內容；
告警規則：告警規則實際上主要由PromQL進行定義，其實際意義是當表達式（PromQL）查詢結果持續多長時間（During）後出發告警；

在Prometheus中，還能夠經過Group（告警組）對一組相關的告警進行統必定義。固然這些定義都是經過YAML文件來統一管理的。

Prometheus告警規則：

Prometheus告警規則是基於PromQL表達式定義的，示例以下：

groups:
- name: node_alert
  rules:

  # Alert for any instance that is unreachable for > 10 seconds.
  - alert: Instance Down
    expr: up == 0
    for: 10s
    annotations:
      summary: "Instance {
   { $labels.instance }} down"
      description: "{
   { $labels.instance }} of job {
   { $labels.job }} has been down."

在告警規則文件中，咱們能夠將一組相關的規則設置定義在一個group下。在每個group中咱們能夠定義多個告警規則(rule)。經過 labels.name 變量能夠訪問當前告警實例中指定標籤的值。$value則能夠獲取當前PromQL表達式計算的樣本值。一條告警規則主要由如下幾部分組成：

alert：告警規則的名稱。
expr：基於PromQL表達式告警觸發條件，用於計算是否有時間序列知足該條件。
for：評估等待時間，可選參數。用於表示只有當觸發條件持續一段時間後才發送告警。在等待期間新產生告警的狀態爲pending。
labels：自定義標籤，容許用戶指定要附加到告警上的一組附加標籤。
annotations：用於指定一組附加信息，好比用於描述告警詳細信息的文字等，annotations的內容在告警產生時會一同做爲參數發送到Alertmanager。

按照PromQl語法配置一個告警規則，定義alert_rules.yml文件，將示例中的語句複製到alert_rules.yml文件中，保存，而後在prometheus的配置文件中，規則配置項添加alert_rules.yml的文件路徑配置,完成以後使用命令：./promtool check rules ./ alert_rules.yml 檢查規則是否正確，簡稱正確，一切完成後重啓prometheus，訪問http://192.168.xx.xx:9090/rules 能夠看到配置的告警信息：

當告警規則觸發時，alerts的state會變成PENDING，若是後告警條件持續知足配置的時間，告警狀態爲FIRING

Alertmanager配置到Prometheus:

Prometheus能夠配置告警規則，並觸發告警配置，可是隻能在頁面看到狀態的變化，沒法發送告警通知，alertmanager結合prometheus能夠作到更多。

經過瀏覽器訪問prometheus官網https://prometheus.io/download/ 獲取最新的alertmanager。下載下圖紅框中的文件，放到要安裝的目錄下，例如：/usr/local/src目錄下；
執行解壓縮命令，解壓下載的alertmanager-0.18.0.linux-amd64.tar.gz文件，裏面包含alertmanager的可執行文件alertmanager，和配置文件alertmanager.yml
啓動alertmanager服務，默認端口爲9093，訪問http://192.168.xx.xx:9093 能夠看到相關的信息，點擊status查看配置信息：

打開alertmanager.yml文件，下載郵件通知模板，添加郵件配置信息，內容示例以下所示（模板下載：wget https://raw.githubusercontent.com/prometheus/alertmanager/master/template/default.tmpl）：

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.qq.com:587'
  smtp_from: '29029xxx2@qq.com'
  smtp_auth_username: '29029xxx2@qq.com'
  smtp_auth_password: 'sxxasd' #這裏須要得是客戶端受權登陸密碼，非帳號登陸密碼
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: team-X-mails
receivers:
  - name: 'team-X-mails'
    email_configs:
    - to: 'liwenqiang@tseveryday.com'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']
templates:
  - 'default.tmpl'

配置完成後重啓服務，刷新http://192.168.xx.xx:9093/status 能夠看到配置信息已經更新：

當告警規則觸發後，alertmanager會收到來自prometheus的告警信息，而且會發送告警通知（這裏配置的是郵件通知，因此會）：

Grafana安裝：

雖然prometheus能夠進行一些數據的查看，可是沒有隻能看到一堆的數據，分析起來複雜，且不直觀，grafana是一個可視化工具，能夠根據須要安裝各類功能分析和展現插件來直觀的展現數據信息；

安裝grafana的方式不少，參考：https://grafana.com/docs/installation/rpm/，爲了方便直接使用 yum 安裝:

sudo yum install https://dl.grafana.com/oss/release/grafana-5.4.2-1.x86_64.rpm

安裝完成後執行：sudo service grafana-server start啓動grafana服務，也能夠經過systemctl start grafana-server啓動（在使用此命令以前先執行一次systemctl daemon-reload），啓動以後查看狀態：systemctl status grafana-server；
Grafana默認端口號爲3000，啓動後訪問http://192.168.xx.xx:3000 ，可看到下圖畫面，默認的帳號密碼是admin/admin；

Grafana 配置數據源：

進入首頁，點擊add data source選項，進入數據源配置頁面：
選擇prometheus做爲數據源配置，點擊prometheus後進入數據源配置頁面，以下圖所示：
在紅色框中配置相關的信息，這裏grafana和prometheus在同一臺機器上，因此這裏配置http://localhost:9090 ，填寫完成後，點擊save and test，而後點擊綠色框中的dashbords選項，選擇prometheus 2.0 stats點擊後面的import。
Import以後，在首頁中，選擇配置的prometheus 2.0 stats，就能夠看到數據展現。

Grafana dashboards添加：

點擊左側欄中的+圖標下的import，在頁面中輸入grafana labs的dashboards下的插件id（node_exporter：1860， mysqld_exporter: 6239， jvm: 4701/9568），會自動跳轉至配置頁，選擇數據源爲prometheus，而後點擊import。操做完成，服務運行一段時間以後能夠看到相關的數據統計：

注意紅色框中，容器名稱時沒有的，這裏須要說明得是，使用4701這個dashboards時，須要在spring boot配置文件中增長一些配置，兩種配置二選一便可：

prometheus和grafana 服務監控搭建