一、prometheus 的服务发现机制
prometheus 默认是采用 pull 方式拉取监控数据的， 也就是定时去目标主机上抓取 metrics 数据， 每一个被抓取的目标需要暴露一个 HTTP 接口， prometheus通过这个暴露的接口就可以获取到相应的指标数据，
这种方式需要由目标服务决定采集的目标有哪些， 通过配置在 scrape_configs 中的各种 job 来实现， 无法动态感知新服务， 如果后面增加了节点或者组件信息， 就得手动修 promrtheus配置，
并重启 promethues， 很不方便， 所以出现了动态服务发现， 动态服务发现能够自动发现集群中的新端点， 并加入到配置中， 通过服务发现， Prometheus能查询到需要监控的 Target 列表， 然后轮询这些 Target 获取监控数据。prometheus 获取数据源 target 的方式有多种，如静态配置和动态服务发现配置，prometheus 目前支持的服务发现有很多种， 常用的主要分为以下几种：
1.kubernetes_sd_configs: #基于 Kubernetes API 实现的服务发现， 让 prometheus 动态发现 kubernetes 中被监控的目标
2.static_configs: #静态服务发现， 基于 prometheus 配置文件指定的监控目标，每当有一个新的目标实例需要监控， 都需要手动修改配置文件配置目标 target。
3.dns_sd_configs: #DNS 服务发现监控目标
4.consul_sd_configs: #Consul 服务发现， 基于 consul 服务动态发现监控目标
5.file_sd_configs: #基于指定的文件实现服务发现， 基于指定的文件发现监控目标，相比较于静态服务发现，使用文件服务发现可以不重启prometheus服务
参考文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/ #所有 *_sd_config> 为当前支持的自动发现的配置
二、prometheus 标签修改(relabeling)
promethues 的 relabeling（重新修改标签） 功能很强大， 它能够在抓取到目标实例之前把目标实例的元数据标签动态重新修改， 动态添加或者覆盖标签 prometheus 动态发现目标(targer)之后， 在被发现的 target 实例中， 都包含一些原始的Metadata 标签信息， 默认的标签有： __address__： 以<host>:<port> 格式显示目标 targets 的地址 __scheme__： 采集的目标服务地址的 Scheme 形式， HTTP 或者 HTTPS __metrics_path__： 采集的目标服务的访问路径
1.label重新标记
为了更好的识别监控指标,便于后期调用数据绘图、 告警等需求， prometheus 支持对发现的目标进行 label 修改， 在两个阶段可以重新标记：
relabel_configs ： 在对 target 进行数据采集之前（比如在采集数据之前重新定义标签信息， 如目的 IP、目的端口等信息） ， 可以使用 relabel_configs 添加、 修改或删除一些标签、 也可以只采集特定目标或过滤目标。
metric_relabel_configs： 在对 target 进行数据采集之后， 即如果是已经抓取到指标数据时， 可以使用metric_relabel_configs 做最后的重新标记和过滤。流程如下
如上一篇文章总prometheus kubernetes_sd_configs服务自动发现中对api-server抓取的配置
- job_name: 'kubernetes-apiserver' #kubernetes_sd_configs: #基于 kubernetes_sd_configs 实现服务发现- role: endpoints #发现 endpoints，还有 node svc pod ingress等其他rolescheme: https #当前 jod 使用的发现协议tls_config: #证书配置ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt #容器里的证书路径,默认内置存在 为集群ca证书的公钥bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token #容器里的 token 路径，默认内置存在relabel_configs: #重新 re 修改标签 label 配置 configs- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] #源标签,即对哪些标签进行操作，不同的发现机制源标签也不相同，具体参考对应的发现机制官方文档action: keep #保留source_labels中标签，其他过滤，action 定义了 relabel 的具体动作， action 支持多种regex: default;kubernetes;https #与source_labels中对应，分别为名称空间 svc名称 svc中port的名称，注意此处是名称不是协议，协议在scheme字段配置，此处含义为发现 default 命名空间的 kubernetes 服务并且是 https 协议
2.label 详解
source_labels： 源标签， 没有经过 relabel 处理之前的标签名字
target_label： 通过 action 处理之后的新的标签名字
regex： 给定的值或正则表达式匹配， 匹配源标签
replacement： 通过分组替换后标签（target_label） 对应的值
3.action 详解
replace: 替换标签值， 根据 regex 正则匹配到源标签的值， 使用 replacement 来引用表达式匹配的分组 keep: 满足 regex 正则条件的实例进行采集， 把 source_labels 中没有匹配到 regex 正则内容的 Target 实例丢掉， 即只采集匹配成功的实例。 drop： 满足 regex 正则条件的实例不采集，把 source_labels 中匹配到 regex 正则内容的 Target 实例丢掉， 即只采集没有匹配到的实例。 hashmod： 使用 hashmod 计算 source_labels 的 Hash 值并进行对比， 基于自定义的模数取模， 以实现对 目标进行分类、 重新赋值等功能： scrape_configs: - job_name: ip_jobrelabel_configs: - source_labels: [__address__]modulus: 4target_label: __ip_hashaction: hashmod - source_labels: [__ip_hash]regex: ^1$action: keep labelmap： 匹配 regex 所有标签名称,然后复制匹配标签的值进行分组， 通过 replacement 分组引用 （${1},${2},…） 替代 labelkeep： 匹配 regex 所有标签名称,其它不匹配的标签都将从标签集中删除 labeldrop： 匹配 regex 所有标签名称,其它匹配的标签都将从标签集中删除
二、kubernetes_sd_configs服务自动发现
参考文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config
Kubernetes 服务发现配置允许从Kubernetes的REST API接口检索并抓取目标，且始终与集群状态保持同步
