Prometheus監控系統入門與部署

本文介紹新一代的監控系統 Prometheus，並指導使用者如何一步一步搭建一個 Prometheus 系統。

什麼是 Prometheus ？

Prometheus是一套開源的監控與告警框架，由工作在 SoundCloud 的 google 前員工在 2012 年建立，作為社群開源專案進行開發，並於 2015 年正式釋出。2016 年， 繼 Kubernetes 之後，Prometheus 成為 Cloud Native Computing Foundation 的第二個專案。

Prometheus 的特點

1. 多維度的時間序列資料模型，以 metric 和鍵值對加以區分；
2. 靈活的查詢語言；
3. 部署方便：不依賴分散式儲存；可自治的單伺服器節點；
4. 時間序列資料通過HTTP協議以拉取（pull）的方式收集；
5. 通過中間的閘道器可以實現時間序列的推送；
6. 監控目標可以通過服務發現或靜態配置；
7. 支援多種繪圖和儀表盤模式

Prometheus 的元件

Prometheus 的生態系統包括多個元件，其中大部分都是可選的：

1. Prometheus Server，負責抓取、儲存時間序列資料；
2. 客戶端庫（client library），組合進應用程式碼；
3. 推送閘道器（push gateway），支援“短暫”的任務；
4. 特殊用途的exporter，支援如 HAProxy，StatsD，Graphite，Redis 一類的服務；
5. 一個 告警管理器（Alertmanager）來管理告警；
6. 各種支援工具

大部分 Prometheus 的元件都是用 Go 寫的，部署很方便。

Prometheus 的架構

從架構圖中可以看出其大概的工作流程：

1. Prometheus Server 以服務發現（如 Kubernetes 等）的方式自動發現或者靜態配置新增監控目標；
2. Prometheus Server 定期從監控目標（Jobs/exporters）或 Pushgateway 中拉取資料（metrics），將時間序列資料儲存到其自身的時間序列資料庫（TSDB）中；
3. Prometheus Server 通過 HTTP Server 對外開放介面，可以給視覺化工具（如 Prometheus web UI、Grafana 或 你自己開發的工具）用 PromQL 查詢/匯出資料；
4. 當有告警產生時，Prometheus Server 將告警資訊推送到 Alertmanager ，由 Alertmanager 根據配置的策略傳送告警資訊到對應的接收方；
5. Pushgateway 接收 “Short-lived” 型別的 Jobs 推送過來的 metrics 並快取，等待 Prometheus Server 抓取。

Prometheus 適合做什麼？

Prometheus 非常適合記錄純數字的時間序列，既可以是以主機為中心的監控，也可以是以服務為導向的動態架構。在微服務的世界，它支援多維度的資料集合，查詢功能非常強大。

Prometheus 是為可用性而設計，利用它你可以快速定位問題。每一個 Prometheus Server 都是獨立的，不依賴於網路儲存或其他的第三方服務。你可以在部分基礎設施出現問題時仍然使用它。

Prometheus 不適合做什麼？

Prometheus 用於評估可用性。如果你想要100%的精準度，比如每個請求的賬單，Prometheus就不是一個好的選擇，因為收集上來的資料可能沒這麼細緻、完整。對於這樣的需求，你最好用其他的大資料系統對資料做分析。

Prometheus 相關概念

為了在後面的安裝和配置步驟中更好地理解，我們首先需要學習一下 Prometheus 的一些相關概念。

資料模型

Prometheus 以時間序列儲存所有的資料：屬於相同 metric 名稱和相同標籤組（鍵值對）的值以時間順序形成資料流。

Metric 名稱和標籤

每一個時間序列都是由其 metric名稱和一組標籤（鍵值對）唯一標識。

metric名稱 代表了被監控系統的一般特徵（比如 http_requests_total，代表接收到的 HTTP 請求總數）。其語法要求符合正規表示式 [a-zA-Z_:][a-zA-Z0-9_:]*。

需要注意的是，冒號 : 一般保留用於使用者自定義的記錄規則，不應該給 exporter 使用。

標籤 給 Prometheus 帶來了多維度資料模型：對於相同metric名稱，任意的標籤組合標識出該 metric 在某特定維度上的例項（比如：所有使用POST方法到/api/tracks介面的HTTP請求）。查詢語言可以基於這些維度過濾和聚合資料。變更任何標籤值，包括增加和刪除標籤，都會創造新的時間序列。

標籤名稱可以包含 ASCII 字元、數字和下劃線，其必須符合正規表示式 [a-zA-Z0-9_]*，以雙下劃線__開頭的標籤名用於內部使用。

標籤的值可以包含 Unicode 字元。

表示法

給定 metric名稱和一組標籤，我們一般用以下的表示法來表示時間序列：

<metric name>{<label name>=<label value>, ...}

舉個例子：一個時間序列的 metric名稱是api_http_requests_total，標籤是method="POST"和handler="/messages"，那麼我們可以這樣寫：

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

這和 OpenTSDB 的表示法是一樣的。

Metric 的型別

Prometheus 的客戶端庫提供四種 Metric 的型別，這些型別目前只在客戶端庫和傳輸協議上做區分。Prometheus server 暫時沒有使用這些型別資訊，會將資料變成無型別的時間序列。這種情況在未來可能會有所變化。

Counter

Counter 是一種累加的 metric ，代表一個單調函式，其值只能上升或在重啟時重置為0。可以用 counter 代表處理的請求數、完成的任務數、出現的錯誤數量等。

不可以用 counter 代表一個可能會下降的值。比如，不能用 counter 表示正在執行的程式數，而應該用下面我們將提到的 gauge。

Gauge

Gauge 代表一個可以任意增加或減少的 metric 值。

Gauge 一般用來測量如溫度、當前的記憶體使用量這樣的值，也用來檢測會上升或下降的值，比如 Go 的併發 goroutine 的數量。

Histogram

Histogram 取樣觀測的結果（一般是請求持續時間或響應大小）並在一個可配置的分佈區間（bucket）內計算這些結果。其也提供所有觀測結果的總和。

Histogram 有一個基本 metric名稱 <basename>，在一次抓取中展現多個時間序列：

• 累加的 counter，代表觀測區間：<basename>_bucket{le="<upper inclusive bound>"}
• 所有觀測值的總數：<basename>_sum
• 觀測到的事件數量：<basenmae>_count

使用 histogram_quantile() 函式計算 histogram 的分位數或者聚合 histogram。Histogram 也適用於計算 Apdex指數。當配置分佈區間（bucket）的時候請牢記 histogram 是累加的。

Summary

和 histogram 相似，summary 取樣觀測的結果（一般是請求持續時間或響應大小）。但是它還提供觀測的次數和所有值的總和，它通過一個滑動的時間視窗計算可配置的分位數。

Summary 有一個基本的 metric名稱 <basename>，在一次抓取中展現多個時間序列：

• 觀測事件的流式φ-分位數（0 ≤ φ ≤ 1）：<basename>{quantile="φ"}
• 所有觀測值的總和：<basename>_sum
• 觀測的事件數量：<basename>_count

任務（Job）與例項（Instance）

在 Prometheus 中，一個你可以抓取資料的端點叫做例項（instance），一般等價於一個程式。一組有著同樣目標的例項（例如為彈性或可用性而複製的程式副本）叫做任務（job）。

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

當 Prometheus 抓取目標時，它會自動新增一些標籤到時間序列中，用於標識被抓取的目標：

• job：目標所屬的任務名稱；
• instance：目標URL中的<host>:<port>部分；

如果兩個標籤在被抓取的資料中已經存在，那麼就要看配置選項 honor_labels 的值來決定行為了。

每次對例項的抓取， Prometheus 會在以下的時間序列中儲存一個樣本（樣本指的是在一個時間序列中特定時間點的一個值）：

• up{job="<job-name>", instance="<instance-id>"}：如果例項健康（可達），則為 1 ，否則為 0
• scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}：抓取的時長
• scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}：在 metric relabeling 之後，留存的樣本數量
• scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}：目標暴露出的樣本數量

up 這個時間序列對於例項的可用性監控來說非常有用。

安裝與配置 Prometheus

Prometheus 大部分元件都是用 Go 編寫，因此安裝非常方便。

在元件的選擇上，一般包括必選的 Prometheus server 和各種可選元件如：Alertmanager、各種 exporter、Grafana 等。

安裝方式可以是二進位制安裝或通過 Docker 安裝。

下面我們將通過二進位制的方式安裝 Prometheus server + Alertmanager + Grafana + node_exporter，另外我們還需要安裝一個釘釘告警元件 prometheus-webhook-dingtalk，用於將告警傳送到釘釘群組。

其他的元件讀者可以參考官網/Github 等站點自行安裝。

主機資源準備

編號	系統	IP地址	安裝的元件
1	CentOS 7	192.168.2.10	Prometheus server & node_exporter
2	CentOS 7	192.168.2.11	Grafana
3	CentOS 7	192.168.2.12	Alertmanager & prometheus-webhook-dingtalk

安裝 Prometheus Server

熟悉 Ansible 的同學可以從 Github 上下載 Playbook 進行 Prometheus server 的安裝，下面介紹手動安裝的步驟：

1. 在 192.168.2.10 上建立系統使用者 prometheus 和組 prometheus：

   $ groupadd -r prometheus
   $ useradd -r -M -s /sbin/nologin -d /tmp prometheus
   

2. 到官網下載已編譯的二進位制原始碼包，解壓縮。

   $ curl https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz | tar -zx
   

3. 規定配置檔案的目錄為 /etc/prometheus，資料庫目錄為 /data/prometheus。複製配置檔案 prometheus.yml 、目錄 conf.d、rules、file_sd、console_libraries、consoles 到配置檔案目錄 /etc/prometheus，建立資料庫目錄。

   $ mkdir -p /etc/prometheus /data/prometheus
   $ chown root:prometheus /etc/prometheus /data/prometheus
   $ cp -rf prometheus.yml conf.d rules file_sd console_libraries consoles /etc/prometheus
   

4. 複製二進位制檔案 prometheus 和 promtool 到 /usr/local/bin。

5. 建立 systemd service unit 檔案 /etc/systemd/system/prometheus.service：

   [Unit]
   Description=Prometheus
   After=network.target
   
   [Service]
   Type=simple
   Environment="GOMAXPROCS=4"
   User=prometheus
   Group=prometheus
   ExecReload=/bin/kill -HUP $MAINPID
   ExecStart=/usr/local/bin/prometheus \
     --config.file=/etc/prometheus/prometheus.yml \
     --storage.tsdb.path=/data/prometheus \
     --storage.tsdb.retention=30d \
     --web.console.    libraries=/etc/prometheus/console_libraries \
     --web.console.templates=/etc/prometheus/consoles \
     --web.listen-address=0.0.0.0:9090 \
     --web.external-url=/prometheus
   PrivateTmp=true
   PrivateDevices=true
   ProtectHome=true
   NoNewPrivileges=true
   LimitNOFILE=infinity
   ReadWriteDirectories=/data/prometheus
   ProtectSystem=full
   
   
   SyslogIdentifier=prometheus
   Restart=always
   
   [Install]
   WantedBy=multi-user.target
   
   

通過以上幾步我們就完成了 Prometheus server 的安裝。

配置 Prometheus Server

Prometheus server 的配置分兩部分，一部分屬於固定配置，需要通過命令列引數傳遞，在上面安裝的時候我們已經寫在 unit 檔案中。另一部分就需要配置檔案了。配置檔案 prometheus.yml 的格式是 yaml ，主要分以下幾個配置塊：

• 全域性配置 global
• 規則檔案配置 rule_files
• 抓取配置 scrape_configs
• 告警配置 alerting
• 遠端讀/寫功能 remote_read 和 remote_write

我們來逐個進行配置。

全域性配置 global

全域性配置中的引數在其他的所有配置塊中都可以使用，將作為其他配置塊的預設值。
以下是一個例子：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s #需注意該值應小於 scrape_internal
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn

規則檔案配置 rule_files

規則檔案配置指定規則和告警的配置檔案的路徑，可以是 glob 模式：

rule_files:
  - /etc/prometheus/rules/*.rules

Prometheus 中的規則檔案分兩種型別：記錄規則和告警規則。

記錄規則可以讓你提前計算高頻需求或對計算效能要求很高的表示式，將結果儲存為一組新的時間序列。查詢這些提前計算好的結果一般都會比每次到用時才計算要快得多。對於 Dashboard 來說這很重要，因為 Dashboard 每次重新整理的時候都會重複查詢同樣的表示式。

告警規則可以讓你基於 PromQL 表示式定義告警條件，並將觸發的告警提醒傳送給外部的服務。每當告警表示式在一個時間點產生一個或多個向量元素時，告警會將這些元素的標籤設為啟用狀態。

記錄和告警規則放在一個規則組（group）中。同一個組中的規則會以一個特定的頻率不斷地執行。

規則檔案的語法

groups:
  [ - <rule_group> ]

舉個例子：

groups:
  - name: example
    rules:
    - record: job:http_inprogress_requests:sum
      expr: sum(http_inprogress_requests) by (job)

<rule_group>

# 組的名稱，在一個檔案中需唯一
name: <string>

# 組中規則執行的頻率
[ interval: <duration> | default = global.evaluation_interval ]

rules:
  [ - <rule> ... ]

<rule>

記錄規則的語法：

# 時間序列的名稱，必須是一個合法的 metric 名稱
record: <string>

# PromQL 表示式。每一個計算週期內都會計算一次，結果記錄為一組以上面 'record' 給定的名稱命名的時間序列
expr: <string>

# 儲存結果前需要新增或覆蓋的標籤
labels:
  [ <labelname>: <labelvalue> ]

告警規則的語法：

# 告警的名稱，必須是一個合法的 metric 名稱。
alert: <string>

# PromQL 表示式。每一個計算週期內都會計算一次，所有的結果組成時間序列，會成為待定/觸發的告警。
expr: <string>

# 告警如果持續了這麼長時間，就會觸發一次；如果還沒持續這麼長時間，就認為是待定的告警
[ for: <duration> | default = 0s ]

# 對於每一個告警需要新增/覆蓋的標籤
labels:
  [ <labelname>: <tmpl_string> ]

# 對於每一個告警需要新增的註釋
annotations:
  [ <labelname>: <tmpl_string> ]

一個告警規則的例子如下：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

for 子句使 Prometheus 在第一次發現一個表示式輸出的向量元素後、到觸發該元素對應的告警之前需要等待特定的時長。在這種情況下， Prometheus 會檢查告警是否在10分鐘的等待期內持續被啟用，當等待期滿了以後就會觸發告警。被啟用而未觸發的告警，就處於等待狀態（Pending）。

label 子句用於給告警提供一組額外的標籤。已經存在的標籤會被覆蓋。標籤的值可以用模板做替換。

annotations 子句用於給告警提供一組資訊標籤，這組標籤可以儲存更長的資訊，比如告警描述、執行記錄連結等。註釋的值也可以用模板做替換。

模板

標籤和註釋的值都可以用 console templating 格式做模板轉換。$labels 變數代表一個告警例項的所有標籤鍵/值對，$value 變數代表告警例項計算的值。

# 插入一個觸發元素的標籤值：
{{ $labels.<labelname> }}
# 插入觸發元素的數字表示式值：
{{ $value }}

例：

groups:
- name: example
  rules:

  # 對於任何超過5分鐘還不可達的例項進行告警：
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # 對於平均請求延遲超過1秒的例項進行告警：
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

更多模板的例子可以訪問官方文件檢視。

抓取配置 scrape_configs

抓取配置設定抓取配置的列表。

每一個抓取配置指定了一組抓取的目標和描述抓取方式的一些引數。一般來說，一個抓取配置對應一個任務（job）。

目標可以用 static_configs 靜態配置，也可以用支援的某種服務發現機制動態發現。

另外 relabel_configs 允許在抓取前對目標及其標籤進行修改。

下面展示了四個抓取配置，其中 prometheus 和 redis 通過 static_configs 靜態配置，node 和 dms 則通過 file_sd 的方式自動發現目標。如果你是在 Kubernetes 中執行，或環境中有 Consul 一類服務發現工具，你也可以配置 kubernetes_sd_configs 或 consul_sd_configs 等實現動態發現。

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml

告警配置 alerting

alerting 的配置與 Alertmanager 有關，目前我們還沒安裝 Alertmanager，但可以先把配置配上，這裡我們用靜態配置指定 Alertmanager 的 HTTP 介面：

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093

遠端讀/寫功能 remote_read 和 remote_write

這部分配置將資料來源與 Prometheus 分離時使用，在我們當前的安裝架構中不需要做額外配置。

下面是完整的配置檔案：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn

rule_files:
  - /etc/prometheus/rules/*.rules

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml

關於配置中更多的配置項和用法，請參閱官方文件。

exporter 簡介

對於自己研發的應用，我們可以在應用內加入客戶端庫，各種語言的庫使用方式請參考：https://prometheus.io/docs/instrumenting/clientlibs/

但是對於某些監控物件，比如：作業系統、Nginx、Redis、MySQL，我們不能插入庫檔案，怎麼辦呢？ Prometheus 的解決方案是引入 exporter 。通過各種 exporter 你可以方便地採集各類目標執行資料。

這裡我們只介紹 node_exporter。該 exporter 適用於 *nix 作業系統，可以採集各種基礎資源使用資訊如 CPU、記憶體、磁碟、網路等。

其他的 exporeter 你可以在 https://prometheus.io/docs/instrumenting/exporters/ 查詢並使用。

安裝 node_exporter

同樣在官方下載頁面我們可以找到 node_exporter 的二進位制安裝包，只需下載並放到後臺執行即可。

細心的同學已經發現了，我們在 Prometheus 配置 scrape_configs 時已經加入了 node_exporter 的部分配置：

scrape_configs:
...
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml

file_sd_configs中的配置檔案可以用 yaml 或 JSON 格式編寫，這裡還是用我們熟悉的 yaml ：

- targets:
  - 192.168.2.10:9100
  labels:
  - server_name: prometheus_server

安裝 Alertmanager 和 prometheus-webhook-dingtalk

讓我們來到告警伺服器（192.168.2.12），下載兩個軟體的二進位制包：

$ curl https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz | tar zx

$ git clone https://github.com/timonwong/prometheus-webhook-dingtalk.git

只需要將兩個二進位制包 alertmanager 和 prometheus-webhook-dingding 放進 /usr/local/bin 就能執行了。

配置 Alertmanager 和 prometheus-webhook-dingtalk

1. 建立配置檔案目錄 /etc/alertmanager 並複製配置檔案 alertmanager.yml 到這裡；建立儲存目錄：

   $ mkdir -p /etc/alertmanager
   $ cp alertmanager.yml /etc/alertmanager.yml
   $ mkdir -p /data/alertmanager
   

2. 修改配置檔案，使其在告警時傳送給釘釘的 webhook：

   global:
     resolve_timeout: 5m
   
   route:
     receiver: 'focusops'
     group_wait: 10s
     group_interval: 1m
     repeat_interval: 1h
     group_by: ['alertname']
     routes:
       - receiver: 'focusops'
         continue: true
       - receiver: 'xyz'
   
   receivers:
   # 我們指定了兩個receiver，分別到 dingtalk 的 webhook1 和 webhook2 ，這和我們後面啟動 prometheus-webhook-dingtalk 時的引數保持一致，    需要注意。
   - name: 'focusops'
     webhook_configs:
     - send_resolved: true
       url: 'http://localhost:8060/dingtalk/webhook1/send'
   - name: 'xyz'
     webhook_configs:
     - send_resolved: true
       url: 'http://localhost:8060/dingtalk/webhook2/send'
   
   inhibit_rules:
     - source_match:
         severity: 'critical'
       target_match:
         severity: 'warning'
       equal: ['alertname', 'dev', 'instance']
   

3. 編寫 Alertmanager 和 prometheus-webhook-dingtalk 的啟動指令碼，並啟動：

   alertmanager.sh：

   alertmanager \ --config.file=/etc/alertmanager/alertmanager.yml \
   --web.external-url=/alertmanager \
   --storage.path=/data/alertmanager/ \
   &> alertmanager.log &
   

   dingtalk.sh（注意替換token1和token2）：

   prometheus-webhook-dingtalk \
   --ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=<token1> \
   --ding.profile=webhook2=https://oapi.dingtalk.com/robot/send?access_token=<token2> \
   &>dingtalk.log &
   

安裝與配置 Grafana

儘管 Prometheus 自身提供一個 web UI，但是這個 UI 還是太簡陋了， Grafana 幾乎是標配的展示工具。

對於我們的 CentOS 7 系統，我們可以通過 YUM 快速安裝：

1. 新增 yum 原始檔 /etc/yum.repos.d/grafana.repo：

   [grafana]
   name=grafana
   baseurl=https://packagecloud.    io/grafana/stable/el/7/$basearch
   #repo_gpgcheck=1
   enabled=1
   gpgcheck=0
   #gpgkey=https://packagecloud.io/gpg.key     https://grafanarel.s3.amazonaws.    com/RPM-GPG-KEY-grafana
   #sslverify=1
   #sslcacert=/etc/pki/tls/certs/ca-bundle.crt
   

   因為國內網路的關係我把 gpgcheck 相關的驗證都去掉了，不放心的可以把刪除註釋，但是需要保證可以網路連通哦！

2. YUM 安裝：

   $ yum install grafana
   

3. 配置 Grafana

   配置檔案 /etc/grafana/grafana.ini 只需要注意登入方面的配置，如 admin_user 和 admin_password，你還可以啟用 LDAP 驗證模組：

   [auth.ldap]
   enabled = true
   config_file = /etc/grafana/ldap.toml
   

   然後配置 /etc/grafana/ldap.toml ，這裡不再贅述。

4. 啟動 Grafana

   $ systemctl start grafana-server
   

5. 關聯 Grafana 與 Prometheus 資料來源

   訪問 http://192.168.2.11:3000 開啟 Grafana，登入後選擇新增資料來源，在 Settings 中選擇 Type 為 Prometheus ，在 HTTP 的 URL 中填入 Prometheus server 的 HTTP 介面地址，點選 Save & Test，看到綠色的 Data source is working 就說明已經關聯成功了。

6. 新增 Dashboard

   雖然你可以自定義 Dashboard，但是如果我告訴你已經有很多人做好了現成的 Dashboard 並且你可以直接拿來用呢？

   是的，除非我們有特定要求，不然我們何必自己造輪子。

   開啟 http://192.168.2.11:3000/dashboard/import ，填入 grafana 官網的 Dashboard ID，即可以匯入其他人做好的 Dashboard 作品。

   各種 Dashboard 我們可以在 https://grafana.com/dashboards 檢視、檢索。

在 Grafana 中檢視資料和圖表

對於不同的時間序列我們可以使用不同的 Dashboard 進行檢視。比如對於 node_exporter 採集到的時間序列，我們只需匯入 node_exporter 適配的 Dashboard （ID：1860），就可以看到圖表了：

最後

上面介紹了這麼多，但是如何自定義圖表和告警規則？在下一篇文章中我將給大家介紹 Prometheus 的查詢語言 PromQL。