从 Kubernetes 群集自定义 Prometheus 指标集合 介绍了如何使用 ConfigMap 从 Kubernetes 群集中的默认目标自定义 Prometheus 指标的抓取。 本文介绍如何使用 ConfigMap 创建自定义抓取作业,以便进行进一步的自定义和添加额外的目标。
ConfigMaps
下表介绍了用于创建自定义抓取作业的 ConfigMap。 启用托管 Prometheus 时,群集中默认不存在这些 ConfigMap。
| 配置映射 | Description |
|---|---|
ama-metrics-prometheus-config (推荐) |
创建具有此名称的 ConfigMap 时,群集中运行的 Azure Monitor 指标副本 Pod 将运行其中定义的抓取作业。 |
ama-metrics-prometheus-config-node (高级) |
为在群集中每个 Linux 节点上运行的附加组件 DaemonSet 提供 Prometheus 抓取配置,以及每个节点上的任何节点级目标。 请参阅 高级设置。 |
ama-metrics-prometheus-config-node-windows (高级) |
为群集中每个 Windows 节点上运行的 addon DaemonSet 提供 Prometheus 抓取配置,以及每个节点上的任何节点级目标。 请参阅 高级设置。 |
创建 Prometheus 配置文件
与其直接修改 ama-metrics-prometheus-config,不如创建一个配置文件,然后将其转换为 ConfigMap,这样更简单。 有关此文件中各个部分的详细信息,请参阅下面的 抓取配置设置。
创建一个名为 prometheus-config 的 Prometheus 抓取配置文件,并使用以下格式。 在 scrape_configs 小节中列出了抓取配置,并可以选择使用全局节来设置全局 scrape_interval、scrape_timeout 和 external_labels。 有关抓取配置选项的完整详细内容,请参阅 Prometheus.io 抓取配置参考。
global:
scrape_interval: <duration>
scrape_timeout: <duration>
external_labels:
<labelname1>: <labelvalue>
<labelname2>: <labelvalue>
scrape_configs:
- <job-x>
- <job-y>
下面是一个示例 Prometheus 抓取配置文件:
global:
scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
scrape_interval: 60s
static_configs:
- targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
scheme: http
kubernetes_sd_configs:
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_service_name]
action: keep
regex: "prometheus-example-service"
小窍门
请参阅 Kubernetes 群集抓取配置的 Prometheus 示例。
验证抓取配置文件
代理使用自定义 promconfigvalidator 工具通过 ConfigMap 验证 Prometheus 配置。 如果配置无效,代理会拒绝自定义配置。 创建 Prometheus 配置文件后,可以使用此工具在为代理创建 ConfigMap 之前验证配置。
该工具 promconfigvalidator 在 Azure Monitor 指标加载项 Pod 中提供。 可以使用 ama-metrics-node-* 群集中命名空间中的任何 kube-system Pod 下载用于验证的工具。 使用 kubectl cp 以下命令下载该工具及其配置。
for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator; kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done
复制可执行文件和 yaml 后,找到 Prometheus 配置文件的路径。 然后在命令中替换 <config path> ,并使用以下命令运行验证程序。
./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"
如果可选merged-otel-config.yaml参数未提供任何路径,则运行验证程序将生成合并的配置文件output。 请勿使用此自动生成的合并文件,因为它仅用于工具验证和调试目的。
将配置文件作为 ConfigMap 部署
自定义 Prometheus 配置文件作为名为prometheus-config的字段在ama-metrics-prometheus-config、ama-metrics-prometheus-config-node或ama-metrics-prometheus-config-node-windows ConfigMap 中,被kube-system命名空间使用。 将你的 Prometheus 配置文件重命名为 prometheus-config 且不带文件扩展名,然后根据需要创建的自定义抓取作业配置的 ConfigMap,运行以下一条或多条示例命令,从抓取配置文件创建 ConfigMap。
创建供副本集使用的 ConfigMap:
kubectl create ConfigMap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system
这会在kube-system命名空间中创建一个名为ama-metrics-prometheus-config的ConfigMap。 若要查看配置验证、处理或合并是否存在任何问题,可以查看 ama-metrics 副本 Pod
创建 Linux DaemonSet 要使用的 ConfigMap:
kubectl create ConfigMap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system
创建一个名为 ama-metrics-prometheus-config-node 的 ConfigMap,在 kube-system 命名空间中。 若要查看配置验证、处理或合并是否存在任何问题,可以查看 ama-metrics-node Linux DaemonSet Pod
创建用于 Windows DaemonSet 的 ConfigMap
kubectl create ConfigMap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system
这会在kube-system命名空间中创建一个名为ama-metrics-prometheus-config-node-windows的ConfigMap。 若要查看配置验证、处理或合并是否存在任何问题,可以查看 ama-metrics-win-node Windows deamonset Pod
Troubleshooting
如果在 kube-system 命名空间中成功创建了 ConfigMap,但仍看不到自定义目标被抓取,请使用 kubectl logs 检查 副本 Pod 日志中的 ama-metrics-prometheus-config ConfigMap 或 DaemonSet Pod 日志中的 ama-metrics-prometheus-config-node ConfigMap 是否存在错误,并确保在以 prometheus-config-merger 为前缀的 “开始合并默认和自定义 Prometheus 配置” 部分中没有错误。
抓取配置
目前,抓取配置支持的目标发现方法是 static_configs 或 kubernetes_sd_configs,用于指定或发现目标。
静态配置包含静态目标列表以及要添加到这些目标的任何额外标签,如下所示。
scrape_configs:
- job_name: example
- targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
- labels: [ label1: value1, label1: value2, ... ]
使用 kubernetes_sd_configs 发现的目标将具有不同的 __meta_* 标签,具体取决于指定的角色。 可以使用 relabel_configs 部分的标签来筛选目标或替换目标的标签。
重新标记配置
relabel_configs 部分在发现目标时被使用,并适用于该作业的所有目标。 以下示例演示了如何使用 relabel_configs。
添加标签向作业的每个指标添加一个具有值example_label的新标签example_value。 仅使用 __address__ 作为源标签,因为该标签始终存在,并为作业的每个目标添加标签。
relabel_configs:
- source_labels: [__address__]
target_label: example_label
replacement: 'example_value'
使用 Kubernetes 服务发现标签
如果作业使用 kubernetes_sd_configs 来发现目标,则每个角色都有指标的相关 __meta_* 标签。 发现目标后,会删除 __* 标签。 若要在指标级别使用它们进行筛选,请先通过使用 relabel_configs 并分配标签名称来保留它们, 然后使用 metric_relabel_configs 进行筛选。
# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
# Keep only metrics with the kubernetes namespace 'default'
metric_relabel_configs:
- source_labels: [kubernetes_namespace]
action: keep
regex: 'default'
作业和实例重新标记
可以根据源标签更改 job 和 instance 标签值,就像任何其他标签一样。
# Replace the job name with the pod label 'k8s app'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
target_label: job
# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
target_label: instance
指标重新标记配置
指标重新标记配置在抓取之后、引入之前应用。 使用 metric_relabel_configs 部分在抓取之后筛选指标。 请参阅以下示例。
按名称删除指标
# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
action: drop
regex: 'example_metric_name'
按名称仅保留某些指标
# Keep only the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
action: keep
regex: 'example_metric_name'
# Keep only metrics that start with 'example_'
metric_relabel_configs:
- source_labels: [__name__]
action: keep
regex: '(example_.*)'
按标签筛选指标
# Keep metrics only where example_label = 'example'
metric_relabel_configs:
- source_labels: [example_label]
action: keep
regex: 'example'
# Keep metrics only if `example_label` equals `value_1` or `value_2`
metric_relabel_configs:
- source_labels: [example_label]
action: keep
regex: '(value_1|value_2)'
# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metric_relabel_configs:
- source_labels: [example_label_1, example_label_2]
separator: ';'
action: keep
regex: 'value_1;value_2'
# Keep metrics only if `example_label` exists as a label
metric_relabel_configs:
- source_labels: [example_label_1]
action: keep
regex: '.+'
重命名指标 不支持指标重命名。
注释
如果要将标签添加到自定义配置中的所有作业,请为每个作业显式添加标签 metrics_relabel_configs 。 使用 ConfigMap 的 Prometheus 配置不支持全局外部标签。
relabel_configs:
- source_labels: [__address__]
target_label: example_label
replacement: 'example_value'
基本身份验证和持有者令牌
如果在擦除配置中使用用户名、密码或凭据作为纯文本,则无需进行其他更改。 配置中指定的值将用于抓取。 如果你在 prometheus 配置中使用 username_file 或 password_file(或任何 _file 配置设置)为 basic_auth 或 bearer_token 进行配置,请执行以下步骤:
在名为
kube-system的ama-metrics-mtls-secret命名空间中创建机密。密钥
password1的名称可以是任何内容,只要与下一步在 Prometheus 抓取配置中提供的password_file文件路径中的文件名匹配即可。 该密钥的值需要经过 base64 编码。apiVersion: v1 kind: Secret metadata: name: ama-metrics-mtls-secret namespace: kube-system type: Opaque data: password1: <base64-encoded-string>ama-metrics-mtls-secret机密会挂载到ama-metricsPod 上的路径/etc/prometheus/certs/处,并可供 Prometheus 抓取器使用。 该密钥(在上述示例中为password1)将为文件名。 该值经过 base64 解码,并作为容器中文件的内容添加。请在 ConfigMap 中自定义抓取配置中提供文件路径:
基本身份验证 字段
username应包含实际的用户名字符串。password_file字段应包括其中包含密码的文件的路径。# Sets the `Authorization` header on every scrape request with the # configured username and password. basic_auth: username: <username string> password_file: /etc/prometheus/certs/password1持有者令牌 该
bearer_token_file字段应包含包含令牌的文件的路径。# Sets the `Authorization` header on every scrape request with the bearer token # read from the configured file. It is mutually exclusive with `bearer_token`. bearer_token_file: /etc/prometheus/certs/password1
有关这些设置的详细信息,请参阅 Prometheus scrape_config 文档 。
基于 TLS 的抓取
如果要从 https 终结点中抓取 Prometheus 指标,Prometheus 配置、PodMonitor 或 ServiceMonitor 应将 scheme 设置为 https 和额外的 TLS 设置。
在名为
kube-system的ama-metrics-mtls-secret命名空间中创建机密。 在机密对象的数据节中指定的每个键值对都将作为单独的文件装载在此 /etc/prometheus/certs 位置,文件名与数据节中指定的密钥相同。 机密值应经过 base64 编码。下面是机密的示例 YAML:
apiVersion: v1 kind: Secret metadata: name: ama-metrics-mtls-secret namespace: kube-system type: Opaque data: <certfile>: base64_cert_content <keyfile>: base64_key_contentama-metrics-mtls-secret机密会挂载到ama-metricsPod 上的路径/etc/prometheus/certs/处,并可供 Prometheus 抓取器使用。 密钥将是文件名。 该值经过 base64 解码,并作为容器中文件的内容添加。在 Prometheus 配置、PodMonitor 或 ServiceMonitor 中提供文件路径:
- 使用以下示例在 ConfigMap 中提供 TLS 配置设置:
tls_config: # CA certificate to validate API server certificate with. ca_file: /etc/prometheus/certs/<certfile> # Certificate and key files for client cert authentication to the server. cert_file: /etc/prometheus/certs/<certfile> key_file: /etc/prometheus/certs/<keyfile> # Disable validation of the server certificate. insecure_skip_verify: false
基本身份验证和 TLS
如果要在 ConfigMap 中使用基本身份验证或持有者令牌(基于文件的凭据)和 TLS 身份验证设置,请确保机密 ama-metrics-mtls-secret 包含数据节下的所有密钥及其相应的 base64 编码值,如以下示例所示:
apiVersion: v1
kind: Secret
metadata:
name: ama-metrics-mtls-secret
namespace: kube-system
type: Opaque
data:
certfile: base64_cert_content # used for TLS
keyfile: base64_key_content # used for TLS
password1: base64-encoded-string # used for basic auth
password2: base64-encoded-string # used for basic auth
注释
/etc/prometheus/certs/ 路径是必需项,但 password1 可以是任何字符串,并且需要匹配上面创建的机密中的数据对应的密钥。 这是因为机密ama-metrics-mtls-secret被挂载在容器内的路径/etc/prometheus/certs/上。
当机密作为文件装载时,ama-metrics pods 会自动解码 base64 编码值。 确保机密名称是 ama-metrics-mtls-secret 并且位于 kube-system 命名空间中。
应首先创建机密,然后在命名空间中创建 kube-system ConfigMap、PodMonitor 或 ServiceMonitor。 机密创建的顺序很重要。 如果没有机密,但 ConfigMap、PodMonitor 或 ServiceMonitor 指向机密,则以下错误将位于 ama-metrics prometheus-collector 容器日志中: no file found for cert....
有关 TLS 配置设置的更多详细信息 ,请参阅tls_config 。
高级设置:为 DaemonSet 配置自定义 Prometheus 采集任务
副本 ama-metrics Pod 使用自定义 Prometheus 配置并擦除指定的目标。 对于一个包含大量节点和 Pod 且需要抓取大量指标的集群,可以将某些适用的自定义抓取目标从单个 ama-metrics 副本 Pod 卸载到 ama-metrics DaemonSet Pod。
ama-metrics-prometheus-config-node ConfigMap 类似于副本集 ConfigMap,可以用于在每个节点上创建静态抓取配置。 抓取配置应仅针对单个节点,并且不应使用服务发现或 Pod 注解。 否则,每个节点都会尝试擦除所有目标,并多次调用 Kubernetes API 服务器。
自定义爬取目标可以遵循相同的格式,使用 static_configs 目标、使用 $NODE_IP 环境变量,并指定用于爬取的端口。 DaemonSet 的每个 Pod 采用配置、抓取指标,并将指标发送到该节点。
以下 node-exporter 配置是 DaemonSet Pod 的默认目标之一。 它使用 $NODE_IP 环境变量,该变量已为每个 ama-metrics 加载项容器设置,以针对节点上的特定端口。
- job_name: nodesample
scrape_interval: 30s
scheme: http
metrics_path: /metrics
relabel_configs:
- source_labels: [__metrics_path__]
regex: (.*)
target_label: metrics_path
- source_labels: [__address__]
replacement: '$NODE_NAME'
target_label: instance
static_configs:
- targets: ['$NODE_IP:9100']
擦除配置设置
以下部分介绍 ConfigMap 中使用的 Prometheus 配置文件中支持的设置。 有关这些设置的更多详细信息,请参阅 Prometheus 配置参考 。
全局设置
全局设置的配置格式与 OSS prometheus 配置支持的格式相同
global:
scrape_interval: <duration>
scrape_timeout: <duration>
external_labels:
<labelname1>: <labelvalue>
<labelname2>: <labelvalue>
scrape_configs:
- <job-x>
- <job-y>
全局部分中提供的设置适用于所有抓取作业(包括 Configmap 和自定义资源中的作业),但如果在单个作业中有明确指定的设置,则这些设置将被覆盖。
注释
如果希望使用适用于所有抓取作业的全局设置,并且只有 自定义资源,那么仍需创建一个仅包含全局设置的 ConfigMap(自定义资源中的每个设置都会覆盖全局部分中的相应设置)。