Delen via

Scraping van metrische Prometheus-gegevens aanpassen in de beheerde Azure Monitor-service voor Prometheus

  • Artikel

Dit artikel bevat instructies voor het aanpassen van scraping van metrische gegevens voor een Kubernetes-cluster met de invoegtoepassing met metrische gegevens in Azure Monitor.

Configuratiekaarten

Er kunnen vier verschillende configuratiekaarten worden geconfigureerd om scrapeconfiguratie en andere instellingen voor de invoegtoepassing met metrische gegevens te bieden. Alle configuratietoewijzingen moeten worden toegepast op kube-system naamruimte voor elk cluster.

Notitie

Geen van de vier configuratiekaarten bestaat standaard in het cluster wanneer Managed Prometheus is ingeschakeld. Afhankelijk van wat moet worden aangepast, moet u een of al deze vier configuratiekaarten implementeren met dezelfde naam die is opgegeven, in kube-system de naamruimte. AMA-Metrics-pods halen deze configuratiekaarten op nadat u ze in kube-system naamruimte hebt geïmplementeerd en worden binnen 2-3 minuten opnieuw opgestart om de configuratie-instellingen toe te passen die zijn opgegeven in de configmap(s).

  1. ama-metrics-settings-configmap Deze configuratietoewijzing heeft onderstaande eenvoudige instellingen die kunnen worden geconfigureerd. U kunt de configmap uit de bovenstaande Git Hub-opslagplaats gebruiken, de instellingen wijzigen die vereist zijn en de configmap toepassen/implementeren in kube-system naamruimte voor uw cluster
    • clusteralias (als u de waarde van cluster het label wilt wijzigen in elke tijdreeks/metrische waarde die wordt opgenomen vanuit een cluster)
    • standaard scrapedoelen in- of uitschakelen : standaardschrooting in- of uitschakelen op basis van doelen. Scrape-configuratie voor deze standaarddoelen zijn al vooraf gedefinieerd/ingebouwd
    • op podaantekening gebaseerde scraping per naamruimte inschakelen
    • lijsten met metrische gegevens: deze instelling wordt gebruikt om te bepalen welke metrische gegevens worden vermeld voor elk standaarddoel en om het standaardgedrag te wijzigen
    • scrape-intervallen voor standaard/vooraf gedefinieerdetargets. 30 secs is de standaard scrapefrequentie en kan worden gewijzigd per standaarddoel met behulp van deze configmap
    • foutopsporingsmodus : als u deze functie inschakelt, kunt u problemen met ontbrekende metrische gegevens/opname opsporen. Zie meer over het oplossen van problemen
  2. ama-metrics-prometheus-config Deze configuratietoewijzing kan worden gebruikt om prometheus-scrapeconfiguratie voor addon-replica op te geven. Met Addon wordt een singleton-replica uitgevoerd en kunnen services op clusterniveau worden gedetecteerd en gesroot door scrapetaken in deze configuratiemap te leveren. U kunt de voorbeeldconfiguratiemap uit de bovenstaande Git Hub-opslagplaats nemen, scrape-taken toevoegen die u nodig hebt en de configuratietoewijzing toepassen/implementeren in kube-system naamruimte voor uw cluster. Hoewel dit wordt ondersteund, moet u er rekening mee houden dat de aanbevolen manier om aangepaste doelen te scrapen gebruikmaakt van aangepaste resources
  3. ama-metrics-prometheus-config-node (Geavanceerd) Deze configuratietoewijzing kan worden gebruikt om Prometheus scrape-configuratie te bieden voor addon DaemonSet die wordt uitgevoerd op elk Linux-knooppunt in het cluster, en eventuele doelen op knooppuntniveau op elk knooppunt kunnen worden afgeschraapt door scrapetaken op te geven in deze configuratiemap. Wanneer u deze configmap gebruikt, kunt u een variabele gebruiken $NODE_IP in uw scrape-configuratie. Deze wordt vervangen door het IP-adres van het bijbehorende knooppunt in de DaemonSet-pod die op elk knooppunt wordt uitgevoerd. Op deze manier krijgt u toegang tot het scrapen van alles dat op dat knooppunt wordt uitgevoerd vanuit de metrische invoegtoepassing DaemonSet. Wees voorzichtig wanneer u ontdekkingen gebruikt in de knipselconfiguratie in deze configuratietoewijzing op knooppuntniveau, omdat elk knooppunt in het cluster de doel(en) instelt en redundante metrische gegevens verzamelt. U kunt de voorbeeldconfiguratiemap uit de bovenstaande Git Hub-opslagplaats nemen, scrape-taken toevoegen die u nodig hebt en de configuratietoewijzing toepassen/implementeren in kube-system naamruimte voor uw cluster
  4. ama-metrics-prometheus-config-node-windows (Geavanceerd) Deze configuratietoewijzing kan worden gebruikt om Prometheus scrape-configuratie te bieden voor addon DaemonSet die wordt uitgevoerd op elk Windows-knooppunt in het cluster, en doelen op knooppuntniveau op elk knooppunt kunnen worden geroot door scrapetaken in deze configuratiemap op te geven. Wanneer u deze configuratiemap gebruikt, kunt u een variabele gebruiken $NODE_IP in uw knipselconfiguratie. Deze wordt vervangen door het IP-adres van het bijbehorende knooppunt in de DaemonSet-pod die op elk knooppunt wordt uitgevoerd. Op deze manier krijgt u toegang tot het scrapen van alles dat op dat knooppunt wordt uitgevoerd vanuit de metrische invoegtoepassing DaemonSet. Wees voorzichtig wanneer u ontdekkingen gebruikt in de knipselconfiguratie in deze configuratietoewijzing op knooppuntniveau, omdat elk knooppunt in het cluster de doel(en) instelt en redundante metrische gegevens verzamelt. U kunt de voorbeeldconfiguratiemap uit de bovenstaande Git Hub-opslagplaats nemen, scrape-taken toevoegen die u nodig hebt en de configuratietoewijzing toepassen/implementeren in kube-system naamruimte voor uw cluster

Aangepaste resourcedefinities

De invoegtoepassing met metrische gegevens van Azure Monitor ondersteunt het scrapen van metrische Prometheus-metrische gegevens met behulp van Prometheus - Pod Monitors en Service Monitors, vergelijkbaar met de OSS Prometheus-operator. Als u de invoegtoepassing inschakelt, worden de aangepaste resourcedefinities voor Pod en Service Monitor geïmplementeerd, zodat u uw eigen aangepaste resources kunt maken. Volg de instructies voor het maken en toepassen van aangepaste resources op uw cluster.

Configmap voor instellingen voor metrische gegevensinvoegtoepassing

De ama-metrics-settings-configmap kan worden gedownload, bewerkt en toegepast op het cluster om de kant-en-klare functies van de invoegtoepassing met metrische gegevens aan te passen.

Standaarddoelen in- en uitschakelen

De volgende tabel bevat een lijst met alle standaarddoelen die de invoegtoepassing met metrische gegevens van Azure Monitor standaard kan scrapen en of deze in eerste instantie is ingeschakeld. Standaarddoelen worden elke 30 seconden afgeschraapt. Een replica wordt geïmplementeerd om clusterbrede doelen, zoals kube-state-metrics, te scrapen. Een DaemonSet wordt ook geïmplementeerd om knooppuntbrede doelen zoals kubelet te scrapen.

Sleutel Type Ingeschakeld Pod Beschrijving
kubelet bool true Linux DaemonSet Scrape kubelet in elk knooppunt in het K8s-cluster zonder extra knipselconfiguratie.
cadvisor bool true Linux DaemonSet Scrape cadvisor in elk knooppunt in het K8s-cluster zonder extra knipselconfiguratie.
Alleen Linux.
kubestate bool true Linux-replica Scrape kube-state-metrics in het K8s-cluster (geïnstalleerd als onderdeel van de invoegtoepassing) zonder extra knipselconfiguratie.
nodeexporter bool true Linux DaemonSet Metrische gegevens van knooppunten scrapen zonder extra knipselconfiguratie.
Alleen Linux.
coredns bool false Linux-replica Scrape coredns-service in het K8s-cluster zonder extra knipselconfiguratie.
kubeproxy bool false Linux DaemonSet Scrape kube-proxy in elk Linux-knooppunt dat is gedetecteerd in het K8s-cluster zonder extra knipselconfiguratie.
Alleen Linux.
apiserver bool false Linux-replica Scrape de Kubernetes-API-server in het K8s-cluster zonder extra knipselconfiguratie.
windowsexporter bool false Windows DaemonSet Knip windows-exporteur in elk knooppunt in het K8s-cluster zonder extra knipselconfiguratie.
Alleen Windows.
windowskubeproxy bool false Windows DaemonSet Scrape windows-kube-proxy in elk knooppunt in het K8s-cluster zonder extra knipselconfiguratie.
Alleen Windows.
prometheuscollectorhealth bool false Linux-replica Scrape informatie over de prometheus-collectorcontainer, zoals de hoeveelheid en grootte van tijdreeksen die worden gesroot.

Als u het scrapen van de standaarddoelen wilt inschakelen die niet standaard zijn ingeschakeld, bewerkt u de configuratiemap ama-metrics-settings-configmap om de doelen onder default-scrape-settings-enabled bij te truewerken. Pas de configuratiemap toe op uw cluster.

Op podaantekening gebaseerde scraping inschakelen

Als u toepassingspods wilt scrapen zonder een aangepaste Prometheus-configuratie te hoeven maken, kunnen aantekeningen worden toegevoegd aan de pods. De aantekening is vereist om de pod te scrapen prometheus.io/scrape: "true" . De aantekeningen prometheus.io/path en prometheus.io/port geven het pad en de poort aan waarop de metrische gegevens worden gehost op de pod. De aantekeningen voor een pod waarop metrische gegevens <pod IP>:8080/metrics worden gehost, zijn:

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

Het scrapen van deze pods met specifieke aantekeningen is standaard uitgeschakeld. Als u wilt inschakelen ama-metrics-settings-configmap, voegt u de regex toe voor de naamruimten van de pods met aantekeningen die u als de waarde van het veld podannotationnamespaceregexwilt scrapen.

Met de volgende instelling worden bijvoorbeeld pods met aantekeningen alleen in de naamruimten kube-system geschraapt en my-namespace:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

Als u scraping wilt inschakelen voor pods met aantekeningen in alle naamruimten, gebruikt u:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

Waarschuwing

Het scrapen van de podaantekeningen uit veel naamruimten kan een zeer groot aantal metrische gegevens genereren, afhankelijk van het aantal pods met aantekeningen.

Metrische gegevens aanpassen die standaarddoelen zijn verzameld

Standaard worden voor alle standaarddoelen alleen minimale metrische gegevens die worden gebruikt in de standaardregistratieregels, waarschuwingen en Grafana-dashboards opgenomen, zoals beschreven in minimaal opnameprofiel. Als u alle metrische gegevens van standaarddoelen wilt verzamelen, werkt u de keep-lists bij in de instellingenconfiguratiemap onder default-targets-metrics-keep-listen stelt u deze in minimalingestionprofile falseop .

Als u meer metrische gegevens wilt toestaan naast de standaardgegevens die worden vermeld, moet u voor alle standaarddoelen de instellingen bewerken onder default-targets-metrics-keep-list voor de bijbehorende taak die u wilt wijzigen.

Is bijvoorbeeld kubelet de instelling voor het filteren van metrische gegevens voor de standaarddoel-kubelet. Gebruik het volgende script om te filteren in metrische gegevens die zijn verzameld voor de standaarddoelen met behulp van filteren op basis van regex.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

Notitie

Als u aanhalingstekens of backslashes in de regex gebruikt, moet u deze escapen met behulp van een backslash zoals de voorbeelden "test\'smetric\"s\"" en testbackslash\\*.

Als u de standaardtaken verder wilt aanpassen om eigenschappen zoals verzamelingsfrequentie of labels te wijzigen, schakelt u het bijbehorende standaarddoel uit door de configmap-waarde voor het doel in te falsestellen op. Pas vervolgens de taak toe met behulp van een aangepaste configmap. Zie Scraping van metrische prometheus-metrische gegevens in Azure Monitor aanpassen voor meer informatie over aangepaste configuratie.

Clusteralias

Het clusterlabel dat wordt toegevoegd aan elke tijdreeks die wordt verwijderd, maakt gebruik van het laatste deel van de Azure Resource Manager-resource-id van het volledige AKS-cluster. Als de resource-id bijvoorbeeld is, is /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclusternamemyclusternamehet clusterlabel .

Als u het clusterlabel in de tijdreeks wilt overschrijven, werkt u de instelling cluster_alias bij naar een tekenreeks in prometheus-collector-settings de configuratiemapama-metrics-settings-configmap. U kunt deze configuratiemap maken als deze niet bestaat in het cluster of u kunt de bestaande configuratiemap bewerken als deze al bestaat in uw cluster.

Het nieuwe label wordt ook weergegeven in de vervolgkeuzelijst clusterparameter in de Grafana-dashboards in plaats van de standaardlabel.

Notitie

Alleen alfanumerieke tekens zijn toegestaan. Alle andere tekens worden vervangen door _. Deze wijziging is ervoor te zorgen dat verschillende onderdelen die dit label gebruiken, voldoen aan de basis alfanumerieke conventie. Als u opname- en waarschuwingsregels inschakelt, moet u ervoor zorgen dat u de naam van de clusteralias gebruikt in de parameter voor de clusternaam van de sjabloon voor het onboarden van regels om de regels te laten werken.

Foutopsporingsmodus

Waarschuwing

Deze modus kan van invloed zijn op de prestaties en mag alleen korte tijd worden ingeschakeld voor foutopsporing.

Als u alle metrische gegevens wilt weergeven die worden verwijderd voor foutopsporingsdoeleinden, kan de invoegtoepassingsagent voor metrische gegevens worden geconfigureerd voor uitvoering in de foutopsporingsmodus door de instelling enabled bij te true werken onder de debug-mode instelling in de configuratiemapama-metrics-settings-configmap. U kunt deze configuratiemap maken of een bestaande configuratiemap bewerken. Zie de sectie Foutopsporingsmodus in de verzameling Problemen met metrische prometheus-gegevens oplossen voor meer informatie.

Intervalinstellingen voor knipsel

Als u de instellingen voor het scrape-interval voor elk doel wilt bijwerken, kunt u de duur bijwerken in de instelling default-targets-scrape-interval-settings voor dat doel in de configuratiemapama-metrics-settings-configmap. U moet de intervallen voor schroot instellen in de juiste indeling die is opgegeven op deze website. Anders wordt de standaardwaarde van 30 seconden toegepast op de bijbehorende doelen. Bijvoorbeeld: als u het scrape-interval voor de kubelet taak 60s wilt bijwerken, kunt u de volgende sectie in de YAML bijwerken:

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"

en pas de YAML toe met behulp van de volgende opdracht: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Aangepaste Prometheus-scrapetaken configureren

U kunt prometheus-metrische gegevens scrapen met behulp van Prometheus - Pod Monitors en Service Monitors (Aanbevolen), vergelijkbaar met de OSS Prometheus-operator. Volg de instructies voor het maken en toepassen van aangepaste resources op uw cluster.

Daarnaast kunt u de instructies volgen voor het maken, valideren en toepassen van de configuratiekaart voor uw cluster. De configuratie-indeling is vergelijkbaar met het Prometheus-configuratiebestand.

Tips en voorbeelden voor Prometheus-configuratie

Hier vindt u enkele tips uit voorbeelden in deze sectie.

Gebruik de Pod- en Service Monitor-sjablonen en volg de API-specificatie om uw aangepaste resources (PodMonitor en Service Monitor) te maken. Houd er rekening mee dat de enige wijziging die is vereist voor de bestaande OSS-CR's voor het ophalen door de beheerde Prometheus, de API-groep - azmonitoring.coreos.com/v1 is. Zie hier voor meer informatie

Notitie

Wanneer de aangepaste scrape-configuratie niet kan worden toegepast vanwege validatiefouten, wordt de standaardconfiguratie voor scrape nog steeds gebruikt.

Als u globale instellingen wilt gebruiken die van toepassing zijn op alle scrapetaken en alleen aangepaste resources hebt, moet u nog steeds een configuratiekaart maken met alleen de globale instellingen (Instellingen voor elk van deze in de aangepaste resources worden de instellingen in de algemene sectie overschreven)

Knipselconfiguraties

Momenteel zijn de ondersteunde methoden voor doeldetectie voor aangepaste resources pod en servicemonitor

Pod- en servicemonitors

Doelen die worden gedetecteerd met pod- en servicemonitors hebben verschillende __meta_* labels, afhankelijk van welke monitor wordt gebruikt. U kunt de labels in de relabelings sectie gebruiken om doelen te filteren of labels voor de doelen te vervangen.

Bekijk de voorbeelden van pod- en servicemonitors van pods en servicemonitors.

Labels opnieuw voltooien

De relabelings sectie wordt toegepast op het moment van doeldetectie en is van toepassing op elk doel voor de taak. In de volgende voorbeelden ziet u manieren om te gebruiken relabelings.

Een label toevoegen

Voeg een nieuw label example_label toe met de waarde example_value aan elke metrische waarde van de taak. Gebruik __address__ het bronlabel alleen omdat dat label altijd bestaat en het label toevoegt voor elk doel van de taak.

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

Pod- of Service Monitor-labels gebruiken

Doelen die worden gedetecteerd met pod- en servicemonitors hebben verschillende __meta_* labels, afhankelijk van welke monitor wordt gebruikt. De __* labels worden verwijderd nadat de doelen zijn ontdekt. Als u wilt filteren op het niveau van metrische gegevens, moet u ze eerst gebruiken relabelings door een labelnaam toe te wijzen. metricRelabelings Gebruik vervolgens om te filteren.

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

Opnieuw labelen van taken en instanties

U kunt de job waarden en instance labelwaarden wijzigen op basis van het bronlabel, net als elk ander label.

# 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

Notitie

Als u configuraties opnieuw hebt gelabeld, moet u ervoor zorgen dat de doelen niet worden gefilterd door het opnieuw labelen en dat de labels die juist zijn geconfigureerd, overeenkomen met de doelen.

Metrische herlabels

Metrische herlabels worden toegepast na scraping en vóór opname. Gebruik de metricRelabelings sectie om metrische gegevens te filteren na het scrapen. In de volgende voorbeelden ziet u hoe u dit doet.

Metrische gegevens op naam verwijderen

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

Alleen bepaalde metrische gegevens op naam behouden

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

Naam van metrische gegevens wijzigen

De naam van metrische gegevens wordt niet ondersteund.

Metrische gegevens filteren op labels

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

Basisverificatie

Als u de instelling in uw prometheus-configuratie gebruikt basic_auth , volgt u de stappen :

  1. Maak een geheim in de kube-system-naamruimte met de naam ama-metrics-mtls-secret

De waarde voor wachtwoord1 is base64encoded.

Het sleutelwachtwoord1 kan alles zijn, maar moet alleen overeenkomen met uw scrapeconfig password_file bestandspad.

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

Het geheim ama-metrics-mtls-secret wordt gekoppeld aan de ama-metrics-containers op pad - /etc/prometheus/certs/ en wordt beschikbaar gesteld voor het proces dat prometheus-metrische gegevens scrapt. De sleutel( ex - wachtwoord1) in het bovenstaande voorbeeld is de bestandsnaam en de waarde wordt base64 gedecodeerd en toegevoegd aan de inhoud van het bestand in de container en de prometheus-scraper gebruikt de inhoud van dit bestand om de waarde op te halen die wordt gebruikt als het wachtwoord dat wordt gebruikt om het eindpunt te scrapen.

  1. Gebruik in de configuratiemap voor de aangepaste scrape-configuratie de volgende instelling. Het veld gebruikersnaam moet de werkelijke gebruikersnaamtekenreeks bevatten. Het veld password_file moet het pad naar een bestand met het wachtwoord bevatten.
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

Door het pad naar het bovenstaande password_file op te geven, gebruikt de prometheus-scraper de inhoud van het bestand met de naam wachtwoord1 in het pad /etc/prometheus/certs als de waarde van het wachtwoord voor eenvoudige auth-gebaseerde scraping.

Als u zowel basisverificatie als tls-verificatie gebruikt, raadpleegt u de onderstaande sectie . Raadpleeg de onderstaande notitiesectie voor meer informatie.

Scraping op basis van TLS

Als u een Prometheus-exemplaar hebt geleverd met TLS en u metrische gegevens wilt scrapen, moet u het schema https instellen en de TLS-instellingen instellen in uw configmap of respectieve CRD. Volg de onderstaande stappen.

  1. Maak een geheim in de kube-system-naamruimte met de naam ama-metrics-mtls-secret. Elk sleutel-waardepaar dat is opgegeven in de gegevenssectie van het geheime object, wordt gekoppeld als een afzonderlijk bestand in deze /etc/prometheus/certificaatlocatie met dezelfde bestandsnaam(en) als sleutel(en) die zijn opgegeven in de gegevenssectie. De geheime waarden moeten base64 worden gecodeerd voordat ze onder de gegevenssectie worden weergegeven, zoals hieronder.

    Hieronder ziet u een voorbeeld van het maken van een geheim via 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

    Het geheim ama-metrics-mtls-secret wordt gekoppeld aan de ama-metrics-containers op pad - /etc/prometheus/certs/ en wordt beschikbaar gesteld voor het proces dat prometheus-metrische gegevens scrapt. De sleutel( ex - certfile) in het bovenstaande voorbeeld is de bestandsnaam en de waarde wordt base64 gedecodeerd en toegevoegd aan de inhoud van het bestand in de container en de prometheus-scraper gebruikt de inhoud van dit bestand om de waarde op te halen die wordt gebruikt als het wachtwoord dat wordt gebruikt om het eindpunt te scrapen.

  2. Hieronder vindt u de details over het opgeven van de TLS-configuratie-instellingen via een configmap of CRD.

  • Als u de TLS-configuratie-instelling in een configuratiemap wilt opgeven, volgt u het onderstaande voorbeeld.
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

Basisverificatie en TLS

Als u zowel de basis- als tls-verificatie-instellingen in uw configmap/CRD wilt gebruiken, moet u ervoor zorgen dat het geheim ama-metrics-mtls-secret alle bestanden(sleutels) in de gegevenssectie bevat met de bijbehorende met base 64 gecodeerde waarden, zoals hieronder wordt weergegeven.

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

Notitie

Notitie

Het pad /etc/prometheus/certs/ is verplicht, maar wachtwoord1 kan elke tekenreeks zijn en moet overeenkomen met de sleutel voor de gegevens in het hierboven gemaakte geheim. Dit komt doordat het geheim ama-metrics-mtls-secret is gekoppeld in het pad /etc/prometheus/certs/ in de container.

De base64-gecodeerde waarde wordt automatisch gedecodeerd door de agentpods wanneer het geheim als bestand wordt gekoppeld.

Zorg ervoor dat de geheime naam ama-metrics-mtls-secret is en dat deze zich in de kube-system-naamruimte bevindt.

Het geheim moet worden gemaakt en vervolgens moet de configmap/CRD worden gemaakt in de kube-system-naamruimte. De volgorde van geheime creatie is belangrijk. Als er geen geheim is maar een geldige CRD/config-toewijzing, vindt u fouten in het collectorlogboek ->no file found for cert....

Volg deze configuraties voor meer informatie over TLS-configuratie-instellingen.

Volgende stappen

Waarschuwingen instellen voor metrische gegevens van Prometheus
Metrische gegevens van Prometheus opvragen
Meer informatie over het verzamelen van metrische prometheus-gegevens