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

项目
12/10/2024

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

configmap

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

注意

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

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

自定义资源定义

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

指标加载项设置 configmap

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

启用和禁用默认目标

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

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

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

启用基于 Pod 注释的抓取

若要在不需要创建自定义 Prometheus 配置的情况下抓取应用程序 Pod，可以向 Pod 添加注释。需要注释 prometheus.io/scrape: "true" 才能抓取 Pod。注释 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-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

警告

从许多命名空间中抓取 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 资源管理器资源 ID 的最后一部分。例如，如果资源 ID 为 /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername，则群集标签为 myclustername。

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

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

注意

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

调试模式

警告

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

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

抓取间隔设置

若要更新任何目标的抓取间隔设置，可以在 configmap ama-metrics-settings-configmap 中更新该目标的设置 default-targets-scrape-interval-settings 中的持续时间。必须以此网站中指定的正确格式设置抓取间隔。否则，将对相应的目标应用默认值（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 监视器和服务监视器（类似于 OSS Prometheus Operator，建议使用）抓取 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，请参阅应用配置文件部分。

注意

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

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

目前支持的自定义资源的目标发现方法有 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。

添加标签

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'

基本身份验证

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

如果在 prometheus 配置中使用basic_auth设置，请执行以下步骤 -

在名为ama-metrics-mtls-secret的kube-system命名空间中创建机密

password1 的值是 base64encoded。

密钥 password1 可以是任何内容，但只需匹配抓取配置 password_file 文件路径即可。

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>

ama-metrics-mtls-secret 机密装载到 /etc/prometheus/certs/ 路径上的 ama-metrics 容器，并可用于正在抓取 prometheus 指标的过程。上述示例中的密钥（例如 password1）是文件名，值经过 base64 解码并添加到容器中文件的内容中，prometheus 抓取程序使用此文件的内容获取用作抓取终结点的密码的值。

在自定义抓取配置的 configmap 中，使用以下设置。用户名字段应包含实际的用户名字符串。 password_file 字段应包括包含密码的文件的路径。

basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

通过提供上述 password_file 的路径，prometheus 抓取程序使用 /etc/prometheus/certs 路径中名为 password1 的文件的内容作为基于基本身份验证的抓取的密码的值。

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

基于 TLS 的抓取

如果有一个 Prometheus 实例，并且想要从中抓取指标，则需要将方案设置为 https 并在配置映射或相应的 CRD 中设置 TLS 设置。请按照以下步骤操作。

在名为 ama-metrics-mtls-secret 的 kube-system 命名空间中创建机密。在机密对象的数据节中指定的每个键值对都将作为单独的文件装载在此 /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 机密装载到 /etc/prometheus/certs/ 路径上的 ama-metrics 容器，并可用于正在抓取 prometheus 指标的过程。上述示例中的密钥（例如 certfile）是文件名，值经过 base64 解码并添加到容器中文件的内容中，prometheus 抓取程序使用此文件的内容获取用作抓取终结点的密码的值。
下面是有关如何通过 configmap 或 CRD 提供 TLS 配置设置的详细信息。

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

若要在 configmap 中提供 TLS 配置设置，请遵循以下示例。

tls_config:
    ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
    cert_file: /etc/prometheus/certs/<certfile>
    key_file: /etc/prometheus/certs/<keyfile>
    insecure_skip_verify: false

若要在 CRD（Pod/服务监视器）中提供 TLS 配置设置，请遵循以下示例。

 tlsConfig:
   ca:
     secret:
       key: "<certfile>" # since it is self-signed
       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 机密包含数据节下的所有文件（密钥）及其相应的基本 64 编码值，如下所示。

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/中。

当机密装载为文件时，代理 Pod 会自动解码 base64 编码值。

请确保机密名称为 ama-metrics-mtls-secret 且位于 kube-system 命名空间中。

机密应已创建，然后应在 kube-system 命名空间中创建 configmap/CRD。机密创建的顺序很重要。如果没有机密，但存在有效的 CRD/config 映射，则会在收集器日志中看到错误 ->no file found for cert....

若要详细了解 TLS 配置设置，请遵循此配置。

后续步骤

查询 Prometheus 指标
 详细了解如何收集 Prometheus 指标

通过

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

configmap

自定义资源定义

指标加载项设置 configmap

启用和禁用默认目标

启用基于 Pod 注释的抓取

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

群集别名

调试模式

抓取间隔设置

配置自定义 Prometheus 抓取作业

Prometheus 配置提示和示例

抓取配置

Pod 和服务监视器

重复标签

添加标签

使用 Pod 或服务监视器标签

作业和实例重新标记

指标重复标签

按名称删除指标

按名称仅保留某些指标

重命名指标

按标签筛选指标

基本身份验证

基于 TLS 的抓取

基本身份验证和 TLS

注意

后续步骤

其他资源