Prometheus服务发现介绍
Prometheus默认是采用pull的方式拉取监控数据的,每一个被抓取的目标都要暴露一个HTTP接口,prometheus通过这个接口来获取相应的指标数据,这种方式需要由prometheus-server决定采集的目标服务器有哪些,通过配置在scrape_configs中的各种job来实现,无法动态感知新服务,如果后面新增了节点或组件,就需要手动修改prometheus配置,然后重启服务或重新加载配置,所以出现了动态服务发现。
动态服务发现能够自动发现集群中的新端点,并加入到配置中,通过服务发现prometheus能够自动获取需要监控的targets列表,然后通过这些targets获取监控数据。
Prometheus获取数据源target的方式有多种,包括静态配置和动态服务发现配置。prometheus目前支持的服务发现有很多种,具体可以参考prometheus的配置文档:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#configuration-file
常用的主要有以下几种:
- kubernetes_sd_configs:基于Kubernetes API实现的服务发现,让prometheus动态发现kubernetes中的被监控目标
- static_configs:静态服务发现,基于prometheus配置文件指定监控目标
- dns_sd_configs:基于DNS服务发现监控目标
- consul_sd_configs:基于Consul服务动态发现监控目标
- file_sd_configs:基于指定的文件发现监控目标
relabeling功能
relabeling简介
在Prometheus动态发现的targets中默认都包含一些原始的metadata标签信息,例如通过Kubernetes API动态发现的目标就包含许多以__meta开头的标签,如下图:
标签含义:
- _address_:以:信息显示目标targets的地址
- _scheme_:采集的目标服务器的Scheme形式,HTTP或等
- _metrics_path_:采集的目标服务器的访问路径
其它标签的含义可以参考Prometheus的官方配置文档。
prometheus的relabeling(标签重写)功能,它允许用户重写这些标签或根据标签做一些过滤操作。目前支持的relabel配置主要有以下4中,它的应用范围和生效时间不一样:
- relabel_configs:在对target进行数据采集之前,可以使用relabel_configs添加、修改或删除一些标签,也可以用来配置只采集特定目标或过滤目标,针对的是target,监控目标
- metric_relabel_configs :在对target采集数据之后,数据写入TSDB之前,可以使用metric_relabel_configs做重新标记和过滤,针对的是metric,指标
- alert_relabel_configs:在被发送到alertmanager之前,对标签进行处理,针对的是alert
- write_relabel_configs:写入远端存储之前进行标签处理
其中较为常用的就是relabel_configs,在配置监控目标时使用。后面介绍的也是relabel_configs
relabeling规则
Relabeling规则主要由以下字段组成:
字段 | 作用 |
---|---|
source_labels | 源标签,没有经过relabel处理之前的标签名 |
separator | 分隔符,一个字符串,用于在连接源标签source_labels时分隔它们,默认是分号; |
target_label | 通过action处理之后新的标签名字 |
regex | 给定的值或正则表达式,用来匹配源标签的值 |
action | 对源标签执行的relabeling动作,可选值和作用参考下个表格 |
modules | 模数,串联的源标签哈希值的模,主要用于 Prometheus 水平分片 |
replacement | 写在目标标签上,它可以引用regex正则表达式匹配的组$1、$2… |
action字段可用的值和含义如下:
replace | 设置或替换标签值,是默认的action |
keep | 源标签值满足regex正则条件的实例进行采集,其它实例丢弃,即只采集成功匹配的实例 |
drop | 作用和keep相反,即只采集未匹配的实例 |
labelmap | 将源标签的值映射到一组新的标签中去,action为labelmap时,regex匹配的是标签名,而不是标签值 |
labelkeep | 保留匹配的标签,其它的进行删除 |
labeldrop | 删除匹配的标签,保留不匹配的标签 |
hashmod | 使用hashmod计算源标签的hash值并进行对比,基于自定义的魔术取模,以实现对目标进行分类、重新赋值等 |
基于Kubernetes API的Prometheus服务发现
可以在prometheus配置文件的job中使用kubenetes_sd_configs字段来配置基于Kubernetes API的服务发现,具体配置方式可以参考官网:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config
目前支持的发现目标类型有以下几种:
- node:发现node节点
- service:发现service
- pod:发现Pod
- enpoints:通过endpoints获取监控目标
- endpointslice:通过endpointslice获取监控目标
- ingress:发现ingress
下面分别是一些对应的的示例
apiserver服务发现及监控
apiserver作为集群如入口,所有请求都是通过apiserver进来的,所以对apiserver指标做监控可以用来判断集群健康状态。我们可以通过目标类型为endpoints的kubenetes_sd_configs配置来自动发现apiserver并监控。
这里因为prometheus-server是部署在k8s集群上的,配置保存在configmap中,所以修改对应的configmap,内容如下:
kind: ConfigMap
apiVersion: v1
metadata:
labels:
app: prometheus
name: prometheus-config
namespace: monitoring
data:
prometheus.yml: |
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 1m
scrape_configs:
- job_name: kubernetes_apiserver #添加此job
kubernetes_sd_configs:
- role: endpoints #指定kubernetes_sd_configs发现角色为endpoint
scheme: https #指定访问apiserver协议
tls_config: #apiserver证书。证书和token都是通过ServiceAccount注入到Prometheus-server Pod中的
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
authorization: #访问apiserver的token
credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs: #标签重写规则配置
- source_labels: ["__meta_kubernetes_namespace", "__meta_kubernetes_endpoints_name", "__meta_kubernetes_endpoint_port_name"] #指定要匹配的源标签
regex: default;kubernetes;https #匹配规则,这里表示只匹配名称空间为default,endpoints名称为kubernetes,且端口名称为https的实例
action: keep #action为keep,表示匹配的实例保留,然后进行监控
修改完成后,将configmap重新应用的集群中,然后重新加载prometheus配置。
kubectl apply -f prometheus-config.yaml
#重新创建prometheus Pod
kubectl delete pods/prometheus-aswcgth
之后就可以在prometheus界面上看到已经自动发现了3个apiserver,状态都为UP
在Grafana导入模板来查看apiserver监控数据, 模板ID 12006
#查询API Server最近10分钟不同方法的请求数量总计
sum(rate(apiserver_request_total[10m])) by (resource,subresource,verb)
coredns服务发现及监控
修改保存prometheus配置的configmap,添加一个job,内容如下:
- job_name: "kubernetes-service-endpoints"
kubernetes_sd_configs:
- role: endpoints
relabel_configs: #标签重写规则
#如果endpoints对应的service资源上存在注解prometheus.io/scrape=true时,目标实例才会被发现为target
- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_scrape"] #
regex: true
action: keep
#通过service资源的注解prometheus.io/scheme获得抓取目标实例的数据时使用的协议(http或https),并赋值给新标签__scheme__
- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_scheme"]
regex: (https?)
action: replace
target_label: __scheme__
#通过service资源的注解prometheus.io/path获取目标实例提供监控数据的url路径,并赋值给新标签__metrics_path__
- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_path"]
regex: (.+)
action: replace
target_label: __metrics_path__
#修改__address__标签的值,即目标实例的地址和端口
- source_labels: ["__address__", "__meta_kubernetes_service_annotation_prometheus_io_port"]
regex: ([^:]+)(?::\d+)?;(\d+)
action: replace
target_label: __address__
replacement: $1:$2
#保留原来存在的以__meta_kubernetes_service_label_开头的标签
- regex: __meta_kubernetes_service_label_(.+)
action: labelmap
#将标签__meta_kubernetes_service_name修改为 kubernetes_service_name
- source_labels: ["__meta_kubernetes_service_name"]
action: replace
target_label: kubernetes_service_name
#将标签__meta_kubernetes_namespace修改为 kubernetes_namespace
- source_labels: ["__meta_kubernetes_namespace"]
action: replace
target_label: kubernetes_namespace
关于资源注解prometheus.io/scrape: true,需要在被发现的目的target定义此注解,且必须匹配成功该注解才会保留监控target,然后再进行数据抓取并进行标签替换,如annotation_prometheus_io_scheme标签为http或https。
修改完成后,将configmap重新应用的集群中,然后重新加载prometheus配置。步骤同上。
然后在prometheus界面查看,就可以看到已经发现了coredns对应的的Pod为target,状态为UP。如下图:
在Grafana导入coredns模板,查看监控数据,模板ID 14981