Prometheus+Grafana部署及模板展示（我熬夜成癮，卻換不來你一句晚安。）

一、Grafana部署及模板展示

grafana是一款基於go語言開發的通用可視化工具，支持從不同的數據源加載並展示數據，可作為其數據源的部分儲存系統如下所示：

TSDB：Prometheus、IfluxDB、OpenTSDB和Graphit

日志和文檔存儲：Loki和ElasitchSearch

分布式請求跟蹤：Zipkin、Jaeger和Tenpo

SQL DB：Mysql、PostgreSQL和Microsoft SQL server

grafana基礎默認監聽於TCP協議的3000端口，支持集成其他認證服務，且能夠通過/metrics輸出內建指標

數據源（Data Source）：提供用於展示的數據的儲存系統

儀表盤（Dashboard）：組織和管理數據的可視化面板（Panel）

團隊和用戶：提供了面向企業組織層級的管理能力

 

1.Grafan部署步驟

[root@prometheus ~]# ls

grafana-7.3.6-1.x86_64.rpm

[root@prometheus ~]# yum install grafana-7.3.6-1.x86_64.rpm -y

[root@prometheus ~]# systemctl start grafana-server.service

[root@prometheus ~]# ss -antp | grep grafana-server

 

 

 

 

 

 

 

 

 

 

二、打標簽

1.重新打標定義（在job上定義）

對target重新打標是在數據抓取之前動態重寫target標簽的強大工具，在每個數據抓取配置中，可以定義多個relabel步驟，它們將按照定義的順序依次執行

對於發現的每個target，Prometheus默認會執行如下操作：

job的標簽設定為其所屬的job name的值;

_address_標簽的值為該target的套接字地址":"

instance標簽的值為_address_的值;

_scheme_標簽的值為抓取該target上指標時使用的協議(http或https) ;

_metrics _path_標簽的值為抓取該target上的指標時使用URI路徑，默認為/metrics;

param_標簽的值為傳遞的URL參數中第一個名稱為的參數的值

重新標記期間，還可以使用該target上以"meta "開頭的元標簽;

各服務發現機制為其target添加的元標簽會有所不同;

重新標記完成后，該target上以"_"開頭的所有標簽都會被移除;

若在relabel的過程中需要臨時存儲標簽值，則要使用tmp標簽名稱為前綴進行保存，以避免同Prometheus的內建標簽沖突

2.relabel config(重新打標配置)

修改標簽值、增加刪除標簽，通過調用不同參數實現自己的需求

source_labels：指定調用哪些已有的標簽（可引用多個）在重新打標的時候會將這些標簽對應的值給引用/提取並連接起來，例如: cpu指標{host=node1; host=node2 }

target_labels：與source_labels組合使用，可以指定使用哪個已有標簽賦值給指定的新標簽

separator：對應源標簽的標簽值使用什么連接符，默認為" ;"

regex：對於源標簽，使用哪個正則表達式對源標簽進行模式匹配、匹配后可以將對應的結果復制到target上，賦值方式:(引用所有正則表達式的內容進行賦值)

moulus：hash算法函數

replacement：把目標標簽的值改為新的值

action <relabel_action>：表示重新打標的方式是什么，以及要實現什么功能

三、prometheus告警功能

Prometheus對指標的收集、存儲同告警能力分屬於Prometheus Server和AlertManager(通用的組件)兩個獨立的組件，前者僅負責基於"告警規則"生成告警通知，具體的告警操作則由后者完成。Alertmanager負責處理由客戶端發來的告警通知客戶端通常是Prometheus server，但它也支持接收來自其它工具的告警。Alertmanager對告警通知進行分組、去重后，根據路由規則將其路由到不同的receiver，如Email、短信或PagerDuty等。目前Alertmanager還不支持釘釘，那用戶完全可以通過Webhook與釘釘機器人進行集成，從而通過釘釘接收告警信息。同時AltManager還提供了靜默和告警抑制機制來對告警通知行為進行優化

1.告警功能概述

prometheus對指標的收集、存儲與告警能力分屬於Prometheus serve和alertmanager兩個獨立的組件，pro-server只負責通過"告警規則"生成告警通知，具體告警操作是由alertmmanager完成

2.告警規則

是由PromQL編寫的布爾值表達式使用>< =與一個常用量值，比如80%進行比較，其返回值為true或false，prometheus-server對抓取到的指標序列與告警規則中做為比較的Prometheus匹配，則會把此樣本值抓取過來作比較，若返回值為true則認為指標異常，不能滿足false，則為正常值以上表達式為告警規則表達式。比如：篩選一個指標數據cpu使用率<0%系統異常

3.通知告警信息

一旦條件表達式為true了就會觸發通知信息，送給altermanager，由alter借助特定服務的API或者訪問入口，將此信息發出去一般稱為告警媒介，也可以借助郵件進行告警SMTP

4.prometheus監控系統的告警邏輯

route：告警路由，分組、分類分發告警消息給不同渠道

prometheus通過alter-rule規則，生成告警通知給altermanager，altermanager會生成本地的告警路由表（第一路由默認稱為根路由，所有的告警信息都需要一個根路由，沒有一個匹配項，則需要設置一個默認路由）為實現將特定的信息發送給特定的用戶。

例如：

按消息級別來看，嚴重、中等、普通級別，紅色報警、藍色報警，應用發送方

按分組：業務運維、系統運維、基礎設施運維、k8s運維

5.告警功能

除了基本的告警通知能力外，Altermanager還支持對告警進行去重、分組、抑制

6.靜默、抑制、分組等功能

分組 （Grouping)：將相似告警合並為單個告警通知的機制，在系統因大面積故障而觸發告警潮時，分組機制能避免用戶被大量的告警噪聲淹沒，進而導致關鍵信息的隱沒；

抑制(Inhibition)：系統中某個組件或服務故障而觸發告警通知后，那些依賴於該組件或服務的其它組件或服務可能也會因此而觸發告警，抑制便是避免類似的級聯告警的一種特性，從而讓用戶能將精力集中於真正的故障所在；

靜默(silent)：是指在一個特定的時間窗口內，即便接收到告警通知，Alertmanager也不會真正向用戶發送告警信息的行為;通常，在系統例行維護期間，需要激活告警系統的靜默特性；

路由(route)：用於配置Alertmanager如何處理傳入的特定類型的告警通知，其基本邏輯是根據路由匹配規則的匹配結果來確定處理當前告警通知的路徑和行為

四、部署告警對接郵箱

在prometheus-server端定義告警規則，指定alertmanager的位置，將告警信息發送給alert處理

1.安裝altermanager

[root@prometheus ~]# cd /opt/

[root@prometheus opt]# ls

alertmanager-0.23.0.linux-amd64.tar.gz

[root@prometheus opt]# tar zxf alertmanager-0.21.0.linux-amd64.tar.gz -C /usr/local/

[root@prometheus opt]# ln -s /usr/local/alertmanager-0.21.0.linux-amd64/ /usr/local/alertmanager

[root@prometheus opt]ln -s /usr/local/prometheus-0.21.0.linux-amd64/prometheus /usr/local/bin

2.查看配置文件

[root@prometheus ~]# cat /usr/local/alertmanager-0.21.0.linux-amd64/alertmanager.yml

route: #路由信息

group_by: ['alertname'] #分組

group_wait: 30s #分組緩沖/等待時間

group_interval: 5m #重新分組時間

repeat_interval: 1h #重新告警間隔

receivers:

- name: 'web.hook'

webhook_configs:

- url: 'http://127.0.0.1:5001/' #標注5001端口

inhibit_rules: #抑制規則的策略

- source_match: #匹配項

severity: 'critical' #嚴重的級別

target_match:

severity: 'warning' #target匹配warning級別

equal: ['alertname', 'dev', 'instance'] #符合alertname、dev、instance

3.修改alertmanager的配置文件

global:

resolve_timeout: 5m

smtp_from: [e-mail]

smtp_auth_username: [e-mail]

smtp_auth_password:

smtp_require_tls: false

smtp_smarthost: 'smtp.qq.com:465'

 

route:

group_by: ['alertname']

group_wait: 10s

group_interval: 10s

repeat_interval: 1h

receiver: 'email-test'

receivers:

- name: 'email-test'

email_configs: ossiocvhdvirbiad

- to: [e-mail]

send_resolved: true

4.配置綁定的郵箱

登入郵箱→設置→賬戶→IMAP/SMTP服務→開啟

5.啟動alertmanager

[root@localhost alertmanager]# ./alertmanager

 

6.相關配置文件

[root@prometheus ~]# cd /usr/local/alertmanager

[root@prometheus alertmanager]# mkdir alert-config

[root@prometheus alertmanager]# cd alert-config/

[root@prometheus alert-config]# mkdir -p alert_rules targets

[root@prometheus alert-config]# ls

alert_rules targets

[root@prometheus alert-config]# cd alert_rules/

[root@prometheus alert_rules]# vim instance_down.yaml

groups:

- name: AllInstances

rules:

- alert: InstanceDown

# Condition for alerting

expr: up == 0

for: 20s

# Annotation - additional informational labels to store more information

annotations:

title: 'Instance down'

description: Instance has been down for more than 20 seconds.'

# Labels - additional labels to be attached to the alert

labels:

severity: 'critical'

 

----

[root@prometheus ~]# cd /usr/local/alertmanager/alert-config/targets/

[root@prometheus targets]# vim alertmanagers.yaml

 

- targets:

- 192.168.153.20:9093

labels:

app: alertmanager

 

----

[root@prometheus targets]# vim nodes-linux.yaml

 

- targets:

- 192.168.153.10:9100

- 192.168.153.20:9100

- 192.168.153.30:9100

labels:

app: node-exporter

job: node

 

----

[root@prometheus targets]# vim prometheus-servers.yaml

 

- targets:

- 192.168.153.10:9090

labels:

app: prometheus

job: prometheus

7、配置prometheus啟動文件

 

[root@prometheus ~]# cd /usr/local/alertmanager/alert-config/

[root@prometheus alert-config]# vim prometheus.yml

# my global config

# Author: MageEdu <[e-mail]>

# Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/

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:

- file_sd_configs:

- files:

- "targets/alertmanagers*.yaml"

 

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.

rule_files:

- "rules/*.yaml"

- "alert_rules/*.yaml"

 

# 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=<job_name>` to any timeseries scraped from this config.

- job_name: 'prometheus'

# metrics_path defaults to '/metrics'

# scheme defaults to 'http'.

static_configs:

file_sd_configs:

- files:

- targets/prometheus-*.yaml

refresh_interval: 2m

 

# All nodes

- job_name: 'nodes'

file_sd_configs:

- files:

- targets/nodes-*.yaml

refresh_interval: 2m

 

- job_name: 'alertmanagers'

file_sd_configs:

- files:

- targets/alertmanagers*.yaml

refresh_interval: 2m

 

8.指定文件啟動alertmanager

[root@prometheus ~]# cd /usr/local/alertmanager

[root@prometheus alertmanager]# ./alertmanager

9.指定文件啟動prometheus

[root@prometheus ~]# cd /usr/local/prometheus-2.27.1.linux-amd64/

[root@prometheus prometheus-0.20.0.linux-amd64]# ./prometheus --config.file=./alert-config/prometheus.yml