使用 CRD 从 Kubernetes 集群创建自定义 Prometheus 抓取作业

自定义从您的 Kubernetes 集群中抓取 Prometheus 指标，文中描述了如何使用 ConfigMap 自定义从 Kubernetes 集群中默认目标收集 Prometheus 指标的方式。 本文介绍如何使用自定义资源定义（CRD）创建自定义抓取任务，以实现进一步的自定义和扩展额外的目标。

自定义资源定义 （CRD）

为 Prometheus 启用 Azure Monitor 托管服务会自动为 Pod 监视器和服务监视器部署自定义资源定义（CRD）。 这些 CRD 与 OsS Pod 监视器 和 Prometheus 的 OSS 服务监视器 相同，但组名称的更改除外。 如果你的群集上存在现有的 Prometheus CRD 和自定义资源，则这些 CRD 不会与加载项创建的 CRD 冲突。 同时，托管 Prometheus 加载项不会拾取针对 OSS Prometheus 创建的 CRD。 这种分离是有意而为的，目的是隔离抓取作业。

创建 Pod 或服务监视器

使用 Pod 和服务监视器模板并遵循 API 规范来创建自定义资源（Pod 监视器和服务监视器）。 托管 Prometheus 选取现有 OSS CR（自定义资源）所需的唯一更改是 API 组 - azmonitoring.coreos.com/v1。

Pod 和服务监视器如以下示例所示：

Pod 监视器示例

# Note the API version is azmonitoring.coreos.com/v1 instead of monitoring.coreos.com/v1
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor

# Can be deployed in any namespace
metadata:
  name: reference-app
  namespace: app-namespace
spec:
  labelLimit: 63
  labelNameLengthLimit: 511
  labelValueLengthLimit: 1023

  # The selector specifies which pods to filter for
  selector:

    # Filter by pod labels
    matchLabels:
      environment: test
    matchExpressions:
      - key: app
        operator: In
        values: [app-frontend, app-backend]

    # [Optional] Filter by pod namespace. Required if service is in another namespace.
    namespaceSelector:
      matchNames: [app-frontend, app-backend]

  # [Optional] Labels on the pod with these keys will be added as labels to each metric scraped
  podTargetLabels: [app, region, environment]

  # Multiple pod endpoints can be specified. Port requires a named port.
  podMetricsEndpoints:
    - port: metricscs from the exa

服务监视器示例

# Note the API version is azmonitoring.coreos.com/v1 instead of monitoring.coreos.com/v1
apiVersion: azmonitoring.coreos.com/v1
kind: ServiceMonitor

# Can be deployed in any namespace
metadata:
  name: reference-app
  namespace: app-namespace
spec:
  labelLimit: 63
  labelNameLengthLimit: 511
  labelValueLengthLimit: 1023

  # The selector filters endpoints by service labels.
  selector:
    matchLabels:
      app: reference-app

  # Multiple endpoints can be specified. Port requires a named port.
  endpoints:
  - port: metrics

部署 Pod 或服务监视器

按照以下示例中的 kubectl apply 部署 Pod 或服务监控器。

创建一个简单的应用程序

部署一个示例应用程序，用于公开 Pod/服务监视器所要配置的 Prometheus 指标。

kubectl apply -f https://raw.githubusercontent.com/Azure/prometheus-collector/refs/heads/main/internal/referenceapp/prometheus-reference-app.yaml

创建 Pod 监视器和/或服务监视器以抓取指标

部署配置为从上一步中抓取应用程序的 Pod 监视器。

Pod 监视器

kubectl apply -f https://raw.githubusercontent.com/Azure/prometheus-collector/refs/heads/main/otelcollector/deploy/example-custom-resources/pod-monitor/pod-monitor-reference-app.yaml

服务监视器

kubectl apply -f https://raw.githubusercontent.com/Azure/prometheus-collector/refs/heads/main/otelcollector/deploy/example-custom-resources/service-monitor/service-monitor-reference-app.yaml

故障排除

成功应用 Pod 或服务监视器后，加载项应自动开始从目标收集指标。 有关自定义资源的常规故障排除，请参阅 Azure Monitor 中的 Prometheus 指标集合 ，并确保目标显示在 127.0.0.1/目标中。

擦除配置设置

以下部分介绍 CRD 中使用的 Prometheus 配置文件中支持的设置。 有关这些设置的更多详细信息，请参阅 Prometheus 配置参考 。

全局设置

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

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

在全局部分中提供的设置适用于 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: '.+'

重命名指标 不支持指标重命名。

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

支持使用 PodMonitor 和 ServiceMonitor 来抓取使用基本身份验证或持有者令牌的目标。 确保包含用户名/密码/令牌的密钥与 pod/服务监视器位于同一命名空间中。 此行为与 OSS prometheus-operator 相同。

基于 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 抓取器使用。 密钥将是文件名。 该值经过 base64 解码，并作为容器中文件的内容添加。

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

   • 使用以下示例为 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

如果要在 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

后续步骤

• 详细了解如何收集 Prometheus 指标。