Freigeben über

Anpassen des Auslesens von Prometheus-Metriken im verwalteten Azure Monitor-Dienst für Prometheus

  • Artikel

Dieser Artikel enthält Anweisungen dazu, wie Sie das Auslesen von Metriken für einen Kubernetes-Cluster mit dem Metrik-Add-On in Azure Monitor anpassen.

ConfigMaps

Vier verschiedene ConfigMaps können konfiguriert werden, um die Auslesekonfiguration und andere Einstellungen für das Metrik-Add-On bereitzustellen. Alle ConfigMaps sollten auf den kube-system-Namespace für jeden Cluster angewendet werden.

Hinweis

Keine der vier Konfigurationszuordnungen ist standardmäßig im Cluster vorhanden, wenn Managed Prometheus aktiviert wird. Je nachdem, was angepasst werden muss, müssen Sie eine oder alle dieser vier Konfigurationszuordnungen mit demselben Namen im Namespace kube-system bereitstellen. AMA-Metrics-Pods nehmen diese Konfigurationszuordnungen auf, nachdem Sie sie im Namespace kube-system bereitgestellt haben, und starten in 2–3 Minuten neu, um die in der/den Konfigurationszuordnung(en) angegebenen Konfigurationseinstellungen anzuwenden.

  1. ama-metrics-settings-configmap Diese ConfigMap enthält einfache Einstellungen (siehe unten), die konfiguriert werden können. Sie können die ConfigMap aus dem obigen Git Hub-Repository verwenden, die erforderlichen Einstellungen ändern und die ConfigMap auf den kube-system-Namespace für Ihren Cluster anwenden/bereitstellen.
    • Clusteralias (zum Ändern des Werts der Bezeichnung cluster in jeder Zeitreihe/Metrik, die aus einem Cluster erfasst wird)
    • Aktivieren/Deaktivieren von Standard-Auslesezielen: Aktivieren/Deaktivieren Sie das Standardauslesen basierend auf Zielen. Die Auslesekonfiguration für diese Standardziele ist bereits vordefiniert/integriert.
    • Aktivieren von auf Podanmerkungen basierendem Auslesen pro Namespace
    • Metrikaufbewahrungslisten: Diese Einstellung wird verwendet, um zu steuern, welche Metriken von jedem Standardziel zugelassen werden sollen, und um das Standardverhalten zu ändern.
    • Auslese-Intervalle für Standard-/Vorabdefinitionsziele. 30 secs ist die Standard-Auslesehäufigkeit und kann mit dieser ConfigMap nach Standardziel geändert werden.
    • Debugmodus: Wenn Sie diese Option aktivieren, können Sie fehlende Metrik-/Erfassungsprobleme debuggen. Weitere Informationen finden Sie unter Problembehandlung.
  2. ama-metrics-prometheus-config Diese ConfigMap kann verwendet werden, um eine Prometheus-Auslesekonfiguration für das Add-On-Replikat bereitzustellen. Das Add-On führt ein Singleton-Replikat aus, und alle Dienste auf Clusterebene können ermittelt und ausgelesen werden, indem in dieser ConfigMap Ausleseaufträge bereitgestellt werden. Sie können die Beispiel-ConfigMap aus dem obigen Git Hub-Repository verwenden, Ausleseaufträge hinzufügen, die Sie benötigen, und die ConfigMap zum kube-system-Namespace für Ihren Cluster anwenden/bereitstellen. Obwohl dies unterstützt wird, beachten Sie, dass die empfohlene Methode zum Scraping (Auslesen) von benutzerdefinierten Zielen benutzerdefinierte Ressourcen verwendet
  3. ama-metrics-prometheus-config-node (Erweitert) Diese ConfigMap kann verwendet werden, um die Prometheus-Auslesekonfiguration für das Add-On DaemonSet bereitzustellen, das auf jedem Linux-Knoten im Cluster ausgeführt wird, und alle Ziele auf Knotenebene auf jedem Knoten können durch Bereitstellen von Ausleseaufträgen in dieser ConfigMap ausgelesen werden. Wenn Sie diese Configmap verwenden, können Sie die Variable $NODE_IP in Ihrer Auslesekonfiguration verwenden, die durch die IP-Adresse des entsprechenden Knotens im DaemonSet-Pod ersetzt wird, der auf jedem Knoten ausgeführt wird. Auf diese Weise erhalten Sie Zugriff, um alles auszulesen, was auf diesem Knoten von Metrik-Add-on DaemonSet ausgeführt wird. Seien Sie vorsichtig, wenn Sie Ermittlungen in der Auslesekonfiguration dieser Konfigurationszuordnung auf Knotenebene verwenden, da jeder Knoten im Cluster die Ziele einrichtet und ermittelt und redundante Metriken sammelt. Sie können die Beispiel-ConfigMap aus dem obigen Git Hub-Repository verwenden, Ausleseaufträge hinzufügen, die Sie benötigen, und die ConfigMap zum kube-system-Namespace für Ihren Cluster anwenden/bereitstellen
  4. ama-metrics-prometheus-config-node-windows (Erweitert) Diese ConfigMap kann verwendet werden, um die Prometheus-Auslesekonfiguration für das Add-On DaemonSet bereitzustellen, das auf jedem Windows-Knoten im Cluster ausgeführt wird, und Ziele auf Knotenebene auf jedem Knoten können durch Bereitstellen von Ausleseaufträgen in dieser ConfigMap ausgelesen werden. Wenn Sie diese Configmap verwenden, können Sie die Variable $NODE_IP in Ihrer Auslesekonfiguration verwenden, die durch die IP-Adresse des entsprechenden Knotens im DaemonSet-Pod ersetzt wird, der auf jedem Knoten ausgeführt wird. Auf diese Weise erhalten Sie Zugriff, um alles auszulesen, was auf diesem Knoten von Metrik-Add-on DaemonSet ausgeführt wird. Seien Sie vorsichtig, wenn Sie Ermittlungen in der Auslesekonfiguration dieser Konfigurationszuordnung auf Knotenebene verwenden, da jeder Knoten im Cluster die Ziele einrichtet und ermittelt und redundante Metriken sammelt. Sie können die Beispiel-ConfigMap aus dem obigen Git Hub-Repository verwenden, Ausleseaufträge hinzufügen, die Sie benötigen, und die ConfigMap zum kube-system-Namespace für Ihren Cluster anwenden/bereitstellen

Benutzerdefinierte Ressourcendefinitionen

Das Azure Monitor-Metrik-Add-On unterstützt das Scraping (Auslesen) von Prometheus-Metriken mithilfe von Prometheus – Pod Monitoren und Dienstmonitoren, ähnlich dem OSS Prometheus-Operator. Wenn Sie das Add-On aktivieren, werden die benutzerdefinierten Ressourcendefinitionen „Pod“ und „Service Monitor“ bereitgestellt, damit Sie eigene benutzerdefinierte Ressourcen erstellen können. Befolgen Sie die Anweisungen zum Erstellen und Anwenden von benutzerdefinierten Ressourcen auf Ihrem Cluster.

ConfigMap-Einstellungen des Metrik-Add-Ons

ama-metrics-settings-configmap kann heruntergeladen, bearbeitet und auf den Cluster angewendet werden, um die vorkonfigurierten Funktionen des Metrik-Add-Ons anzupassen.

Aktivieren und Deaktivieren von Standardzielen

In der folgenden Tabelle finden Sie eine Liste aller Standardziele, die das Azure Monitor-Metrik-Add-On standardmäßig auslesen kann, und erfahren, ob die Ziele anfänglich aktiviert sind. Standardziele werden alle 30 Sekunden ausgelesen. Ein Replikat wird bereitgestellt, um clusterweite Ziele wie kube-state-metrics auszulesen. Ein DaemonSet wird auch zum Auslesen knotenweiter Ziele wie Kubelet bereitgestellt.

Schlüssel type Aktiviert Pod Beschreibung
kubelet bool true Linux: DaemonSet Liest „kubelet“ in jedem Knoten des K8s-Clusters ohne zusätzliche Auslesekonfiguration aus.
cadvisor bool true Linux: DaemonSet Liest „cadvisor“ in jedem Knoten des K8s-Clusters ohne zusätzliche Auslesekonfiguration aus.
Nur Linux.
kubestate bool true Linux-Replikat Liest „kube-state-metrics“ im K8s-Cluster (als Teil des Add-Ons installiert) ohne zusätzliche Auslesekonfiguration aus.
nodeexporter bool true Linux: DaemonSet Liest Knotenmetriken ohne zusätzliche Auslesekonfiguration aus.
Nur Linux.
coredns bool false Linux-Replikat Liest den coredns-Dienst im K8s-Cluster ohne zusätzliche Auslesekonfiguration aus.
kubeproxy bool false Linux: DaemonSet Liest „kubeproxy“ in jedem im K8s-Cluster ermittelten Linux-Knoten ohne zusätzliche Auslesekonfiguration aus.
Nur Linux.
apiserver bool false Linux-Replikat Liest den Kubernetes-API-Server im K8s-Cluster ohne zusätzliche Auslesekonfiguration aus.
windowsexporter bool false Windows DaemonSet Liest den Windows-Exporter in jedem Knoten des K8s-Clusters ohne zusätzliche Auslesekonfiguration aus.
Nur Windows
windowskubeproxy bool false Windows DaemonSet Liest den Windows-Kubeproxy in jedem Knoten des K8s-Clusters ohne zusätzliche Auslesekonfiguration aus.
Nur Windows
prometheuscollectorhealth bool false Linux-Replikat Liest Informationen über den prometheus-collector-Container aus, z. B. die Anzahl und Größe der ausgelesenen Zeitreihen.

Wenn Sie das Auslesen der Standardziele aktivieren möchten, die standardmäßig nicht aktiviert sind, bearbeiten Sie die ConfigMap ama-metrics-settings-configmap, um die unter default-scrape-settings-enabled aufgelisteten Ziele auf true zu aktualisieren. Wenden Sie die ConfigMap auf Ihren Cluster an.

Aktivieren von auf Podanmerkungen basierendem Scraping

Um Anwendungspods auszulesen, ohne eine benutzerdefinierte Prometheus-Konfiguration erstellen zu müssen, können Anmerkungen zu den Pods hinzugefügt werden. Die Anmerkung prometheus.io/scrape: "true" ist erforderlich, damit der Pod ausgelesen werden kann. Die Anmerkungen prometheus.io/path und prometheus.io/port geben den Pfad und den Port an, an dem die Metriken auf dem Pod gehostet werden. Die Anmerkungen für einen Pod, der Metriken unter <pod IP>:8080/metrics hostet, wäre:

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

Das Auslesen dieser Pods mit bestimmten Anmerkungen ist standardmäßig deaktiviert. Fügen Sie zum Aktivieren in ama-metrics-settings-configmapden regulären Ausdruck für die Namespaces der Pods mit Anmerkungen hinzu, die Sie als Wert des Felds podannotationnamespaceregex auslesen möchten.

Beispielsweise liest die folgende Einstellung Pods mit Anmerkungen nur in den Namespaces kube-system und my-namespace aus:

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

Verwenden Sie Folgendes, um das Scraping für Pods mit Anmerkungen in allen Namespaces zu aktivieren:

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

Warnung

Durch das Scraping der Podanmerkungen aus vielen Namespaces kann je nach Anzahl der Pods mit Anmerkungen eine sehr große Menge an Metriken generiert werden.

Anpassen von Metriken, die durch Standardziele gesammelt wurden

Standardmäßig werden für alle Standardziele nur die minimalen Metriken erfasst, die in den standardmäßigen Aufzeichnungsregeln, Warnungsregeln und Grafana-Dashboards verwendet werden, wie unter minimal-ingestion-profile beschrieben. Um alle Metriken von Standardzielen zu sammeln, aktualisieren Sie die keep-Listen in der configmap-Einstellung unter default-targets-metrics-keep-list, und legen Sie minimalingestionprofile auf false fest.

Bearbeiten Sie für alle Standardziele die Einstellungen unter default-targets-metrics-keep-list für den entsprechenden Auftrag, den Sie ändern möchten, um zusätzlich zu den Standardmetriken, die zulässig sind, weitere Metriken zuzulassen.

Beispielsweise ist kubelet die Metrikfiltereinstellung für das Standardziel „kubelet“. Verwenden Sie folgendes Skript, um in Metriken zu filtern, die mit der RegEx-basierten Filterung für die Standardziele gesammelt wurden.

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

Hinweis

Wenn Sie Anführungszeichen oder umgekehrte Schrägstriche im RegEx verwenden, müssen Sie für sie einen umgekehrten Schrägstrich wie in den Beispielen "test\'smetric\"s\"" und testbackslash\\* als Escapezeichen verwenden.

Wenn Sie die Standardaufträge weiter anpassen möchten, um Eigenschaften wie Sammlungshäufigkeit oder Bezeichnungen zu ändern, deaktivieren Sie das entsprechende Standardziel, indem Sie den ConfigMap-Wert für das Ziel auf false festlegen. Wenden Sie dann den Auftrag mithilfe einer benutzerdefinierten ConfigMap an. Ausführliche Informationen zur benutzerdefinierten Konfiguration finden Sie unter Anpassen des Auslesens von Prometheus-Metriken in Azure Monitor.

Clusteralias

Die Clusterbezeichnung, die jeder ausgelesenen Zeitreihe angefügt wird, verwendet den letzten Teil der Azure Resource Manager-Ressourcen-ID des vollständigen AKS-Clusters. Wenn die Ressourcen-ID beispielsweise /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername lautet, ist die Clusterbezeichnung myclustername.

Um die Clusterbezeichnung in der ausgelesenen Zeitreihe außer Kraft zu setzen, aktualisieren Sie die Einstellung cluster_alias auf eine beliebige Zeichenfolge unter prometheus-collector-settings in der ConfigMap ama-metrics-settings-configmap. Sie können diese Konfigurationszuordnung erstellen, wenn sie nicht im Cluster vorhanden ist, oder eine bearbeiten, die bereits im Cluster vorhanden ist.

Anstelle der Standardbezeichnung wird auch in der Dropdownliste für Clusterparameter in den Grafana-Dashboards die neue Bezeichnung angezeigt.

Hinweis

Hierbei sind nur alphanumerische Zeichen zulässig. Alle anderen Zeichen werden durch _ ersetzt. Durch diese Änderung soll sichergestellt werden, dass die verschiedenen Komponenten, die diese Bezeichnung nutzen, der grundlegenden Konvention für alphanumerische Zeichen entsprechen. Wenn Sie Aufzeichnungs- und Warnregeln aktivieren, stellen Sie bitte sicher, dass Sie den Clusteraliasnamen im Parameter „Clustername“ der Regelonboardingvorlage verwenden, damit die Regeln funktionieren.

Debugmodus

Warnung

Dieser Modus kann sich auf die Leistung auswirken und sollte nur für kurze Zeit zum Debuggen aktiviert werden.

Um jede ausgelesene Metrik zum Debuggen anzuzeigen, kann der Metrik-Add-On-Agent für die Ausführung im Debugmodus konfiguriert werden, indem die Einstellung enabled unter der Einstellung debug-mode in der ConfigMap ama-metrics-settings-configmap auf true aktualisiert wird. Sie können diese ConfigMap entweder erstellen oder eine vorhandene bearbeiten. Weitere Informationen finden Sie im Abschnitt „Debugmodus“ in der Problembehandlung unter der Auflistung der Prometheus-Metriken.

Einstellungen für das Ausleseintervall

Um die Einstellungen für das Ausleseintervall für ein beliebiges Ziel festzulegen, können Sie die Dauer in der Einstellung default-targets-scrape-interval-settings für dieses Ziel in der ConfigMap ama-metrics-settings-configmap aktualisieren. Sie müssen die Ausleseintervalle im richtigen Format festlegen, das auf dieser Website angegeben ist. Andernfalls wird der Standardwert von 30 Sekunden auf die entsprechenden Ziele angewendet. Beispiel: Wenn Sie das Auslese-Intervall für den kubelet-Auftrag auf 60s aktualisieren möchten, können Sie den folgenden Abschnitt in der YAML aktualisieren:

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"

und wenden Sie die YAML mit folgendem Befehl an: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Konfigurieren benutzerdefinierter Prometheus-Ausleseaufträge

Sie können Prometheus-Metriken mithilfe von Prometheus – Pod Monitore und Dienstmonitore(Empfohlen) auslesen, ähnlich dem OSS Prometheus-Operator. Befolgen Sie die Anweisungen zum Erstellen und Anwenden von benutzerdefinierten Ressourcen auf Ihrem Cluster.

Außerdem können Sie den Anweisungen folgen, um die configmap für Ihren Cluster zu erstellen, zu validieren und anzuwenden. Das Konfigurationsformat ähnelt der Prometheus-Konfigurationsdatei.

Tipps und Beispiele für Prometheus-Konfigurationen

In diesem Abschnitt finden Sie einige Tipps anhand von Beispielen.

Verwenden Sie die Vorlagen „Pod“ und „Service Monitor“ und befolgen Sie die API-Spezifikation, um Ihre benutzerdefinierten Ressourcen (PodMonitor und Service Monitor) zu erstellen. Beachten Sie, dass die einzige Änderung, die für die vorhandene OSS-CRs erforderlich ist, für die von der verwalteten Prometheus-Gruppe aufgenommen werden muss, die API-Gruppe ist – azmonitoring.coreos.com/v1. Siehe hier, um mehr zu erfahren

Hinweis

Wenn die benutzerdefinierte Auslesekonfiguration aufgrund von Überprüfungsfehlern nicht angewendet werden kann, wird weiterhin die standardmäßige Auslesekonfiguration verwendet.

Wenn Sie globale Einstellungen verwenden möchten, die für alle Scrape-Aufträge gelten und nur über Benutzerdefinierte Ressourcen verfügen, müssen Sie weiterhin eine Configmap mit nur den globalen Einstellungen erstellen (Einstellungen für jede dieser Einstellungen in den benutzerdefinierten Ressourcen überschreiben die Einstellungen im globalen Abschnitt)

Auslesekonfigurationen

Derzeit sind die unterstützten Methoden zur Zielerkennung für benutzerdefinierte Ressourcen „Pod“ und „Service Monitor“

Pod- und Dienstmonitore

Ziele, die mithilfe von Pod- und Dienstmonitoren ermittelt werden, weisen unterschiedliche __meta_*-Bezeichnungen auf, je nachdem, welcher Monitor verwendet wird. Sie können die Bezeichnungen im Abschnitt relabelings verwenden, um Ziele zu filtern oder Bezeichnungen für die Ziele zu ersetzen.

Beispiele für Pod- und Dienstmonitore finden Sie in den Beispielen für Pod- und Dienstmonitore.

Neubezeichnungen

Der relabelings-Abschnitt wird zum Zeitpunkt der Zielermittlung angewendet und gilt für jedes Ziel des Auftrags. Die folgenden Beispiele zeigen, wie Sie relabelings verwenden können.

Hinzufügen einer Bezeichnung

Fügen Sie jeder Metrik des Auftrags eine neue Bezeichnung namens example_label mit dem Wert example_value hinzu. Verwenden Sie nur __address__ als Quellbezeichnung, da diese Bezeichnung immer vorhanden ist und die Bezeichnung für jedes Ziel des Auftrags hinzugefügt wird.

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

Verwenden von Pod- oder Dienstüberwachungsbezeichnungen

Ziele, die mithilfe von Pod- und Dienstmonitoren ermittelt werden, weisen unterschiedliche __meta_*-Bezeichnungen auf, je nachdem, welcher Monitor verwendet wird. Die __*-Bezeichnungen werden nach der Ermittlung der Ziele gelöscht. Um mit ihnen auf der Metrikebene zu filtern, behalten Sie sie zunächst mithilfe von relabelings bei, indem Sie ihnen einen Bezeichnungsnamen zuweisen. Verwenden Sie metricRelabelings dann zum Filtern.

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

Zuweisen neuer Bezeichnungen zu Aufträgen und Instanzen

Sie können die Bezeichnungswerte job und instance auf der Grundlage der Quellbezeichnung ändern, genau wie bei jeder anderen Bezeichnung.

# 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

Hinweis

Stellen Sie bei Konfigurationen zur Neubezeichnung sicher, dass die Neubezeichnung die Ziele nicht herausfiltert, und die konfigurierten Bezeichnungen den Zielen ordnungsgemäß entsprechen.

Metrische Neubezeichnungen

Metrische Neubezeichnungen werden nach dem Auslesen und vor der Erfassung angewendet. Verwenden Sie den metricRelabelings-Abschnitt, um Metriken nach dem Auslesen zu filtern. Die folgenden Beispiele veranschaulichen die Vorgehensweise.

Metriken nach Namen löschen

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

Nur bestimmte Metriken nach Namen beibehalten

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

Metriken umbenennen

Das Umbenennen von Metriken wird nicht unterstützt.

Metriken nach Bezeichnungen filtern

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

Standardauthentifizierung

Falls Sie in Ihrer Prometheus-Konfiguration die Einstellung basic_auth verwenden, gehen Sie wie folgt vor:

  1. Erstellen Sie im Namespace kube-system ein Geheimnis mit dem Namen ama-metrics-mtls-secret.

Der Wert für password1 ist base64encoded.

Der Schlüssel password1 kann alles sein, muss aber nur mit Ihrem scrapeconfig-Dateipfad password_file übereinstimmen.

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

Das Geheimnis ama-metrics-mtls-secret wird in den ama-metrics-Container unter dem Pfad /etc/prometheus/certs/ eingebunden und dem Prozess zur Verfügung gestellt, der die Metriken von Prometheus ausliest. Der Schlüssel (z. B. password1) im obigen Beispiel ist der Dateiname, und der Wert wird base64-dekodiert und dem Inhalt der Datei im Container hinzugefügt. Der Prometheus-Scraper verwendet den Inhalt dieser Datei, um den Wert zu erhalten, der als Kennwort zum auslesen des Endpunkts verwendet wird.

  1. Verwenden Sie in der configmap für die benutzerdefinierte Auslesekonfiguration die folgende Einstellung. Das Feld „Benutzername“ sollte die tatsächliche Benutzernamenzeichenfolge enthalten. Das Feld „password_file“ sollte den Pfad zu einer Datei enthalten, die das Kennwort enthält.
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

Durch die Angabe des Pfads zur password_file oben verwendet der prometheus-Scraper den Inhalt der Datei mit dem Namen password1 im Pfad /etc/prometheus/certs als Wert des Kennworts für das grundlegende Scraping, das auf Authentifizierung basiert.

Wenn Sie sowohl grundlegende Authentifizierung als auch TLS-Authentifizierung verwenden, lesen Sie bitte den Abschnitt unten. Weitere Informationen finden Sie unten im Abschnitt „Hinweis“.

TLS-basiertes Scraping

Wenn Sie eine Prometheus-Instanz haben, die mit TLS bedient wird und aus der Sie Metriken auslesen möchten, müssen Sie das Schema auf https festlegen und die TLS-Einstellungen in Ihrer ConfigMap oder den entsprechenden CRD festlegen. Führen Sie die folgenden Schritte aus.

  1. Erstellen Sie im Namespace „kube-system“ ein Geheimnis mit dem Namen „ama-metrics-mtls-secret“. Jedes Schlüssel-Wert-Paar, das im Datenabschnitt des geheimen Objekts angegeben ist, wird als separate Datei in diesen /etc/prometheus/certs-Speicherort gemountet, wobei der Dateiname mit den im Datenabschnitt angegebenen Schlüsseln übereinstimmt. Die geheimen Werte sollten base64-codiert sein, bevor sie wie unten im Datenabschnitt abgelegt werden.

    Nachfolgend finden Sie ein Beispiel zum Erstellen eines geheimen Schlüssels über 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

    Das Geheimnis ama-metrics-mtls-secret wird in den ama-metrics-Container unter dem Pfad /etc/prometheus/certs/ eingebunden und dem Prozess zur Verfügung gestellt, der die Metriken von Prometheus ausliest. Der Schlüssel (z. B. certfile) im obigen Beispiel ist der Dateiname, und der Wert wird base64-dekodiert und dem Inhalt der Datei im Container hinzugefügt. Der Prometheus-Scraper verwendet den Inhalt dieser Datei, um den Wert zu erhalten, der als Kennwort zum auslesen des Endpunkts verwendet wird.

  2. Nachfolgend finden Sie die Details zum Bereitstellen der TLS-Konfigurationseinstellungen über eine ConfigMap oder CRD.

  • Um die TLS-Konfigurationseinstellung in einer Configmap bereitzustellen, befolgen Sie bitte das folgende Beispiel.
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

Standardauthentifizierung und TLS

Wenn Sie in Ihrer configmap/CRD Einstellungen sowohl für die Standard- als auch für die TLS-Authentifizierung verwenden möchten, stellen Sie einfach sicher, dass das Geheimnis ama-metrics-mtls-secret alle Dateien (Schlüssel) unter dem Abschnitt „Daten“ mit ihren entsprechenden Base-64-kodierten Werten enthält, wie unten gezeigt.

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

Hinweis

Hinweis

Der Pfad /etc/prometheus/certs/ ist obligatorisch, aber password1 kann eine beliebige Zeichenfolge sein und muss dem Schlüssel für die Daten im oben erstellten Geheimnis entsprechen. Der Grund: Das Geheimnis ama-metrics-mtls-secret ist im Pfad /etc/prometheus/certs/ innerhalb des Containers eingebunden.

Der base64-codierte Wert wird automatisch von den Agent-Pods decodiert, wenn das Geheimnis als Datei eingebunden ist.

Stellen Sie sicher, dass der Name des Geheimnisses ama-metrics-mtls-secret lautet und sich im Namespace kube-system befindet.

Das Geheimnis sollte erstellt werden, und dann sollte die ConfigMap/CRD im kube-system-Namespace erstellt werden. Die Reihenfolge, in der das Geheimnis erstellt wird, ist wichtig. Wenn kein Geheimnis, aber eine gültige CRD/ConfigMap vorhanden ist, finden Sie Fehler im Collectorprotokoll ->no file found for cert....

Weitere Informationen zu TLS-Konfigurationseinstellungen finden Sie in den folgenden Konfigurationen.

Nächste Schritte

Einrichten von Benachrichtigungen für Prometheus-Metriken
Abfrage von Prometheus-Metriken
Erfahren Sie mehr über das Sammeln von Prometheus-Metriken.