环境,软件准备
本次演示环境,我是在虚拟机上安装 Linux 系统来执行操作,以下是安装的软件及版本:
- System: CentOS Linux release 7.6
- Docker: 24.0.5
- Prometheus: v2.37.6
- Consul: 1.6.1
注意:这里为了方便启动 Prometheus、Consul服务,我使用 Docker 方式启动,所以本机需要安装好 Docker 环境,这里忽略 Docker 的安装过程。其中 Prometheus 安装配置,可以参照之前文章?Prometheus 监控报警系统 AlertManager 之邮件告警,这里着重介绍一下如何启动并配置 Consul 并配置 Prometheus 基于 Consul 实现自动服务发现。
使用 Docker 启动 Consul 单节点服务,直接获取最新版官方镜像?consul:latest
?命令如下:
$ docker run --name consul -d -p 8500:8500 consul
启动完毕后,同上方法验证是否启动成功,这里为了方便演示,我采用 Docker 方式启动 Consul,这里的访问地址为:http://192.168.75.42:8500
接下来,我们要注册服务到 Consul 中,可以通过其提供的 API 标准接口来添加。那么先注册一个测试服务,该测试数据为本机?node-exporter
?服务信息,服务地址及端口为?node-exporter
?默认提供指标数据的地址,执行如下命令:
$curl -X PUT -d '{"id": "node-exporter","name": "node-exporter-192.168.75.42","address": "192.168.75.42","port": 9100,"tags": ["test"],"checks": [{"http": "http://192.168.75.42:9100/metrics", "interval": "5s"}]}' http://192.168.75.41:8500/v1/agent/service/register
提一下,如果要注销掉某个服务,可以通过如下 API 命令操作,例如注销上边添加的?node-exporter
?服务.这里的node-exporter事这个注册服务的ID
$curl -X PUT http://192.168.75.41:8500/v1/agent/service/deregister/node-exporter
现在 Consul 服务已经启动完毕,并成功注册了一个服务,接下来,我们需要配置 Prometheus 来使用 Consul 自动服务发现,目的就是能够将上边添加的服务自动发现到 Prometheus 的 Targets 中,增加?prometheus.yml
?配置如下:
- job_name: 'consul_exporter'
consul_sd_configs:
- server: '192.168.75.41:8500'
services: []
#重新加载prometheus服务
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus]$curl -X POST http://localhost:9090/-/reload
说明一下:这里需要使用?consul_sd_configs
?来配置使用 Consul 服务发现类型,server
?为 Consul 的服务地址,这里跟上边要对应上。 配置完毕后,重启 Prometheus 服务,此时可以通过 Prometheus UI 页面的 Targets 下查看是否配置成功。
这里说明下,在进行服务注册的时候ID是不可以重复出现的,如果重复出现的话那么这个ID要么会被替换成新的,要么会注册不成功.
可以看到,在 Targets 中能够成功的自动发现 Consul 中的 Services 信息,后期需要添加新的 Targets 时,只需要通过 API 往 Consul 中注册服务即可,Prometheus 就能自动发现该服务,是不是很方便。
- 会发现 Prometheus 同时加载出来了默认服务 consul,这个是不需要的。
- 默认只显示 job 及 instance 两个标签,其他标签都默认属于?
before relabeling
?下,有些必要的服务信息,也想要在标签中展示,该如何操作呢?- 如果需要自定义一些标签,例如 team、group、project 等关键分组信息,方便后边 alertmanager 进行告警规则匹配,该如何处理呢?
- 所有 Consul 中注册的 Service 都会默认加载到 Prometheus 下配置的?
consul_prometheus
?组,如果有多种类型的 exporter,如何在 Prometheus 中配置分配给指定类型的组,方便直观的区别它们?
以上问题,我们可以通过 Prometheus 配置中的?relabel_configs
?参数来解决。
我们先来普及一下?relabel_configs
?的功能, Prometheus 允许用户在采集任务设置中,通过?relabel_configs
?来添加自定义的 Relabeling 的额过程,来对标签进行指定规则的重写。 Prometheus 加载 Targets 后,这些 Targets 会自动包含一些默认的标签,Target 以?__
?作为前置的标签是在系统内部使用的,这些标签不会被写入到样本数据中。眼尖的会发现,每次增加 Target 时会自动增加一个 instance 标签,而 instance 标签的内容刚好对应 Target 实例的?__address__
?值,这是因为实际上 Prometheus 内部做了一次标签重写处理,默认?__address__
?标签设置为?<host>:<port>
?地址,经过标签重写后,默认会自动将该值设置为 instance 标签,所以我们能够在页面看到该标签。
详细?relabel_configs
?配置及说明可以参考?relabel_config?官网说明,这里我简单列举一下里面每个?relabel_action
?的作用,方便下边演示。
- replace: 根据 regex 的配置匹配?
source_labels
?标签的值(注意:多个?source_label
?的值会按照 separator 进行拼接),并且将匹配到的值写入到?target_label
?当中,如果有多个匹配组,则可以使用?1,1,{2} 确定写入的内容。如果没匹配到任何内容则不对?target_label
?进行重新, 默认为 replace。- keep: 丢弃?
source_labels
?的值中没有匹配到 regex 正则表达式内容的 Target 实例- drop: 丢弃?
source_labels
?的值中匹配到 regex 正则表达式内容的 Target 实例- hashmod: 将?
target_label
?设置为关联的?source_label
?的哈希模块- labelmap: 根据 regex 去匹配 Target 实例所有标签的名称(注意是名称),并且将捕获到的内容作为为新的标签名称,regex 匹配到标签的的值作为新标签的值
- labeldrop: 对 Target 标签进行过滤,会移除匹配过滤条件的所有标签
- labelkeep: 对 Target 标签进行过滤,会移除不匹配过滤条件的所有标签
接下来,我们来挨个处理上述问题。
relabel_configs
?来实现标签过滤,只加载符合规则的服务。以上边为例,可以通过过滤?__meta_consul_tags
?标签为?test
?的服务,relabel_config
?向 Consul 注册服务的时候,只加载匹配 regex 表达式的标签的服务到自己的配置文件。修改?prometheus.yml
?配置如下:
- job_name: 'consul_exporter'
consul_sd_configs:
- server: '192.168.75.41:8500'
services: []
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*test.*
action: keep
解释下,这里的?relabel_configs
?配置作用为丢弃源标签中?__meta_consul_tags
?不包含?test
?标签的服务,__meta_consul_tags
?对应到 Consul 服务中的值为?"tags": ["test"]
,默认 consul 服务是不带该标签的,从而实现过滤。重启 Prometheus 可以看到现在只获取了?node-exporter-75.42
?这个服务了,
可以归为一类,就是将系统默认标签或者用户自定义标签转换成可视化标签,
方便查看及后续 Alertmanager 进行告警规则匹配分组。不过要实现给服务添加自定义标签,我们还得做一下修改,就是在注册服务时,将自定义标签信息添加到 Meta Data 数据中,具体可以参考 [这里](Consul Service - Agent HTTP API) 官网说明,下边来演示一下如何操作。
新建?consul-0.json
?如下:
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$cat consul-0.json
{
"ID": "node-exporter",
"Name": "node-exporter-192.168.75.41",
"Tags": [
"test"
],
"Address": "192.168.75.41",
"Port": 9100,
"Meta": {
"app": "spring-boot",
"team": "appgroup",
"project": "bigdata"
},
"EnableTagOverride": false,
"Check": {
"HTTP": "http://192.168.75.41:9100/metrics",
"Interval": "10s"
},
"Weights": {
"Passing": 10,
"Warning": 1
}
}
说明一下:该 Json 文件为要注册的服务信息,同时往 Meta 信息中添加了 app=spring-boot,team=appgroup,project=bigdata 三组标签,目的就是为了方便告警分组使用。执行如下命令进行注册:
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$curl --request PUT --data @consul-0.json http://192.168.75.41:8500/v1/agent/service/register?replace-existing-checks=1
注册完毕,通过 Consul Web 管理页面可以查看到已注册成功,并且包含了 Meta 信息。
?然后修改?prometheus.yml
?配置如下:
- job_name: 'consul_exporter'
consul_sd_configs:
- server: '192.168.75.41:8500'
services: []
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*test.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
#重新加载prometheus配置
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus]$curl -X POST http://localhost:9090/-/reload
解释一下,增加的配置作用为匹配?
__meta_consul_service_metadata_
?开头的标签,将捕获到的内容作为新的标签名称,匹配到标签的的值作为新标签的值,而我们刚添加的三个自定义标签,系统会自动添加?__meta_consul_service_metadata_app=spring-boot
、__meta_consul_service_metadata_team=appgroup
、__meta_consul_service_metadata_project=bigdata
?三个标签,经过 relabel 后,Prometheus 将会新增?app=spring-boot
、team=appgroup
、project=bigdata
?三个标签。重启 Prometheus 服务,可以看到新增了对应了三个自定义标签。
本质上跟上边的处理方式一致,可以添加自定义的标签方式,通过标签来区分,二可以通过服务 Tag 来进行匹配来创建不同的类型 exporter 分组。这里我以第二种为例,通过给每个服务标记不同的 Tag,然后通过?relabel_configs
?来进行匹配区分。我们来更新一下原?node-exporter-192.168.75.42
?服务标签,同时注册一个其他类型 exporter 的服务如下:
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$cat consul-0.json
{
"ID": "node-exporter",
"Name": "node-exporter-192.168.75.41",
"Tags": [
"node-exporter"
],
"Address": "192.168.75.41",
"Port": 9100,
"Meta": {
"app": "spring-boot",
"team": "appgroup",
"project": "bigdata"
},
"EnableTagOverride": false,
"Check": {
"HTTP": "http://192.168.75.41:9100/metrics",
"Interval": "10s"
},
"Weights": {
"Passing": 10,
"Warning": 1
}
}
#更新注册服务
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$curl --request PUT --data @consul-0.json http://192.168.75.41:8500/v1/agent/service/register?replace-existing-checks=1
这里说明下,最后的checks参数表示如果重复那么就覆盖更新
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$cat consul2.json
{
"ID": "cadvisor-exporter-test",
"Name": "cadvisor-exporter-192.168.75.42",
"Tags": [
"cadvisor-exporter"
],
"Address": "192.168.75.42",
"Port": 8080,
"Meta": {
"app": "docker",
"team": "cloudgroup",
"project": "docker-service"
},
"EnableTagOverride": false,
"Check": {
"HTTP": "http://192.168.75.42:8080/metrics",
"Interval": "10s"
},
"Weights": {
"Passing": 10,
"Warning": 1
}
}
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus/test]$curl --request PUT --data @consul2.json http://192.168.75.41:8500/v1/agent/service/register?replace-existing-checks=1
?查看注册情况
最后,我们修改?prometheus.yml
?配置如下:
- job_name: 'consul_exporter'
consul_sd_configs:
- server: '192.168.75.41:8500'
services: []
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*node-exporter.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
- job_name: 'cadvisor-exporter-test'
consul_sd_configs:
- server: '192.168.75.41:8500'
services: []
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*cadvisor-exporter.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
#重新加载prometheus配置
[root@node1-prome /zpf/k8s/prometheus/docker-prometheus/prometheus]$curl -X POST http://localhost:9090/-/reload
这里需要根据每种类型的 exporter 新增一个关联 job,同时?relabel_configs
?中配置以 Tag 来做匹配区分。重启 Prometheus 服务,可以看到服务已经按照类型分类了,方便查看。