Egyéni Prometheus-kaparós feladat létrehozása a Kubernetes-fürtből CRD-k használatával

A Prometheus-metrikák gyűjteményének testreszabása a Kubernetes-fürtből azt ismerteti, hogyan szabhatja testre a Prometheus-metrikák kaparását a Kubernetes-fürt alapértelmezett példányaiból a ConfigMap használatával. Ez a cikk bemutatja, hogyan hozhat létre egyéni kaparásfeladatokat egyéni erőforrásdefiníciók (CRD-k) használatával további testreszabásokhoz és további célokhoz.

Egyéni erőforrás-definíciók (CRD-k)

Az Azure Monitor Prometheus felügyelt szolgáltatásának engedélyezése automatikusan üzembe helyezi az egyéni erőforrás-definíciókat (CRD) pod monitorokhoz és szolgáltatás monitorokhoz. Ezek a CRD-k megegyeznek az OSS podfigyelőivel és a Prometheus OSS-szolgáltatásfigyelőivel , kivéve a csoportnév módosítását. Ha meglévő Prometheus CRD-kkel és egyéni erőforrásokkal rendelkezik a fürtön, ezek a CRD-k nem ütköznek a bővítmény által létrehozott CRD-kkel. Ugyanakkor a felügyelt Prometheus-bővítmény nem veszi fel az OSS Prometheushoz létrehozott CRD-ket. Ez az elkülönítés szándékos a kaparási feladatok elkülönítése érdekében.

Pod vagy szolgáltatásfigyelő létrehozása

Használja a Pod- és Szolgáltatásfigyelő-sablonokat , és kövesse az API-specifikációt az egyéni erőforrások (PodMonitor és Service Monitor) létrehozásához. A meglévő OSS egyéni erőforrásoknak, amelyeket a felügyelt Prometheus vesz át, az egyetlen szükséges módosítása az API-csoport – azmonitoring.coreos.com/v1.

Fontos

Ügyeljen arra, hogy a sablonokban megadott labelLimit, labelNameLengthLimit és labelValueLengthLimit címkét használja, hogy azok ne legyenek elvetve a feldolgozás során. A fájl különböző szakaszaival kapcsolatos részletekért tekintse meg az alábbi Scrape konfigurációs beállításokat .

A pod- és szolgáltatásmonitoroknak az alábbi példákhoz hasonlóan kell kinéznie:

Példa podfigyelőre

# 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

Példa szolgáltatásfigyelőre

# 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 vagy szolgáltatásfigyelő üzembe helyezése

Helyezze üzembe a podot vagy szolgáltatásmonitort kubectl apply az alábbi példákhoz hasonlóan.

Mintaalkalmazás létrehozása

Helyezzen üzembe egy Prometheus metrikákat publikáló mintaalkalmazást, amelyet a pod/szolgáltatásmonitor konfigurálhat.

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

Podmonitor és/vagy szolgáltatásmonitor létrehozása metrikák lekaparásához

Helyezzen üzembe egy podmonitort, amely úgy van konfigurálva, hogy lekaparja az alkalmazást az előző lépésből.

Pod monitorozása

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

Szolgáltatásfigyelő

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

Hibaelhárítás

A pod- vagy szolgáltatásmonitorok sikeres alkalmazásakor a bővítménynek automatikusan el kell kezdenie a metrikák gyűjtését a célokból. Az egyéni erőforrások általános hibaelhárításához, és annak biztosítására, hogy a célok megjelenjenek a 127.0.0.1/targets címen, tekintse meg az Azure Monitor Prometheus-metrikák hibaelhárításának gyűjteményét.

A konfigurációs beállítások lekésése

A következő szakaszok a CRD-ben használt Prometheus konfigurációs fájlban támogatott beállításokat ismertetik. A beállításokkal kapcsolatos további részletekért tekintse meg a Prometheus konfigurációs referenciáját .

Globális beállítások

A globális beállítások konfigurációs formátuma megegyezik az OSS prometheus konfigurációja által támogatott formátummal

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

A globális szakaszban megadott beállítások a CRD összes lekérési feladatára vonatkoznak, de felülírják őket, ha az egyes feladatoknál vannak megadva.

Megjegyzés:

Ha olyan globális beállításokat szeretne használni, amelyek az összes kaparófeladatra vonatkoznak, és csak egyéni erőforrásokkal rendelkeznek, akkor is létre kell hoznia egy ConfigMap-térképet, amely csak a globális beállításokat használja. Az egyéni erőforrások mindegyikének beállításai felülbírálják a globális szakaszban lévőket

Konfigurációk lekaparása

Az egyéni erőforrások célfelderítésének támogatott módszerei jelenleg a Pod és a Service Monitor.

Pod- és szolgáltatásfigyelők

A pod- és szolgáltatásmonitorokkal felderített célok különböző __meta_* címkékkel rendelkeznek a használt monitortól függően. A szakasz címkéivel szűrheti a relabelings célokat, vagy lecserélheti a célcímkéket. Tekintse meg a pod- és szolgáltatásfigyelőkre vonatkozó példákat.

Újracímkézések

A relabelings szakasz a célfelderítéskor lesz alkalmazva, és a feladat minden egyes céljára érvényes. Az alábbi példák a használati relabelingsmódokat mutatják be.

Címke hozzáadása Adjon hozzá új címkét example_label, értékével example_value a feladat minden metrikájához. Csak azért használja __address__ forráscímkeként, mert ez a címke mindig létezik, és hozzáadja a címkét a feladat minden céljához.

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

Pod- vagy Szolgáltatásfigyelő-címkék használata

A pod- és szolgáltatásmonitorokkal felderített célok különböző __meta_* címkékkel rendelkeznek a használt monitortól függően. A __* címkék a célpontok felderítése után el lesznek dobva. A szűréshez a metrikák szintjén való használatuk érdekében először relabelings segítségével adjon nekik címkenevet. Ezután használja metricRelabelings a szűréshez.

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

Feladat- és példány újracímkézés

A job és instance címke értékeit a forráscímke alapján módosíthatja, ugyanúgy, mint bármely más címkét.

# 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

Megjegyzés:

Ha újracímkézési konfigurációkkal rendelkezik, győződjön meg arról, hogy az újracímkézés nem szűri ki a célokat, és a megfelelően konfigurált címkék megfelelnek a céloknak.

Metricai újracímkézések

A metrikák átcímkézései az adatok gyűjtése után, de még a betöltés előtt történnek. A szakasz használatával szűrheti a metricRelabelings metrikákat a kaparás után. Lásd az alábbi példákat.

Metrikák törlése név szerint

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

Csak bizonyos metrikákat tarts meg név szerint

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

Metrikák szűrése címkék szerint

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

Metrikák átnevezése A metrika átnevezése nem támogatott.

Alapszintű hitelesítés és tulajdonosi jogkivonatok

A PodMonitors és a ServiceMonitors használatával támogatottak az alapszintű hitelesítési vagy tulajdonosi jogkivonatokat használó kaparási célok. Győződjön meg arról, hogy a felhasználónevet/jelszót/token tartalmazó titok ugyanabban a névtérben van, mint a pod/szolgáltatásfigyelő. Ez a viselkedés megegyezik az OSS Prometheus-operatoréval.

TLS-alapú adatgyűjtés

Ha a Prometheus metrikáit egy https-végpontról szeretné begyűjteni, a Prometheus konfigurációjában, a PodMonitorban vagy a ServiceMonitorban a scheme értékét állítsa https-re, és adjon meg extra TLS-beállításokat.

1. Hozzon létre egy titkos kulcsot a kube-system névtérben.ama-metrics-mtls-secret A titkos objektum adatszakaszában megadott kulcs-érték párok külön fájlként lesznek csatlakoztatva ebben a /etc/prometheus/certs helyen az adatszakaszban megadott kulcsokkal megegyező fájlnevekkel. A titkos értékeknek base64 kódolásúnak kell lenniük.

   Az alábbiakban egy titkos yaML-példát mutatunk be:

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

   A ama-metrics-mtls-secret titok a ama-metrics podokra van szerelve az /etc/prometheus/certs/ útvonalon, és elérhetővé válik a Prometheus scraper számára. A kulcs a fájlnév lesz. Az érték a base64 dekódolva van, és a tárolóban lévő fájl tartalmaként van hozzáadva.

2. Adja meg a fájlútmutatót a Prometheus konfigurációjában, a PodMonitorban vagy a ServiceMonitorban:

   • Az alábbi példában adja meg a PodMonitor vagy a ServiceMonitor TLS-konfigurációs beállítását:

    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
   

Alapszintű hitelesítés és TLS

Ha az alapszintű hitelesítési vagy tulajdonosi jogkivonatot (fájlalapú hitelesítő adatokat) és a TLS-hitelesítési beállításokat is használni szeretné a CRD-ben, győződjön meg arról, hogy a titkos kód ama-metrics-mtls-secret tartalmazza az adatszakasz összes kulcsát a megfelelő base64 kódolású értékekkel, az alábbiak szerint:

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

Megjegyzés:

Az /etc/prometheus/certs/ elérési út kötelező, de password1 bármilyen sztring lehet, és meg kell egyeznie a fent létrehozott titkos kódban szereplő adatok kulcsával. Ennek az az oka, hogy a titkos kód ama-metrics-mtls-secret a tárolón belüli elérési útra /etc/prometheus/certs/ van csatlakoztatva.

A base64 kódolású értéket az ama-metrics podok automatikusan dekódolják, amikor a titkos kód fájlként van csatlakoztatva. Győződjön meg arról, hogy a titkos kód neve ama-metrics-mtls-secret és a kube-system névtérben van.

Először létre kell hozni a titkos kulcsot, majd létre kell hozni a ConfigMap, PodMonitor vagy ServiceMonitor nevet a névtérben kube-system . A titkos kódok létrehozásának sorrendje számít. Ha nincs titkos kód, csak egy ConfigMap, PodMonitor vagy ServiceMonitor, amely a titkos kódra mutat, a következő hiba jelenik meg az ama-metrics prometheus-collector tárolónaplókban: no file found for cert....

A TLS konfigurációs beállításairól további információt a tls_config talál.

Következő lépések

• További információ a Prometheus-metrikák gyűjtéséről.