一文读懂运维人员必须理解的Prometheus Target发现机制

本文摘自《Kubernetes快速进阶与实战》一书，《Kubernetes快速进阶与实战》讲解Kubernetes的硬核知识，主要包含：Kubernetes核心概念，快速构建Kubernetes集群，Kubernetes核心对象使用，Kubernetes容器编排实践，Kubernetes系统运维与故障处理，构建Kubernetes高可用集群（Keepalived+LVS），Kubernetes监控与告警（Prometheus+Grafana）和基于Kubernetes的CI/CD项目综合实践（GitLab+ Harbor+Jenkins）等。

Target发现机制非常重要，因为Prometheus一切围绕Target展开，而Target发现是Prometheus监控的第一步，也是位于源头的关键一步。Prometheus会自动发现Target，同时也向用户屏蔽了背后的细节，但是作为一名运维人员必须理解这个背后的机制。

查看Prometheus的配置，点击Prometheus Web UI中的Status->Configuration，如图1所示。

图1  Prometheus 配置界面

Prometheus配置中最重要的一项就是Job的设置，如下所示，总共有16项Job。

- job_name: serviceMonitor/monitoring/alertmanager/0

每个Job就是一个监控任务，它监控1组（1个或多个）Target（这些Target的URL除了IP地址不同外，其余都相同），每个Job对应Prometheus Web页面中Service Discovery的一项，点击Status->Service Discovery，如图2所示，Service Discovery下正好是16项，和Configuration中的16个Job正好一一对应。其中，Service Discovery下每一项的名字就来自于Job的job_name值。

图2  Prometheus Service Discovery界面

Job中有1个非常重要的设置role，它表示该Job中Target的类型，例如本例中16个Job的role都配置成了endpoints（- role: endpoints），这就意味着Prometheus会根据Kubernetes中Service所对应的Endpoint来发现Target，每个Target由（Endpoint名，IP，Port，协议）四元组决定，此外如果该Endpoint背后的载体是Pod，那么该Pod所有的端口（这些端口不一定都是Endpoint中的端口）都会作为Target进行统计，具体示例说明如下。

如图2中的第1项（第1个Job）“serviceMonitor/monitoring/alertmanager/0 (3 / 48 active targets)”中有48个Target，那么这48个Target是怎么来的呢？

首先，该Job的配置了NameSpace为monitoring，如下所示。

kubernetes_sd_configs:

- role: endpoints

follow_redirects: true

namespaces:

names:

- monitoring

Prometheus读取kubernetes_sd_config中的配置，通过Kubernetes REST API 获取monitoring NameSpace中所有Endpoint，如图3所示。

图3 Endpoint信息界面

图3中一共有29个Endpoint，每个Endpoint对应一个Target，每个Target有（Endpoint名，IP，Port，协议）四种信息，成为四元组。不同行的Endpoint，它们的Endpoint名就不同，例如第7行和第8行的Endpoint（192.168.2.154:9090），虽然它们的IP和端口都相同，但是它们的Endpoint名是不同的，一个是prometheus-k8s，另一个是prometheus-operated，因此，它们是不同的Target；同一行的Endpoint，还要进一步看协议，区分是TCP还是UDP，例如第二行的Endpoint（192.168.2.159:9094），图3因为格式关系并未显示全，用+6 more...代替，但确实是存在的，可以“kubectl edit ep alertmanager-operated -n monitoring”查看验证），既有TCP又有UDP，因此，也要分为两个不同的Target。在Service Discovery界面中，点击“serviceMonitor/monitoring/alertmanager/0”旁边的Show more按钮，如图4所示，搜索“192.168.2.159:9094”能找到4个Target，其中2个含有标签__meta_kubernetes_endpoint_address_target_kind="Pod"的Target，就对应Service alertmanager-operated中的两个Endpoint（192.168.2.159:9094+TCP）和（192.168.2.159:9094+UDP）。剩下的两个Target则是Service alertmanager-main和（192.168.2.159:9094+TCP）和（192.168.2.159:9094+UDP）的组合，这个组合虽然没有出现在Endpoint列表中，但根据Prometheus的机制，从Endpoint alertmanager-main的角度看，9094也是Pod中容器打开的端口，因此，也作为Target计入。

图4  Job项界面

总之，图3有29个Target，距离48个Target，还差19个Target，这19个Target又分为两类，第一类是完全未在Endpoint列表的端口8080，共有13个Target；第二类是端口在Endpoint列表，但Endpoint对不上的端口9094（例如：在192.168.2.159上存在名字为altermanager-main的Endpoint，如图3所示，在该节点上还有1个监听端口9094，此时altermanager-main+9094+TCP就是一个组合，即为一个Target，altermanager-main+9094+UDP也是一个组合，即为一个Target，和192.168.2.159类似的节点有3个，因此一共有2x3=6个Target），共有6个Target。这两类Target（13+6=19）的特点是它们没有标签__meta_kubernetes_endpoint_address_target_kind="Pod"。

至此，解释了图2中的第1项（第1个Job）“serviceMonitor/monitoring/alertmanager/0 (3 / 48 active targets)”中48个Target的由来。而其它的Job，例如“serviceMonitor/monitoring/kube-apiserver/0 (1 / 1 active targets)”和“serviceMonitor/monitoring/kubelet/0 (3 / 16 active targets)”，它们的Target数量各不相同，这是因为它们获取Target的NameSpace不同，前者获取的是default NameSpace中的Target，后者获取的则是kube-system NameSpace中的Target。

接下来，继续看图2中的第1项（第1个Job）“serviceMonitor/monitoring/alertmanager/0 (3 / 48 active targets)”，这里有个数字3，它表示该Job所获取的所有Target（48个）中，只有3个是满足条件的。那么Job选择Target的条件是怎样的呢？这个是由Configuration的 relabel_configs所决定的，本例Job对应的relabel_configs如下所示，关键看“action: keep”，它表示如果Target的Label不符合该项的条件，就丢弃（Drop）该Target，例如__meta_kubernetes_service_label_alertmanager的值，如果Label alertmanager的值不是main，就丢弃该Target，如果是则进入到下一步的判断。

relabel_configs:

- source_labels: [job]

separator: ;

regex: (.*)

target_label: __tmp_prometheus_job_name

replacement: $1

action: replace

- source_labels: [__meta_kubernetes_service_label_alertmanager]

separator: ;

regex: main

replacement: $1

action: keep

- source_labels: [__meta_kubernetes_service_label_app_kubernetes_io_component]

separator: ;

regex: alert-router

replacement: $1

action: keep

- source_labels: [__meta_kubernetes_service_label_app_kubernetes_io_name]

separator: ;

regex: alertmanager

replacement: $1

action: keep