使用 ConfigMap 从 Kubernetes 群集创建自定义 Prometheus 抓取任务

从 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_intervalscrape_timeoutexternal_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-configama-metrics-prometheus-config-nodeama-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_configskubernetes_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'

作业和实例重新标记

可以根据源标签更改 jobinstance 标签值,就像任何其他标签一样。

# 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_filepassword_file(或任何 _file 配置设置)为 basic_authbearer_token 进行配置,请执行以下步骤:

  1. 在名为 kube-systemama-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-metrics Pod 上的路径 /etc/prometheus/certs/ 处,并可供 Prometheus 抓取器使用。 该密钥(在上述示例中为 password1)将为文件名。 该值经过 base64 解码,并作为容器中文件的内容添加。

  2. 请在 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 设置。

  1. 在名为 kube-systemama-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_content 
    

    ama-metrics-mtls-secret 机密会挂载到 ama-metrics Pod 上的路径 /etc/prometheus/certs/ 处,并可供 Prometheus 抓取器使用。 密钥将是文件名。 该值经过 base64 解码,并作为容器中文件的内容添加。

  2. 在 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(自定义资源中的每个设置都会覆盖全局部分中的相应设置)。

后续步骤