prometheus__meta_kubernetes_namespace赋值给多个label prometheus 自定义metric prometheus relabel_configs

写在之前

prometheus 配置文件大体框架有以下几个部分：

data:
  prometheus.yml: | #
    rule_files:
    - etc/prometheus/rules.yml
    alerting:
      alertmanagers:
      - static_configs:
        - targets: ["localhost:9093"]
    global:
      scrape_interval: 15s
      scrape_timeout: 10s
      evaluation_interval: 1m
    scrape_configs:
    - job_name: 'kubernetes-node'
      ....

   rules.yml: |
     groups:
     - name: example
       rules:
       - alert: kubernetes-apiserver打开句柄数>1000
         ...
     - name: 物理节点状态-监控告警
       rules:
       - alert: 物理节点cpu使用率
         ...

 

包括两个文件：prometheus配置文件（prometheus.yaml）和 规则文件 （rules.yml）。

Prometheus配置文件，主要配置加载规则文件的路径，报警服务器的连接配置、全局配置、和抓取目标服务器的配置信息，这里会主要讲解抓取规则。

规则文件这里通过分组的形式进行监控，在监控页面也可以很好的展示；

 

prometheus 配置文件中global

Global	含义
scrape_interval: 15s	收集目标数据的时间间隔，可以使用全局配置，也可以基于某个Job_name配置，默认为15秒，
scrape_timeout: 10s	目标采集超时时间，默认为10秒；
evaluation_interval: 1m	报警状态更新间隔时间，默认1分钟；

上面说的报警状态，主要有三个，第一篇文章中有提到，这里加深下理解，再次给出。

告警状态	功能
pending	警报通知已经被激活，但低于配置的持续时间，这里的持续时间即rule里的FOR字段设置的时间，在此状态下，不发送报警通知
firing	警报通知已经发送，而且超出设置的持续时间，该状态下发送报警通知
inactive	正常状态，既不是pending也不是firing的时候状态即inactive

 

prometheus 服务发现方式

Prometheus 默认是采用Pull的方式拉取指标数据，那么它是如何知道拉取哪些目标服务的指标数据呢？其实就是通过配置 scrape_configs来定义各种Job来实现目标服务发现的，配置一个job_name后，这个指定的名称就会在Prometheus UI界面 Targets中显示出来，那么我们监控的目标有很多，尤其是Pod、Service这些经常变动的，我们又应该如何来配置管理 呢，下面我们来看Prometheus 中服务发现几种方式：

Prometheus 服务发现	含义
dns_sd_configs	基于DNS 服务发现；
file_sd_configs	基于文件服务发现；
static_configs	静态服务发现，这个很好理解，比如我们的kube-apiserver、kube-controller-manager、kube-scheduler、Etcd等这些资源相对固定，不会经常性的发生变化，每当有新的目标需要监控时，需要手动配置监控目标服务；
kubernetes_sd_configs	基于Kubernetes的服务发现，比如Pod、Service，这种也叫基于API的动态服务发现；
consul_sd_configs	使用第三方组件Consul ，完成动态服务发现，Prometheus 一直监视consul服务，当发现在consul中注册的服务有变化，prometheus就会自动把注册到consul中的目标资源的变化同步到Prometheus的Targets中来；

 

基于API的服务发现：kubernetes_sd_configs

Prometheus 集成了 Kubernetes 的自动服务发现，通过 kube-apiserver 提供的5种模式API来动态服务发现，它们分别是：基于 Node、Service、Pod、Endpoints以及基于ingress的服务发现；

下面给出 Kubernetes 服务发现的实例，这里会使用大量的 relabel_configs 标签，它主要是重新修改标签，它仅仅是对采集过来的指标进行二次处理，我们要什么、不要什么、如何替换等，把以__meta__、__address__、__scheme__或者以__metrics_path__开头的这些元数据标签进行动态的修改、更新、添加、删除操作；

 

relabel_configs action动作有如下几种：

relabel_configs action动作	含义
replace	根据regex来去匹配source_labels标签上的值，并将并将匹配到的值写入target_label中，其实就是替换；
keep	只是收集匹配到regex的源标签source_labels，而会丢弃没有匹配到的所有标签，用于选择保留哪些标签；
drop	丢弃匹配到regex的源标签，而会收集没有匹配到的所有标签，用于排除，与keep相反；
labeldrop	使用regex表达式匹配标签，符合规则的标签将从target实例中移除；
labelkeep	使用regex表达式匹配标签，仅收集符合规则的target，不符合匹配规则的不收集；
labelmap	根据regex的定义去匹配Target实例所有标签的名称，并且以匹配到的内容为新的标签名称，其值作为新标签的值；

几种动作中提到的几个术语解析：

source_labels：字面意思是源标签，没有经过relabel处理之前的标签名；

target_label：目标标签，通过action动作处理之后的新的标签名；

regex：正则表达式，用于匹配源标签值使用的；

replacement：replacement指定的替换后的标签（target_label）对应的数值；

scheme: https、http等代表获取指标数据时使用的协议类型；

 

prometheus WebUI  targets中的endpoints组成：

__scheme__://__address__/__metrics__path__

__scheme__，默认是http，不特别指明，就是http；

__address__，不特别说明也是抓取到源标签中的指标值；

__metrics__path__，默认是/metrics，除非特别指明；

 

Node 服务发现

主要监控Node节点的指标数据

- 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_(.+)

 

job_name 是为监控的目标定义一个标识名称，显示在WebUI界面的Targets中；

kubernetes_sd_configs 代表这是基于kubernetes API进行的动态服务发现方式；

role 指的是使用哪种类型的API，上面已经说过基于5种不同类型API来实现动态服务发现，这里指的是node；

relables_configs 重新修改标签的配置，

 

source_labels：__address__="172.31.117.233:10250"；

reges:  正则表达式，用于匹配源标签值使用的，这里源标签值是172.31.117.233:10250，通过正则表达式(.*):10250，匹配出来的结果是172.31.117.233；

replacement：替换后标签对应的值172.31.117.233:9100，其实就是 WebUI中Endpoint的数据；

action：replace即替换动作；

labelmap：__meta_kubernetes_node_label_(.+)，根据regex的定义去匹配Target实例所有标签的名称，并且以匹配到的内容为新的标签名称，其值作为新标签的值，其实新的标签值即是 WebUI 界面中显示的；

 

 

API Server服务发现

- 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
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_
service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https

 

job_name 在WebUI中 Targets中显示的名称；

kubernetes_sd_configs 代表这是基于kubernetes API进行的动态服务发现方式；

role，指的是使用哪种类型的API，上面已经说过基于5种不同类型API来实现动态服务发现，这里指的是endpoints，这里也有一些默认的配置；

scheme，抓取数据时使用的协议类型为https；

tls_config和bearer_token_file，都是使用https进行获取数据使用的认证文件；

source_lables，动态服务发现kube-apiserver时，根据源标签进行一次过滤，把符合的target先过滤出来；

reges，根据正则去过滤哪个源标签被匹配出来，再结合keep动作，它能唯一的表示出是我们监控的对象；

action，keep就是保留符合正则表达式的targets，并显示出来；

 

node-cadvisor 动态服务发现

主要是监控容器的指标数据；

- job_name: 'kubernetes-node-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: var/run/secrets/kubernetes.io/serviceaccount/
token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

 

job_name，在WebUI中 Targets中显示的名称；

kubernetes_sd_configs 代表这是基于kubernetes API进行的动态服务发现方式；

role 指的是使用哪种类型的API，上面已经说过基于5种不同类型API来实现动态服务发现，这里指的是node；

scheme，抓取数据时使用的协议类型为https；

tls_config和bearer_token_file，都是使用https进行获取数据使用的认证文件；

source_labels，通过regex 匹配出来 master01，把__metrics_path__默认值 metrics 替换成replacement成/api/v1/nodes/${1}/proxy/metrics/cadvisor，这里的$1由master01再次替换，

target_label，__address__它直接replacement 替换成kubernetes.default.svc:443；

 

 

Service 动态服务发现

要想让service自动服务发现，必须在注解中声明prometheus.io/port: "9153"和prometheus.io/scrape: "true"，默认是9153端口，可以不声明，但prometheus.io/scrape必须声明，还有一个前提你后面Pod 需要暴露了/metrics接口，否则也监控不到；

- job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name

 

job_name，在WebUI中 Targets中显示的名称；

kubernetes_sd_configs 代表这是基于kubernetes API进行的动态服务发现方式；

role 指的是使用哪种类型的API，上面已经说过基于5种不同类型API来实现动态服务发现，这里指的是node；

__meta_kubernetes_service_annotation_prometheus_io_scrape，这个标签为true的过滤出来；

__meta_kubernetes_service_annotation_prometheus_io_path，如果指定了拉取指标数据的接口，把原来的__metrics_path__ 替换掉；

labelmap，保留哪些标签显示在prometheus WebUI中；

 

 

Pod 动态服务发现

Pod要想动态的服务发现，必须在定义Pod的时候，使用annotations:声明prometheus.io/scrape: 'true'，否则创建的Pod不会被自动服务发现，还有一个前提你使用的镜像需要暴露了/metrics接口，否则也监控不到；

- job_name: kubernetes-pods
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - action: keep
        regex: true
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_scrape
      - action: replace
        regex: (.+)
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_path
        target_label: __metrics_path__
      - action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        source_labels:
        - __address__
        - __meta_kubernetes_pod_annotation_prometheus_io_port
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - action: replace
        source_labels:
        - __meta_kubernetes_namespace
        target_label: kubernetes_namespace
      - action: replace
        source_labels:
        - __meta_kubernetes_pod_name
        target_label: kubernetes_pod_name

 

这里的规则不作介绍和之前大同小异，要想让 Pod 自动服务发现，就需要暴露metrics接口；

基于静态配置的服务发现：static_configs

kube-scheduler/controller-manager/proxy静态服务发现

- job_name: 'kube-scheduler'
      scrape_interval: 5s
      static_configs:
      - targets: ['172.31.117.233:10251','172.31.117.234:10251','172.31.117.235:10251']
    - job_name: 'kube-controller-manager'
      scrape_interval: 5s
      static_configs:
      - targets: ['172.31.117.233:10252','172.31.117.234:10252','172.31.117.235:10252']
    - job_name: 'kube-proxy'
      scrape_interval: 5s
      static_configs:
      - targets: ['172.31.117.233:10249','1172.31.117.234:10249','1172.31.117.235:10249','1172.31.117.236:10249']

 

静态配置相对简单，直接添加targets即可，以列表的形式，这里需要注意一个问题，由于集群是使用kubeadm安装的，kube-proxy监听的是127.0.0.1:10249，无法正常监控，需要修改

[root@master01 monitor]# kubectl edit cm kube-proxy -n kube-system

 

默认metricsBindAddress : ""，监听在127.0.0.1:10249

 

需要先把之前的kube-proxy删除，然后它会自动重建Pod，此时即可监听0.0.0.0:10249

[root@master01 monitor]# kubectl get pods -n kube-system|grep kube-proxy
kube-proxy-5zs9d 1/1     Running 0          33h
kube-proxy-b28fj 1/1     Running 0          33h
kube-proxy-btmlh 1/1     Running 1          33h
kube-proxy-ct7vd 1/1     Running 0          33h
[root@master01 monitor]# kubectl get pods -n kube-system|grep kube-proxy|gawk '{print $1}'
kube-proxy-5zs9d
kube-proxy-b28fj
kube-proxy-btmlh
kube-proxy-ct7vd
[root@master01 monitor]# for i in `kubectl get pods -n kube-system|grep kube-proxy|gawk '{print $1}'`
> do
> kubectl delete pods $i -n kube-system
> done
pod "kube-proxy-5zs9d" deleted
pod "kube-proxy-b28fj" deleted
pod "kube-proxy-btmlh" deleted
pod "kube-proxy-ct7vd" deleted
[root@master01 monitor]# kubectl get pods -n kube-system|grep kube-proxy
kube-proxy-5xh5r 1/1     Running 0          22s
kube-proxy-ccp4w 1/1     Running 0          29s
kube-proxy-swmw9 1/1     Running 0          17s
kube-proxy-vkz78 1/1     Running 0          20s
[root@master01 monitor]#

 

监控情况截图

etcd服务发现

由于集群采用了 https 的方式访问 etcd 集群，如果想监控etcd的话，也需要使用证书，我们这边使用 secret 资源类型，让 Prometheus 挂载此证书；

[root@master01 monitor]# kubectl create secret generic etcd-certs --from-file=/etc/kubernetes/ssl/etcd/etcd.pem --from-file=/etc/kubernetes/ssl/etcd/etcd-key.pem --from-file=/etc/kubernetes/ssl/ca/ca.pem -n monitor
secret/etcd-certs created
[root@master01 monitor]#

 

修改prometheus-alertmanager-deployment.yaml文件添加如下标注配置

 

添加Etcd 静态监控配置

- job_name: 'k8s-etcd'
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/k8s-certs/etcd/ca.pem
        cert_file: /var/run/secrets/kubernetes.io/k8s-certs/etcd/etcd.pem
        key_file: /var/run/secrets/kubernetes.io/k8s-certs/etcd/etcd-key.pem
      scrape_interval: 5s
      static_configs:
      - targets: ['172.31.117.233:2379','172.31.117.234:2379','172.31.117.235:2379']

 

监控如图

 

Prometheus常用启动参数

配置参数	说明
- --config.file=/etc/prometheus/prometheus.yml	配置文件路径
- --storage.tsdb.path=/prometheus	存储路径，默认在data目录下
- --storage.tsdb.retention=720h	数据保留时间
- --web.enable-admin-api	控制对admin HTTP API的访问，其中包括删除时间序列等功能
- --web.enable-lifecycle	热加载 reload操作，如果不生效，删除重建；
- --web.max-connections=512	默认最大连接数
- --alertmanager.timeout=10s	报警信息发送给alertmanager的超时时间
- --query.timeout=2m	查询超时间
- --query.max-concurrency=20	并发查询数，prometheus的默认采集指标中有一项，prometheus_engine_queries_concurrent_max可以拿到最大查询并发数及查询情况

 

总结

主要总结 Prometheus 监控抓取的配置规则，尤其是relabel_configs的使用，这个是Prometheus 配置监控目标的重点，详细说明了node、pod、service、kube-apiserver的动态服务发现方式及配置文件详解，又列举了kube-controller-manager、kube-scheduler和etcd静态配置服务发现的方式，基于文件和DNS的服务发现，用的不多，先不总结，最后总结了Prometheus常用启动参数。