Prometheus服务发现

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: prometheusname: prometheus-confignamespace: monitoring
data:prometheus.yml: |global:scrape_interval: 15sscrape_timeout: 10sevaluation_interval: 1mscrape_configs:- job_name: kubernetes_apiserver	 #添加此jobkubernetes_sd_configs:- role: endpoints		#指定kubernetes_sd_configs发现角色为endpointscheme: https		#指定访问apiserver协议tls_config:	#apiserver证书。证书和token都是通过ServiceAccount注入到Prometheus-server Pod中的ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crtauthorization:	#访问apiserver的tokencredentials_file: /var/run/secrets/kubernetes.io/serviceaccount/tokenrelabel_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: endpointsrelabel_configs:	#标签重写规则#如果endpoints对应的service资源上存在注解prometheus.io/scrape=true时，目标实例才会被发现为target- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_scrape"]	#regex: trueaction: keep#通过service资源的注解prometheus.io/scheme获得抓取目标实例的数据时使用的协议（http或https），并赋值给新标签__scheme__- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_scheme"]regex: (https?)action: replacetarget_label: __scheme__#通过service资源的注解prometheus.io/path获取目标实例提供监控数据的url路径，并赋值给新标签__metrics_path__- source_labels: ["__meta_kubernetes_service_annotation_prometheus_io_path"]regex: (.+)action: replacetarget_label: __metrics_path__#修改__address__标签的值，即目标实例的地址和端口- source_labels: ["__address__", "__meta_kubernetes_service_annotation_prometheus_io_port"]regex: ([^:]+)(?::\d+)?;(\d+)action: replacetarget_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: replacetarget_label: kubernetes_service_name#将标签__meta_kubernetes_namespace修改为 kubernetes_namespace- source_labels: ["__meta_kubernetes_namespace"]action: replacetarget_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