Kubernetes监控体系（5）-prometheus服务发现简介

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

static_configs：静态服务发现
kubernetes_sd_configs: 基于Kubernetes的服务发现，这章讲的内容
consul_sd_configs: Consul 服务发现
dns_sd_configs: DNS 服务发现
file_sd_configs: 文件服务发现

promethues的静态静态服务发现static_configs：每当有一个新的目标实例需要监控，我们都需要手动配置目标target
promethues的consul服务发现consul_sd_configs：Prometheus 一直监视consul服务，当发现在consul中注册的服务有变化，prometheus就会自动监控到所有注册到consul中的目标资源
promethues的k8s服务发现kubernetes_sd_configs：Prometheus与Kubernetes的API进行交互，动态的发现Kubernetes中部署的所有可监控的目标资源。

Prometheus的relabel_configs：
promethues的relabeling（重新修改标签）功能很强大，它能够在抓取到目标实例之前把目标实例的元数据标签动态重新修改，动态添加或者覆盖标签
prometheus加载target成功之后，在Target实例中，都包含一些Metadata标签信息，默认的标签有：
__address__：以: 格式显示目标targets的地址
__scheme__：采集的目标服务地址的Scheme形式，HTTP或者HTTPS
__metrics_path__：采集的目标服务的访问路径

Prometheus怎么从Target实例中获取监控数据就是通过上面这些标签获取得，上面列举的是一些默认标签，我们还可以为Target添加一些自定义的标签，我们可以在配置文件中设置relabeling重写规则

relabel_configs配置详细说明：
action：action定义了relabel的动作，action支持多种，如下

replace: 替换标签值，根据regex正则匹配到源标签的值，并把匹配的值写入到目的标签中
keep: 满足regex正则条件的实例进行采集，把source_labels中没有匹配到regex正则内容的Target实例丢掉
drop： 满足regex正则条件的实例不采集，把source_labels中匹配到regex正则内容的Target实例丢掉
labeldrop：  对抓取到的符合过滤规则的target标签进行删除
labelkeep：  对抓取到的符合过滤规则的target标签进行保留

source_labels：源标签，没有经过relabel处理之前的标签名字
target_label：通过action处理之后的新的标签名字
regex：正则表达式，匹配源标签
replacement：replacement指定的替换后的标签（target_label）对应的数值

labelmap会根据regex的定义去匹配Target实例所有标签的名称，并且以匹配到的内容为新的标签名称，其值作为新标签的值

1.node-exporter服务发现kubernetes_sd_configs配置

    - job_name: 'kubernetes-node'

      kubernetes_sd_configs:

      - role: node

      relabel_configs:

      - source_labels: [__address__]

        regex: '(.*):10250'

        replacement: '${1}:9100'

        target_label: __address__

        action: replace

      - action: labelmap

        regex: __meta_kubernetes_node_label_(.+)

 

每个节点都需要运行了node-exporter程序，如果我们通过一个Server来将数据收集在一起，用静态的方式配置到prometheus就会显示一条数据，我们得自己在指标中过滤每个节点的数据，配置比较麻烦；

这里就需要采用服务发现配置，在Kubernetes下，Prometheus通过Kubernetes API基础，目前主要支持5种服务发现，分别是node、Server、Pod、Endpoints、Ingress，通过制定Kubernetes_sd_config的模式为node，prometheus就会自动从Kubernetes中发现所有的node节点并作为当前job监控的目标实例，发现的节点/metrics接口是默认的kubelet的HTTP接口，但是由于metrics监听的端口是10250而并不是我们设置的9100，这里我们就需要使用Prometheus提供的relabel_configs中的replace能力了；

 

relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值，这里使用__address__标签替换10250端口为9100；

 

添加了一个action为labelmap，正则表达式是__meta_kubernetes_node(.+)的配置，这里的意思就是表达式中匹配的数据也添加到指标数据的Label标签中去。；

实际上就是获取我们的标签就是用kubectl get nodes --show-labels获取到的标签

NAME         STATUS   ROLES    AGE    VERSION   LABELS

k8s-master   Ready    master   2d4h   v1.16.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=

k8s-node     Ready       2d4h   v1.16.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node,kubernetes.io/os=linux

对于Kubernetes_sd_configs下面可用的元标签如下

__meta_kubernetes_node_name: 节点对象的名称

_meta_kubernetes_node_label: 节点对象中的每个标签

_meta_kubernetes_node_annotation: 来自节点对象的每个注释

_meta_kubernetes_node_address: 每个节点地址类型的第一个地址(如果存在)