prometheus服务发现

1、prometheus的服务发现机制

1.1服务发现的概念

prometheus 默认是采用 pull 方式拉取监控数据的，也就是定时去目标主机上抓取 metrics 数据，每一个被抓取的目标需要暴露一个 HTTP 接口，prometheus通过这个暴露的接口就可以获取到相应的指标数据，这种方式需要由目标服务决定采集的目标有哪些，通过配置在 scrape_configs 中的各种 job 来实现，无法动态感知新服务，如果后面增加了节点或者组件信息，就得手动修 promrtheus配置，并重启 promethues，很不方便，所以出现了动态服务发现，动态服务发现能够自动发现集群中的新端点，并加入到配置中，通过服务发现，Prometheus能查询到需要监控的 Target 列表，然后轮询这些 Target 获取监控数据。

修改标签的时机：

relabel_configs: 在抓取数据之前,可以使用relabel_configs添加一些标签,也可以值采集特定目标或过滤目标
metric_relabel_configs: 在抓取数据之后,可以使用metric_relabel_configs做最后的重新标记和过滤

1.2服务发现的方法

1.2.1静态服务发现

promethues 的静态静态服务发现 static_configs：每当有一个新的目标实例需要监控，都需要手动修改配置
文件配置目标 target。

1.2.2动态服务发现

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

• kubernetes_sd_configs: #Kubernetes 服务发现，让 prometheus 动态发现 kubernetes 中被监控的目标

  promethues 的 k8s 服务发现 kubernetes_sd_configs：Prometheus 与 Kubernetes 的 API 进行交互，动态的
  发现 Kubernetes 中部署的所有可监控的目标资源。
  

• dns_sd_configs: #DNS 服务发现监控目标

• consul_sd_configs: #Consul 服务发现，基于 consul 服务动态发现监控目标

  promethues 的 consul 服务发现 consul_sd_configs：Prometheus 一直监视 consul 服务，当发现在 consul
  中注册的服务有变化，prometheus 就会自动监控到所有注册到 consul 中的目标资源。
  

• file_sd_configs: #基于指定的文件实现服务发现，基于指定的文件发现监控目标

1.2.3 支持发现的目标

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

• node
• service
• pod
• endpoints
• endpointslice #对endpoint进行切片
• ingress

1.2.4label的详解

• source_label: 源标签，没有经过relabel处理之前的标签名字
• target_label:通过action动作处理之后的新的标签名字
• regex:正则表达式，匹配源标签
• replacement: 通过分组替换后的新标签（target_label)对应的值

1.2.5 action详解

• replace: 替 换 标 签 值 ， 根 据 regex 正 则 匹 配 到 源 标 签 的 值 ， 使用 用 replacement 来 引 用 表 达 式 匹 配 的

执行replace动作前

执行replace动作后

    global:
      scrape_interval: 15s
      scrape_timeout: 10s
      evaluation_interval: 1m
    scrape_configs:
      - job_name: "kubernetes-node"
        static_configs:
          - targets:  ['172.17.1.101:9100','172.17.1.102:9100']
            labels:
              app1: test:v1
              hostname__: k8s-cluster
        relabel_configs:
          - source_labels: ['app1']
            regex: '(.*):v1'  #正则匹配原标签（app1)的值
            replacement: '${1}:v2'  #重写正则匹配到的值，如test:v1替换成test:v2
            target_label: app1
            action: replace

• keep: 满足 足 regex 正 则 条 件 的 实 例 进 行 采 集 ， 把 source_labels 中 没 有 匹 配到 到 regex 正 则 内 容的 的 Target实 例 丢 掉 ， 即 只 采 集 匹 配 成 功 的 实 例

• drop：满足 regex 正则条件的实例不采集，把 source_labels 中匹配到 regex 正则内容的 Target 实例丢掉，
  即只采集没有匹配到的实例。

• labelmap: 匹配regex所有标签名称,然后赋值匹配标签的值进行分组,通过replacement分组引用替代 （将正则匹配到的值作为标签的名称使用，而标签的值继承原标签的值）

  没有执行labelmap之前：
  

  执行labelmap之后：

      scrape_configs:
        - job_name: "kubernetes-node"
          static_configs:
            - targets:  ['172.17.1.101:9100','172.17.1.102:9100']
              labels:
                app1: test1
                hostname__: k8s-cluster
          relabel_configs：       
             - source_labels: ['hostname__']
               regex: "host(.+)"
               action: labelmap  #"hostname__"这个标签名通过正则匹配到了“name”这个值，把name这个值作为新标签（target_label),新标签的值为源标签"hostname__"的值，故web界面显示为：name: k8s-cluster
  

  

• labelkeep: 匹配regex所有标签名称,其他不匹配的标签都将从标签集中删除

• labeldrop: 匹配regex所有标签名称,其他匹配的标签都将从标签集中删除

2、kubernetes_sd_config服务发现案例

2.1 监控kube-api组件

root@master1:~/app# cat configmap-prometheus.yaml 
---
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"
      kubernetes_sd_configs:
      - role: endpoints
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt #容器里的证书路径
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token #容器里的 token 路径
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name,__meta_kubernetes_endpoint_port_name] #源标签
        action: keep #action 定义了 relabel 的具体动作，action 支持多种
        regex:  default;kubernetes;https #发现了 default 命名空间的 kubernetes 服务切是 https 协议

关于服务发现匹配这块内容研究了七八天，最终在借助这个老兄的文章才把新增的疑惑接除，我这里还有很多小细节我就没细写了。
这部分的实验后面再补上。
细节可以借助这篇博客来理解：http://t.csdnimg.cn/XRCBz