使用 CRD 從 Kubernetes 叢集建立自訂 Prometheus 抓取工作

自訂 Kubernetes 叢集中的 Prometheus 指標集合說明如何使用 ConfigMap 自訂從 Kubernetes 叢集中的預設目標抓取的 Prometheus 指標。 本文說明如何使用自訂資源定義 （CRD） 來建立自訂擷取作業，以進一步自訂和其他目標。

自訂資源定義 （CRD）

啟用 Prometheus 的 Azure 監視器受控服務會自動部署 Pod 監視器和服務監視器的自訂資源定義 （CRD）。 這些 CRD 與 Prometheus 的 OSS Pod 監視器和OSS 服務監視器 相同，只是群組名稱有所變更。 如果您的叢集上有現有的 Prometheus CRD 和自訂資源，這些 CRD 不會與附加元件所建立的 CRD 相衝突。 於此同時，受控 Prometheus 附加元件並不會挑選 OSS Prometheus 所建立的 CRD。 此分隔的目的是為了隔離抓取作業。

建立 Pod 或服務監視器

使用 Pod 和服務監視器範本 ，並遵循 API 規格來建立您的自訂資源（PodMonitor 和服務 監視器）。 為使受管理的 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 監視器中的 Prometheus 計量收集進行疑難排解以取得針對自訂資源進行一般疑難排解的方法，並確保目標顯示在 127.0.0.1/targets 中。

抓取組態設定

下列各節說明 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: '.+'

重新命名計量 不支援計量重新命名。

基本驗證與持有人權杖

使用 PodMonitors 與 ServiceMonitors 時，支援使用基本驗證或持有人權杖抓取目標。 確保包含使用者名稱/密碼/權杖的祕密與 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 的 /etc/prometheus/certs/ Pod 上，並可供 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 計量。