Skapa ett anpassat Prometheus-skrapjobb från kubernetes-klustret med hjälp av CRD:er

Anpassa en samling Prometheus-mått från kubernetes-klustret beskriver hur du använder ConfigMap för att anpassa skrapning av Prometheus-mått från standardmål i ditt Kubernetes-kluster. Den här artikeln beskriver hur du använder anpassade resursdefinitioner (CRD) för att skapa anpassade skrapjobb för ytterligare anpassning och ytterligare mål.

Anpassade resursdefinitioner (CRD)

Om du aktiverar azure monitor-hanterad tjänst för Prometheus distribueras automatiskt anpassade resursdefinitioner (CRD) för poddövervakare och tjänstövervakare. Dessa CRD:er är samma som OSS Pod-övervakare och OSS-tjänstövervakare för Prometheus förutom en ändring i gruppnamnet. Om du har befintliga Prometheus CRD:er och anpassade resurser i klustret kommer dessa CRD:er inte att vara i konflikt med de CRD:er som skapats av tillägget. Samtidigt hämtar det hanterade Prometheus-tillägget inte de CRD:er som skapats för OSS Prometheus. Denna åtskillnad är avsiktlig för att isolera skrapjobb.

Skapa en podd eller tjänstövervakare

Använd mallarna Pod och Service Monitor och följ API-specifikationen för att skapa dina anpassade resurser (PodMonitor och Service Monitor). Den enda ändring som krävs för befintliga OSS CR (anpassade resurser) för att hämtas av den hanterade Prometheus är API-gruppen: azmonitoring.coreos.com/v1.

Dina podd- och tjänstövervakare bör se ut som följande exempel:

Exempel på Pod-monitor

# 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

Exempel på tjänstövervakare

# 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

Distribuera en podd eller tjänstövervakare

Distribuera podden eller tjänstövervakaren med hjälp av kubectl apply som i följande exempel.

Skapa ett exempelprogram

Distribuera ett exempelprogram som exponerar prometheus-mått som ska konfigureras av podd-/tjänstövervakaren.

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

Skapa en podövervakare och/eller tjänstövervakare för att samla in mätvärden

Distribuera en podmonitor som är konfigurerad för att insamla programmet från föregående steg.

Podövervakare

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

Serviceövervakning

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

Felsökning

När podd- eller tjänsteövervakningssystemen har tillämpats, ska tillägget automatiskt börja samla in metrik från målobjekten. Se Felsöka insamling av Prometheus-metrik i Azure Monitor för allmän felsökning av anpassade resurser och säkerställ att målen visas i 127.0.0.1/targets.

Inställningar för scrape-konfiguration

I följande avsnitt beskrivs de inställningar som stöds i Prometheus-konfigurationsfilen som används i CRD. Mer information om de här inställningarna finns i konfigurationsreferensen för Prometheus .

Globala inställningar

Konfigurationsformatet för globala inställningar är detsamma som stöds av OSS prometheus-konfigurationen

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

Inställningarna som anges i det globala avsnittet gäller för alla skrapjobb i CRD, men åsidosätts om de anges i de enskilda jobben.

Scrape-konfigurationer

De metoder som stöds för målidentifiering för anpassade resurser är för närvarande podövervakning och tjänstövervakning.

Podar och tjänsteövervakning

Mål som identifieras med podd- och tjänstövervakare har olika __meta_* etiketter beroende på vilken övervakare som används. Du kan använda etiketterna i avsnittet relabelings för att filtrera mål eller ersätta etiketter för målen. Se podd- och tjänstövervakarens exempel på poddar och tjänstövervakare.

Ommärkningar

Avsnittet relabelings tillämpas vid tidpunkten för målidentifieringen och gäller för varje mål för jobbet. I följande exempel visas olika sätt att använda relabelings.

Lägga till en etikett Lägg till en ny etikett med namnet example_label med värdet example_value för varje mått i jobbet. Använd __address__ bara som källetikett eftersom etiketten alltid finns och lägger till etiketten för varje mål för jobbet.

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

Använd Pod- eller Service Monitor-etiketter

Mål som identifieras med podd- och tjänstövervakare har olika __meta_* etiketter beroende på vilken övervakare som används. Etiketterna __* tas bort när målen har upptäckts. Om du vill filtrera med hjälp av dem på måttnivå ska du först behålla dem genom relabelings att tilldela ett etikettnamn. Använd metricRelabelings sedan för att filtrera.

# 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'

Ommärkning av jobb och instanser

Du kan ändra job värdena och instance etiketterna baserat på källetiketten, precis som andra etiketter.

# 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

Omlabeling av mätvärden

Måttommärkningar tillämpas efter skrapning och före inmatning. Använd avsnittet metricRelabelings för att filtrera mått efter skrapning. Se följande exempel.

Ta bort mått efter namn

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

Behåll endast vissa mått efter namn

# 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_.*)'

Filtrera mått efter etiketter

# 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: '.+'

Byt namn på mått Det går inte att byta namn på mått.

Grundläggande autentiserings- och ägartoken

Att skrapa mål med grundläggande autentisering eller bärartoken stöds via PodMonitors och ServiceMonitors. Kontrollera att hemligheten som innehåller användarnamnet/lösenordet/token finns i samma namnområde som podd-/tjänstövervakaren. Det här beteendet är detsamma som OSS prometheus-operator.

TLS-baserad dataskrapning

Om du vill samla in Prometheus-mått från en https-slutpunkt bör Prometheus-konfigurationen, PodMonitor eller ServiceMonitor ha scheme inställd till https och ytterligare TLS-inställningar.

1. Skapa en hemlighet i kube-system namnområdet med namnet ama-metrics-mtls-secret. Varje nyckel/värde-par som anges i dataavsnittet i det hemliga objektet monteras som en separat fil på den här /etc/prometheus/certs-platsen med filnamn som är samma som nycklarna som anges i dataavsnittet. De hemliga värdena ska vara base64-kodade.

   Följande är ett exempel på YAML för en hemlighet:

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     <certfile>: base64_cert_content    
     <keyfile>: base64_key_content 
   

   Hemligheten ama-metrics-mtls-secret monteras på ama-metrics poddarna vid sökvägen /etc/prometheus/certs/ och görs tillgänglig för Prometheus-skrapan. Nyckeln blir filnamnet. Värdet är base64-avkodat och läggs till som innehållet i filen i containern.

2. Ange filsökvägen i Prometheus-konfigurationen, PodMonitor eller ServiceMonitor:

   • Använd följande exempel för att ange TLS-konfigurationsinställningen för en PodMonitor eller ServiceMonitor:

    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
   

Grundläggande autentisering och TLS

Om du vill använda både grundläggande autentiserings- eller ägartoken (filbaserade autentiseringsuppgifter) och inställningarna för TLS-autentisering i din CRD kontrollerar du att hemligheten ama-metrics-mtls-secret innehåller alla nycklar under dataavsnittet med motsvarande base64-kodade värden, enligt nedan:

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

Nästa steg

• Läs mer om att samla in Prometheus-mått.