天天看點
傳回

Prometheus監控系統入門與部署Prometheus監控系統入門與部署

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 的架構

Prometheus監控系統入門與部署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

     ，否則為

  • 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監控系統入門與部署Prometheus監控系統入門與部署

最後

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

監控 prometheus 監控系統
上一篇: 監控元件Prometheus安裝配置監控元件普羅米修斯Prometheus
下一篇: Prometheus 系統監控方案 二 安裝與配置

繼續閱讀