prometheusalert 安装 mysql 指定字符集 prometheus.yml详解

1. 配置文件说明

Prometheus可以通过命令行或者配置文件的方式对服务进行配置。

• 命令行方式一般用于不可变的系统参数配置，例如存储位置、要保留在磁盘和内存中的数据量等;配置文件用于定义与数据动态获取相关的配置选项和文件等内容。
• 命令行方式的配置属性可以通过 prometheus -h 的方式来获取，这些配置属性主要在服务启动时候设置
• 配置文件方式，需要在prometheus.yml 文件中修改配置属性，该配置文件的内容是以YAML格式编写的

官方文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

• 默认情况下，prometheus的配置文件由4部分组成，效果如下：

[root@cs7 node_exporter]# egrep -v '^#|^$' prometheus.yml
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).
alerting:
 alertmanagers:
 - static_configs:
 - targets:
rule_files:
scrape_configs:
 - job_name: 'prometheus'
 static_configs:
 - targets: ['localhost:9090']

scrape_interval: 15s #采集目标主机监控据的时间间隔

scrape_timeout: 10s #数据采集超时时间,默认10s

evaluation_interval: 1m #查看规则的时间间隔,默认是1m

• 配置解析

#核心配置:

global #全局配置内容

alerting #触发告警相关的配置，主要是与Alertmanager相关的设置。

rule_files #各种各样的外置规则文件配置，包含了各种告警表达式、数据查询表达式等

scrape_configs #监控项的配置列表，这是最核心的配置

#除了默认的四项配置之外，prometheus还有另外可选的其它配置如下

#扩展配置(8项) 
tls_config、static_config、relabel_config、metric_relabel_configs、 
alert_relabel_configs、alertmanager_config、remote_write、remote_read
#平台集成配置(12项) 
azure_sd_config、consul_sd_config、dns_sd_config、ec2_sd_config、 
openstack_sd_config、file_sd_config、gce_sd_config、kubernetes_sd_config、 
marathon_sd_config、nerve_sd_config、serverset_sd_config、triton_sd_config

• scrape_configs 管理

scrape_configs 是操作最多的一个配置段，它指定了一组监控目标及其细节配置参数，这些目标和参数描述了如何获取指定主机上的时序数据。配置样例如下:

scrape_configs:
 - job_name: '<job_name>'
 static_configs:
 - targets: [ '<host_ip:host_port>', ... ]
 labels: { <labelname>: <labelvalue> ... }

#配置解析: #在一般情况下，一个scrape_configs配置需要指定一个或者多个job，

根据我们之前对基本概念的了解，每一个job都是一系列的instance集合，借助job我们可以将目标主机进行分组管理。

#对于job内部的每一个instance的配置，都需要借助于static_configs参数获取目标列表，

只要在该列表位置的目标，都可以被Prometheus动态服务自动发现。

#static_configs可以借助于 targets 以ip+port 方式发现目标，也可以使用labels以标签方式发现目标。

语法检查

[root@prometheus ~]#promtool check config
/usr/local/prometheus/conf/prometheus.yml

2. 标签简介

标签功能: 用于对数据分组和分类,利用标签可以将数据进行过滤筛选

标签的常见场景:

• 删除不必要的指标
• 从指标中删除敏感或不需要的标签
• 添加、编辑或修改指标的标签值或标签格式

标签分类:

• 默认标签: Prometheus 自身内置
• 形式: __keyname__
• 应用标签: 应用本身内置
• 形式: keyname
• 自定义标签: 用户定义
• 形式: keyname

范例: 添加主机节点

#编辑prometheus.yml配置文件 scrape_configs:
 ...
 - job_name: "prometheus"
 static_configs:
 - targets: ['10.0.0.101:9100']
 - job_name: 'node_exporter'
 static_configs:
 - targets: ['10.0.0.104:9100','10.0.0.105:9100','10.0.0.106:9100']
#- '10.0.0.104:9100' #或者下面格式 #- '10.0.0.105:9100'
#- '10.0.0.106:9100'
#配置解析:static_configs 用于手工定制要监控的target 
#重启服务
systemctl restart prometheus.service

#查看效果,可以看到如下的内置的标签

• 应用默认的标签如下形式

范例：添加主机标签

#编辑prometheus.yml配置文件
[root@cs7 node_exporter]# cat prometheus.yml 
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.
alerting:
 alertmanagers:
 - static_configs:
 - targets:
rule_files:
scrape_configs:
 - job_name: "prometheus"
 static_configs:
 - targets: ["localhost:9090"]
 - job_name: "pushgateway"
 static_configs:
 - targets: ["192.168.225.167:9091"]
 - job_name: 'node_exporter' #添加以下行,指定监控的node exporter节点
 metrics_path: '/metrics'
 static_configs:
 - targets: ['192.168.225.167:9100'] 
 - targets: ['192.168.225.112:9100'] 
 - targets: ['192.168.225.113:9100'] 
 - targets: ['192.168.225.114:9100'] 
 #labels: {"app": "node_exporter"} 也可以使用这种方式添加标签
 labels: 
 name: shibosen
 class: m49
#重启服务
[root@prometheus ~]#systemctl restart prometheus.service 
#浏览器访问确认

3. 标签管理

官方文档

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#metric_relabel_configs

Prometheus对数据的处理流程是:

先从各目标节点上获取数据，然后对数据进行本地化处理，然后进行各种数据分析。这个流程中最核心的就是监控数据的本地化处理

在prometheus的配置选项中，有两个与监控指标密切相关的配置，relabel_config、 metric_relabel_configs，他们的作用就是监控目标上面的监控项进行标签管理和设置，便于在prometheus上设置更灵活的时序数据。

标签主要有两种表现形式:

• 私有标签

私有标签以"__*"样式存在，用于获取监控目标的默认元数据属性，比如__address__用于获取目标的

地址，__scheme__用户获取目标的请求协议方法，__metrics_path__获取请求的url地址等

• 普通标签

对个监控主机节点上的监控指标进行各种灵活的管理操作，常见的操作有，删除不必要|敏感指标，

添加、编辑或者修改指标的标签值或者标签格式。

对于一些全局性的标签，可以在global部分通过属性来设置，效果如下：

global: ...

# 与外部系统通信时添加到任何时间序列或警报的标签 external_labels:
 [ <labelname>: <labelvalue> ... ]
relabel_config、metric_relabel_configs 的使用格式基本上一致，虽然他们有很多配置，但是我们使用 的最多的也就那么三四个。
 #配置示例如下: scrape_configs:
 - job_name: 'prometheus'
 metric_relabel_configs:
 - source_labels: [<labelname> [, ...]]
 regex: '<regex> | default = (.*)'
 replacement: '<string> | default = $1'
 target_label: '<labelname>'
 action: '<relabel_action> | default = replace'
#属性解析: 
source_labels #指定正则表达式匹配成功的Label进行标签管理
regex #source_labels对应Label的匹配正则表达式的指定值
target_label #在进行标签替换的时候，可以将原来的source_labels替换为指定修改后的
label 
replacement #替换标签时,指定label对应的值进行修改后的值
action #对标签进行管理，常见的动作有replace|keep|drop|labelmap|labeldrop
等
 
 
#动作解析:
labeldrop #删除regex匹配的标签label
labelkeep #删除regex不匹配的标签label
labelmap #将regex对所有的标签名进行匹配，而后将匹配到的标签的值赋给replacement字段指定的标签名的值;通常用于取出匹配的标签名的一部分生成新标签,旧的标签仍会存在
replace #此为默认值，通过regex匹配source_label的值，使用replacement来进行替换
keep #从获取的监控数据中删除与regex不匹配的目标 source_labels
drop #从获取的监控数据中删除与regex匹配的目标 source_labels
范例：
#删除示例 metric_relabel_configs:
- source_labels: [__name__] #匹配标签
 regex: 'node_network_receive.*' #匹配标签值
 action: drop
#替换示例 metric_relabel_configs: - source_labels: [id]
 regex: '/.*'
 replacement: '123456'
 target_label: replace_id

• 指标抓取的生命周期

下图展示了Prometheus上进行指标抓取的简单生命周期

在每个scrape_interval(抓取周期)期间，Prometheus都会检查执行的作业（Job）；这些作业首先会根据Job上指定的发现配置生成target列表，此即服务发现过程；

#1 服务发现会返回一个Target列表，其中包含一组称为元数据的标签，这些标签都以"_ _medata_"为前缀；

#2 服务发现还会根据目标配置来设置其它标签，这些标签带有“__”前缀和后缀，包括

“__scheme__”、“__address__”和“__metrics_path__”，分别保存有target支持使用协议(http或 https，默认为http）、target的地址及指标的URI路径（默认为/metrics）；

#3 若URI路径中存在任何参数，则它们的前缀会设置为“__param_”

#4 这些目标列表和标签会返回给Prometheus，其中的一些标签也可以配置中被覆盖；

配置标签会在抓取的生命周期中被重复利用以生成其他标签，例如，指标上的instance标签的默认值就来自于__address__标签值；

第一个relabe_configs就是对target自身的标签重新标记，常见的target的标签有2个：instance和job，抓取前重新标记

第二个metric_relable_configs是对target抓取后的标签重新标记；

• 配置区别

relabel_config、metric_relabel_configs这两个配置虽然在作用上类似，但是他们还是有本质上的区别 的，这些区别体现在两个方面:执行顺序和数据处理上。

区别	解析
执行顺序	relabel_configs用与发现目标前的标签设置，也就是说在scrape_configs前生效，针对的target对象的标签 metric_relabel_configs 作用于scrape_configs生效后，即针对target对象上的监控数据的标签
数据处理	metric_relabel_configs 是 prometheus 在保存数据前的最后一步标签重新编辑，默认情况下，它将监控不需要的数据，直接丢掉，不在prometheus 中保存

4. 案例

4.1 relabel_configs

对target重新打标是在数据抓取之前动态重写target标签的强大工具，在每个数据抓取配置中，可以定义多个relabel步骤，它们将按照定义的顺序依次执行；

◆ 对于发现的每个target，Prometheus默认会执行如下操作

 job的标签设定为其所属的job_name的值；

 __address__标签的值为该target的套接字地址“<host>:<port>”

 instance标签的值为__address__的值；

 __scheme__标签的值为抓取该target上指标时使用的协议（http或https）；

 __metrics_path__标签的值为抓取该target上的指标时使用URI路径，默认为/metrics；

 __param_<name>标签的值为传递的URL参数中第一个名称为<name>的参数的值；

◆ 重新标记期间，还可以使用该target上以“___meta_”开头的元标签；

 各服务发现机制为其target添加的元标签会有所不同；

◆ 重新标记完成后，该target上以“__”开头的所有标签都会被移除；

 若在relabel的过程中需要临时存储标签值，则要使用__tmp标签名称为前缀进行保存，以避免同Prometheus的内建标签冲突；

4.1.1 修改新增标签或者已有标签的值---replace

#编辑prometheus.yml配置文件
[root@prometheus ~]#vim /usr/local/prometheus/conf/prometheus.yml 
scrape_configs:
...
 - job_name: 'k8s-node'
 static_configs:
 - targets: ['192.168.225.167:9100']
 - targets: ['192.168.225.112:9100']
 - targets: ['192.168.225.113:9100']
 - targets: ['192.168.225.114:9100']
 labels:
 name: shibosen
 class: m49
 relabel_configs:
 - source_labels: #匹配3个已有的标签
 - __scheme__
 - __address__
 - __metrics_path__
 regex: "(http|https)(.*)" #使用正则表达式过滤http或https，后面是任意字符，并分组
 separator: "" #默认使用封号连接$1和$2，此处使用空则表示不使用任何符号
 target_label: "endpoint" #如果原来有endpoint这个标签，那么就替换他的值为$1://$2，如果没有就新建
 replacement: "${1}://${2}"
 action: replace
#配置解析:separator 是设定拼接的时候用到的分隔符，我们这里不用设置任何符号
#重启服务
[root@prometheus ~]#systemctl restart prometheus.service

#浏览器查看效果

#结果显示:基于默认的属性重写了一个新的标签。

• 未修改前

• 修改后

4.1.2 基于已经存在的标签匹配，改名后删除原有的标签--labelmap&&labeldrop

#编辑prometheus.yml配置文件

[root@prometheus ~]#vim /usr/local/prometheus/conf/prometheus.yml 
scrape_configs:
...
 static_configs:
 - targets: ['192.168.225.167:9100']
 - targets: ['192.168.225.112:9100']
 - targets: ['192.168.225.113:9100']
 - targets: ['192.168.225.114:9100']
 labels: {app: 'k8s-node'}
 relabel_configs:
 - source_labels:
 - __scheme__
 - __address__
 - __metrics_path__
 regex: "(http|https)(.*)"
 separator: ""
 target_label: "endpoint"
 replacement: "${1}://${2}"
 action: replace
- regex: "(class|app)" #加下面三行,所有名为class或app的标签修改标签名称,但旧的标签还会存在
 replacement: ${1}_name
 action: labelmap
 - regex: "(class|app)" #加下面两行,则删除旧的标签,注意上面修改和此删除的前后顺序
 action: labeldrop
#配置解析:第一条规则基于现有的匹配内容重写标签名称，第二条规则，删除旧标签的名称 
#重启服务
[root@prometheus ~]#systemctl restart prometheus.service
#查看效果

#如下结果显示:第二条规则中，匹配到的标签就移除掉了

• 为修改前

• 修改后

4.1.3 删除target---drop

[root@prometheus ~]#vim /usr/local/prometheus/conf/prometheus.yml 
scrape_configs:
...
 static_configs:
 - targets: ['192.168.225.167:9100']
 - targets: ['192.168.225.112:9100']
 - targets: ['192.168.225.113:9100']
 - targets: ['192.168.225.114:9100']
 labels: {app: 'k8s-node'}
 relabel_configs:
 - source_labels:
 - __scheme__
 - __address__
 - __metrics_path__
 regex: "(http|https)(.*)"
 separator: ""
 target_label: "endpoint"
 replacement: "${1}://${2}"
 action: replace
 - regex: "(class|app)" #加下面三行,所有名为class或app的标签修改标签名称,但旧的标签还会存在
 replacement: ${1}_name
 action: labelmap
 - regex: "(class|app)" #加下面两行,则删除旧的标签,注意上面修改和此删除的前后顺序
 action: labeldrop
 - source_labels:
 - __address__ #注意，此处的下划线左右都是2个，不是1个
 regex: "192.168.225.167:9100"
 action: drop

• 修改前

• 修改后

需要注意的是：上面的几个范例都是修改的target的标签，也就是在修改抓取metrics之前的标签

4.2 metric_relabel_configs

对metric重新打标是在数据抓取之后动态重写metric标签的工具，在每个数据抓取配置中，可以定义多个metric relabel的步骤，它们将按照定义的顺序依次执行；

• 删除不必要的指标；
• 从指标中删除敏感或不需要的标签；
• 添加、编辑或修改指标的标签值或标签格式；

对metric重新打标的配置格式与target重新打标的格式相同，但前者要定义在专用的metric_relabel_configs字段中；

但是要注意的是，更改或添加标签会创建新的时间序列；

• 应该明确地使用各个标签，并尽可能保持不变，以避免创建出一个动态的数据环境；
• 标签是时间序列的唯一性约束，删除标签并导致时间序列重复时，可能会导致系统出现问题；

需要注意的是，对target重新打标和对metrics的操作方式和语法都是一致的，只不过前者是在relabel_configs下面操作，而后者是在metrics_relabel_configs下面操作

4.2.1 metric relabel之drop（删除指标）

在source_labels字段上，通过指标上元标签“name”引用指标名称，而后由regex（正则表达式）进行匹配判定，可使用drop action删除匹配的指标，或使用keep action仅保留匹配的指标；

◆ 下面的示例，用于在相应的job上，在发现的各target之上，删除以“go_info”为前名称前缀的指标

[root@prometheus ~]#vim /usr/local/prometheus/conf/prometheus.yml 
scrape_configs:
...
 static_configs:
 - targets: ['192.168.225.167:9100']
 - targets: ['192.168.225.112:9100']
 - targets: ['192.168.225.113:9100']
 - targets: ['192.168.225.114:9100']
 labels: {app: 'k8s-node'}
 relabel_configs:
 - source_labels:
 - __scheme__
 - __address__
 - __metrics_path__
 regex: "(http|https)(.*)"
 separator: ""
 target_label: "endpoint"
 replacement: "${1}://${2}"
 action: replace
 - regex: "(class|app)" #加下面三行,所有名为class或app的标签修改标签名称,但旧的标签还会存在
 replacement: ${1}_name
 action: labelmap
 - regex: "(class|app)" #加下面两行,则删除旧的标签,注意上面修改和此删除的前后顺序
 action: labeldrop
 - source_labels:
 - __address__ #注意，此处的下划线左右都是2个，不是1个
 regex: "192.168.225.167:9100"
 action: drop
 metric_relabel_configs:
 - source_labels:
 - __name__
 regex: "go_info.*" #匹配以go_info为前缀的指标
 action: drop

下面的第一个图为执行go_info为前缀的指标删除之前的查询结果，而第二个图则是删除相关指标之后的查询结果；

• 提示：若删除的指标此前曾由Prometheus抓取并存储过相关的样本数据，则删除操作的需要经过一定的时长后才会反映至查询结果中；

5. relabel_action详解

<relabel_action>字段用于定义重新标记的行为，其可用取值如下

⚫ replace：首先将source_labels中指定的各标签的值进行串连，而后将regex字段中的正则表达式对源标签值进行匹配判定，若匹配，则将target_label字段中指定的标签的值替换为replacement字段中保存的值；✓ replacement可按需引用保存regex中的某个“分组模式”匹配到的值；默认保存整个regex匹配到的内容；✓ 进行值替换时，replacememnt字段中指定标签的值也支持以分组格式进行引用；

⚫ hashmod：将target_label的值设置为一个hash值，该hash则由modules字段指定的hash模对块对source_labels上各标签的串连值进行hash计算生成； 删除指标：该处的每个指标名称对应一个target

⚫ keep：regex 不能匹配到target上的source_labels上的 各标签的串连值时，则删除该target；（仅用于relabel_configs）

⚫ drop：regex 能够匹配到target上的source_labels上的 各标签的串连值时，则删除该target；（仅用于relabel_configs）创建或删除指标标签

⚫ labelmap：将regex对所有的 标签名进行匹配判定，而后将匹配到的标签的值赋给replacement字段指定的标签名之上；通常用于取出匹配的标签名的一部分生成新标签；

⚫ labeldrop：将regex对所有的标签名进行匹配判定，能够匹配到的标签将从该target的标签集中删除；

⚫ labelkeep：将regex对所有的标签名进行匹配判定，不能匹配到的标签将从该target的标签集中删除；

◆ 注意：要确保在labeldrop或labelkeep操作后，余下的标签集依然能惟一标识该指标