在适用于 Prometheus 的 Azure Monitor 托管服务中自定义 Prometheus 指标的抓取

本文介绍如何使用 Azure Monitor 中的指标加载项自定义 Kubernetes 群集的指标抓取。

Configmap

可以配置四种不同的 configmap，以为指标加载项提供抓取配置和其他设置。 对于任何群集，所有配置映射都应应用于 kube-system 命名空间。

备注

启用托管 Prometheus 时，默认情况下，所有四个 configmap 都不在群集中。 根据需要自定义的内容，应在 kube-system 命名空间中部署这四个指定名称相同的 configmap 中的任何一个或全部。 AMA-Metrics pod 会在你将其部署到 kube-system 命名空间后选取这些 configmap，并将在 2-3 分钟内重新启动以应用 configmap 中指定的配置设置。

1. ama-metrics-settings-configmap此配置映射具有以下可配置的简单设置。 可以从上述 git 中心存储库中获取 configmap，更改所需设置，并将 configmap 应用/部署到群集的kube-system命名空间
   • 群集别名（用于更改从群集引入的每个时序/指标中 cluster 标签的值）
   • 启用/禁用默认抓取目标 - 基于目标打开/关闭默认抓取。 这些默认目标的抓取配置已预定义/内置
   • 按命名空间启用基于 Pod 注释的抓取
   • metric keep-lists - 此设置用于控制每个默认目标允许列出哪些指标，以及更改默认行为
   • 默认/预定义目标的抓取间隔。 30 secs是默认抓取频率，可以使用此 configmap 为每个默认目标更改该值
   • debug-mode - 打开此模式有助于调试缺失指标/引入问题 - 请参阅有关故障排除的详细信息
2. ama-metrics-prometheus-config 此配置映射可用于为加载项副本提供 Prometheus 抓取配置。 加载项运行一个单一实例副本，并且可以通过在此 configmap 中提供抓取作业来发现和抓取任何群集级别的服务。 可以从上述 GitHub 存储库中获取示例配置映射，添加所需的抓取作业，然后将该配置映射应用/部署到群集的 kube-system 命名空间。 尽管支持此操作，但请注意，建议的抓取自定义目标的方式是使用自定义资源
3. ama-metrics-prometheus-config-node（高级）此 configmap 可用于为在群集的每个 Linux 节点上运行的加载项 DaemonSet 提供 Prometheus 抓取配置，并且可以在此 configmap 中提供抓取作业以抓取每个节点上的任何节点级别目标。 使用此 configmap 时，可以在抓取配置中使用$NODE_IP变量，该变量由每个节点上运行的 DaemonSet Pod 中相应节点的 IP 地址替换。 这样就可以从指标加载项 DaemonSet 访问并抓取在该节点上运行的任何内容。 在此节点级别配置映射中使用抓取配置中的发现功能时请小心，因为群集中的每个节点都会设置和发现目标，并可能收集冗余指标。 可以从上述 GitHub 仓库中获取示例 configmap，添加所需的抓取任务，并将配置映射应用/部署到集群的kube-system命名空间。
4. ama-metrics-prometheus-config-node-windows（高级）此 configmap 可用于为在群集的每个 Windows 节点上运行的加载项 DaemonSet 提供 Prometheus 抓取配置，并且可以在此 configmap 中提供抓取作业以抓取每个节点上的节点级别目标。 使用此 configmap 时，可以在抓取配置中使用$NODE_IP变量，该变量将由每个节点上运行的 DaemonSet Pod 中相应节点的 IP 地址替换。 这样就可以从指标加载项 DaemonSet 访问并抓取在该节点上运行的任何内容。 在此节点级别配置映射的抓取配置中使用发现功能时，请务必小心，因为群集中的每个节点都会设置并发现目标，并且会收集冗余指标。 可以从上述 GitHub 存储库中获取示例配置映射，添加所需的抓取作业，然后将该配置映射应用/部署到群集的 kube-system 命名空间

自定义资源定义

Azure Monitor 指标加载项支持使用 Prometheus Pod 监视器和服务监视器来抓取 Prometheus 指标，这与 OSS Prometheus 运算符类似。 启用该加载项会部署 Pod 和服务监视器自定义资源定义，以允许你创建自己的自定义资源。 按照说明在群集上创建并应用自定义资源。

指标加载项设置 configmap

您可以下载、编辑 ama-metrics-settings-configmap，并将其应用于集群，以自定义指标加载项的开箱即用功能。

启用和禁用默认目标

下表列出了 Azure Monitor 指标加载项默认可以抓取的所有默认目标，以及这些目标最初是否处于启用状态。 默认目标每 30 秒抓取一次。 系统会部署一个副本，用于抓取群集范围内的目标（如 kube-state-metrics）。 此外，还会部署一个 DaemonSet，用于抓取节点范围内的目标（如 kubelet）。

密钥	类型	已启用	Pod	说明
kubelet	bool	true	Linux DaemonSet	在 K8s 群集的每个节点中抓取 kubelet，无需任何额外的抓取配置。
cadvisor	布尔	true	Linux DaemonSet	在 K8s 群集的每个节点中抓取 cadvisor，无需任何额外的抓取配置。 仅限 Linux。
kubestate	布尔 (bool)	true	Linux 副本	在 K8s 群集（作为加载项的一部分安装）中抓取 kube-state-metrics，无需任何额外的抓取配置。
nodeexporter	布尔	true	Linux DaemonSet	抓取节点指标，而无需任何额外的抓取配置。 仅限 Linux。
coredns	bool	false	Linux 副本	在 K8s 群集中抓取 coredns 服务，而无需任何额外的抓取配置。
kubeproxy	布尔	false	Linux DaemonSet	在 K8s 群集中发现的每个 Linux 节点中抓取 kube-proxy，而无需任何额外的抓取配置。 仅限 Linux。
apiserver	布尔	false	Linux 副本	在 K8s 群集中抓取 Kubernetes API 服务，而无需任何额外的抓取配置。
windowsexporter	布尔	false	Windows DaemonSet	在 K8s 群集的每个节点中抓取 windows-exporter，无需任何额外的抓取配置。 仅限 Windows。
windowskubeproxy	布尔	false	Windows DaemonSet	在 K8s 群集中的每个节点中抓取 windows-kube-proxy，而无需任何额外的抓取配置。 仅限 Windows。
prometheuscollectorhealth	布尔	false	Linux 副本	抓取有关 prometheus-collector 容器的信息，例如已抓取时序的数量和大小。

如果要开启对默认情况下未启用的默认目标的抓取，请编辑 configmapama-metrics-settings-configmap 以将 default-scrape-settings-enabled 下列出的目标更新为 true。 并将 configmap 应用于群集。

启用基于 Pod 注释的抓取

若要在不需要创建自定义 Prometheus 配置的情况下抓取应用程序 Pod，可以向 Pod 添加注释。 要抓取 Pod，需要 prometheus.io/scrape: "true" 注释。 注释 prometheus.io/path 和 prometheus.io/port 指示指标托管在 Pod 上的路径和端口。 在 <pod IP>:8080/metrics 处托管指标的 Pod 的注释为：

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

默认情况下，禁用对带有特定注释的 Pod 的抓取。 启用此功能，请在 ama-metrics-settings-configmap 中添加你想要抓取的带注释的 Pod 所在命名空间的正则表达式，作为字段 podannotationnamespaceregex 的值。

例如，以下设置仅抓取 kube-system 和 my-namespace 命名空间中带注释的 Pod：

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

警告

从许多命名空间中抓取 Pod 注释可能会生成大量的指标，具体取决于具有注释的 Pod 数。

自定义默认目标收集的指标

默认情况下，对于所有默认目标，仅引入默认记录规则、警报和 Grafana 仪表板中使用的最少指标（具体如 minimal-ingestion-profile 中所述）。 要从默认目标收集所有指标，请在 default-targets-metrics-keep-list 下的设置 configmap 中更新保留列表，并将 minimalingestionprofile 设置为false。

要在默认允许列出的指标之外允许更多指标，对于任何默认目标，请在 default-targets-metrics-keep-list 下编辑要更改的相应作业的设置。

例如，kubelet 是默认目标 kubelet 的指标筛选设置。 使用以下脚本通过基于正则表达式的筛选来筛选为默认目标收集的 in 指标。

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

备注

如果在正则表达式中使用引号或反斜杠，则需要像示例 "test\'smetric\"s\"" 和 testbackslash\\* 那样使用反斜杠进行转义。

若要进一步自定义默认作业以更改集合频率或标签等属性，请通过将目标的 configmap 值设置为 false 来禁用相应的默认目标， 然后使用自定义 configmap 来应用该作业。 有关自定义配置的详细信息，请参阅在 Azure Monitor 中自定义 Prometheus 指标的抓取。

群集别名

附加到每个已抓取时序的群集标签将使用完整 AKS 或Azure Arc 支持的 Kubernetes 群集的 Azure 资源管理器资源 ID 的最后一部分。 例如，如果资源 ID 为 /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername，则群集标签为 myclustername。

若要替代所抓取的时序中的群集标签，请将设置 cluster_alias 更新为 prometheus-collector-settings 中 ama-metrics-settings-configmap 下的任何字符串。 如果群集中不存在此配置映射，可以创建；如果现有配置映射已存在于群集中，可以对其进行编辑。

新标签（而不是默认标签）还会显示在 Grafana 仪表板中的群集参数下拉列表中。

备注

仅允许使用字母数字字符。 其他任何字符都将替换为 _。 这一更改是为了确保使用此标签的不同组件遵守基本的字母数字约定。 如果要启用记录和警报规则，请确保在规则载入模板的群集名称参数中使用群集别名，使规则正常工作。

调试模式

警告

此模式可能会影响性能，应该出于调试目的短时间启用。

若要查看出于调试目的而抓取的每个指标，可以将指标加载项代理配置为在调试模式下运行，方法是将设置 enabled 更新为 truedebug-mode 中 设置下的 ama-metrics-settings-configmap。 可以创建此 configmap 或编辑现有 configmap。 有关更多详细信息，请参阅 Prometheus 指标收集疑难解答中的“调试模式”部分。

抓取时间间隔设置

若要更新任何目标的抓取间隔设置，可以在 default-targets-scrape-interval-settings 中更新该目标的设置 ama-metrics-settings-configmap 中的持续时间。 必须以此网站中指定的正确格式设置抓取间隔。 否则，将对相应的目标应用默认值（30 秒）。 例如 - 如果要将kubelet作业的抓取间隔更新为60s，可以更新 YAML 中的以下部分：

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

使用以下命令应用 YAML： kubectl apply -f .\ama-metrics-settings-configmap.yaml

配置自定义 Prometheus 抓取作业

可以使用 Prometheus Pod 监视器和服务监视器（推荐）来抓取 Prometheus 指标，这与开源 Prometheus 运算符类似。 按照说明在群集上创建并应用自定义资源。

此外，还可以按照说明为群集创建、验证和应用配置 configmap。 配置格式类似于 Prometheus 配置文件。

Prometheus 配置提示和示例

从本节的示例中了解一些技巧。

使用 CRD 进行自定义抓取配置

使用 Pod 和服务监视器模板并遵循 API 规范来创建自定义资源（Pod 监视器和服务监视器）。 注意，要让托管的 Prometheus 选取现有的 OSS CR，只需对 API 组 - azmonitoring.coreos.com/v1进行更改。 请参阅此文了解详细信息

自定义抓取配置的配置文件

配置格式与 Prometheus 配置文件相同。 目前支持以下部分：

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

在将其作为 configmap 应用之前，必须先从配置中删除任何其他不支持的部分。 否则，自定义配置无法通过验证，并且不会应用。

要根据 Prometheus 配置创建 configmap，请参阅应用配置文件部分。

备注

当自定义抓取配置由于验证错误而无法应用时，将继续使用默认抓取配置。

全局设置

全局设置的配置格式与 OSS prometheus 配置支持的格式相同

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

全局部分中提供的设置适用于所有抓取作业（包括 Configmap 和自定义资源中的作业），但如果在单个作业中有明确指定的设置，则这些设置将被覆盖。

备注

如果你要使用应用于所有抓取作业的全局设置，并且只有自定义资源，则仍然需要创建一个仅包含全局设置的配置映射（自定义资源中每个项的设置将替代全局部分中的设置）

抓取配置

使用 CRD 抓取配置

目前，自定义资源支持的目标发现方法是 Pod 和服务监视器

Pod 和服务监视器

使用 Pod 和服务监视器发现的目标具有不同的 __meta_* 标签，具体取决于使用的监视器。 可以使用 relabelings 部分的标签来筛选目标或替换目标的标签。

请参阅 Pod 和服务监视器示例了解 Pod 和服务监视器。

重复标签

relabelings 部分在发现目标时被使用，并适用于该作业的所有目标。 以下示例演示了如何使用 relabelings。

添加标签

向作业的每个指标添加一个名为 example_label、值为 example_value 的新标签。 仅使用 __address__ 作为源标签，因为该标签始终存在，并为作业的每个目标添加标签。

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

使用 Pod 或服务监视器标签

使用 Pod 和服务监视器发现的目标具有不同的 __meta_* 标签，具体取决于使用的监视器。 发现目标后，会删除 __* 标签。 若要在指标级别使用它们进行筛选，请先通过使用 relabelings 并分配标签名称来保留它们， 然后使用 metricRelabelings 进行筛选。

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metricRelabelings:
- sourceLabels: [kubernetes_namespace]
  action: keep
  regex: 'default'

作业和实例重新标记

可以根据源标签更改 job 和 instance 标签值，就像任何其他标签一样。

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: 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
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

备注

如果你有重新标记配置，请确保重新标记不会筛选掉目标，并且配置的标签与目标正确匹配。

指标重新标记

指标重新标记在抓取之后、引入之前应用。 使用 metricRelabelings 部分在抓取之后筛选指标。 以下示例演示了具体做法。

按名称删除指标

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

按名称仅保留某些指标

# Keep only the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: '(example_.*)'

重命名指标

不支持指标重命名。

按标签筛选指标

# Keep metrics only where example_label = 'example'
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metricRelabelings:
- sourceLabels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metricRelabelings:
- sourceLabels: [example_label_1]
  action: keep
  regex: '.+'

使用配置文件抓取配置

目前，抓取配置支持的目标发现方法是 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 服务发现配置

使用 kubernetes_sd_configs 发现的目标将具有不同的 __meta_* 标签，具体取决于指定的角色。 可以使用 relabel_configs 部分的标签来筛选目标或替换目标的标签。

请参阅 Kubernetes 群集抓取配置的 Prometheus 示例。

重新标记配置

在目标发现时，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'

基本身份验证和持有者令牌

使用 ConfigMap 抓取配置

若要在 prometheus 配置中使用 basic_auth 或 bearer_token 设置，请执行以下步骤：

1. 在名为 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-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 文档。

使用 CRD（Pod/服务监视器）抓取配置

目前，使用 PodMonitors 或 ServiceMonitors 不支持使用基本身份验证或持有者令牌来抓取目标。 即将发布的版本中将添加对此操作的支持。 目前，应将 Pod 或服务监视器转换为 Prometheus 抓取配置，并放入自定义抓取配置 configmap 中。 然后，即可支持基本身份验证和持有者令牌。

如果同时使用基本身份验证和 TLS 身份验证，请参阅以下部分。 有关更多详细信息，请参阅以下注释部分。

基于 TLS 的抓取

如果要从 https 终结点中抓取 Prometheus 指标，Prometheus 配置、PodMonitor 或 ServiceMonitor 应将 scheme 设置为 https 和额外的 TLS 设置。

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

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

2. 然后，在 Prometheus 配置、PodMonitor 或 ServiceMonitor 中提供文件路径：

使用 ConfigMap 抓取配置

• 若要在 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

使用 CRD（Pod/服务监视器）抓取配置

• 若要为 PodMonitor 或 ServiceMonitor 提供 TLS 配置设置，请遵循以下示例：

 tlsConfig:
   ca:
     secret:
       key: "<certfile>"
       name: "ama-metrics-mtls-secret"
   cert:
     secret:
       key: "<certfile>"
       name: "ama-metrics-mtls-secret"
   keySecret:
       key: "<keyfile>"
       name: "ama-metrics-mtls-secret"
   insecureSkipVerify: false

基本身份验证和 TLS

如果要在 ConfigMap/CRD 中使用基本身份验证设置和 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 Pod 会自动解码 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 配置设置，请遵循此配置。

后续步骤

在 Prometheus 的指标上设置警报
查询 Prometheus 指标
详细了解如何收集 Prometheus 指标