Teilen über

Senden von Prometheus-Metriken an den Log Analytics-Arbeitsbereich mit Container Insights

  • Artikel

In diesem Artikel wird beschrieben, wie Sie Prometheus-Metriken aus Ihrem von Container Insights überwachen Kubernetes-Cluster an einen Log Analytics-Arbeitsbereich senden. Bevor Sie diese Konfiguration ausführen, sollten Sie zunächst sicherstellen, dass Sie Prometheus-Metriken aus Ihrem Cluster mithilfe des verwalteten Azure Monitor-Diensts für Prometheus extrahieren, was die empfohlene Methode für die Überwachung Ihrer Cluster ist. Verwenden Sie die in diesem Artikel beschriebene Konfiguration nur, wenn Sie dieselben Daten auch an einen Log Analytics-Arbeitsbereich senden möchten, wo Sie sie mithilfe von Protokollabfragen und Protokollsuchwarnungen analysieren können.

Für diese Konfiguration muss das Überwachungs-Add-On für den Azure Monitor-Agent konfiguriert werden, welches das gleiche ist, das von Container Insights zum Senden von Daten an einen Log Analytics-Arbeitsbereich verwendet wird. Dazu müssen Sie den Prometheus-Metrikendpunkt über Ihre Exportprogramme oder Pods verfügbar machen und dann eines der Überwachungs-Add-Ons für den Azure Monitor-Agent konfigurieren, der von Container Insights verwendet wird, wie im folgenden Diagramm dargestellt.

Diagramm der Architektur der Containerüberwachung, die Prometheus-Metriken an Azure Monitor-Protokolle sendet.

Prometheus-Scrapingeinstellungen (für als Protokolle gespeicherte Metriken)

Das aktive Scraping von Metriken aus Prometheus erfolgt aus einer der folgenden beiden Perspektiven, und Metriken werden an den konfigurierten Log Analytics-Arbeitsbereich gesendet:

  • Clusterweit: Definiert im Abschnitt „ConfigMap“ [Prometheus data_collection_settings.cluster].
  • Knotenweit: Definiert im Abschnitt „ConfigMap“ [Prometheus_data_collection_settings.node].
Endpunkt `Scope` Beispiel
Podanmerkung Clusterweit prometheus.io/scrape: "true"
prometheus.io/path: "/mymetrics"
prometheus.io/port: "8000"
prometheus.io/scheme: "http"
Kubernetes-Dienst Clusterweit http://my-service-dns.my-namespace:9100/metrics
http://metrics-server.kube-system.svc.cluster.local/metrics​
URL/Endpunkt Pro Knoten und/oder clusterweit http://myurl:9101/metrics

Wenn eine URL angegeben wird, erfasst Container Insights nur den Endpunkt. Wenn „Kubernetes-Dienst“ angegeben wird, wird der Dienstname mit dem Cluster-DNS-Server aufgelöst, um die IP-Adresse abzurufen. Anschließend wird der aufgelöste Dienst ausgelesen.

`Scope` Schlüssel Datentyp Wert BESCHREIBUNG
Clusterweit Geben Sie eine der folgenden drei Methoden zum Abrufen von Endpunkten für Metriken an.
urls String Durch Trennzeichen getrenntes Array HTTP-Endpunkt (entweder IP-Adresse oder gültiger URL-Pfad angegeben). Beispiel: urls=[$NODE_IP/metrics]. („$NODE_IP“ ist ein spezifischer Container Insights-Parameter und kann anstelle der Knoten-IP-Adresse verwendet werden. Er darf nur Großbuchstaben enthalten.)
kubernetes_services String Durch Trennzeichen getrenntes Array Ein Array von Kubernetes Services zum Abrufen von Metriken aus „kube-state-metrics“. Hier müssen vollqualifizierte Domänennamen verwendet werden. Beispiel: kubernetes_services = ["http://metrics-server.kube-system.svc.cluster.local/metrics",http://my-service-dns.my-namespace.svc.cluster.local:9100/metrics]
monitor_kubernetes_pods Boolean true oder false Wenn die Option in den clusterweiten Einstellungen auf true festgelegt ist, ruft der Container Insights-Agent aus dem gesamten Cluster für die folgenden Prometheus-Anmerkungen Kubernetes-Pods ab:
prometheus.io/scrape:
prometheus.io/scheme:
prometheus.io/path:
prometheus.io/port:
prometheus.io/scrape Boolean true oder false Aktiviert das Scraping des Pods und monitor_kubernetes_pods muss auf true festgelegt werden.
prometheus.io/scheme String http Entspricht standardmäßig Scraping über HTTP.
prometheus.io/path String Durch Trennzeichen getrenntes Array Der HTTP-Ressourcenpfad, von dem Metriken abgerufen werden sollen. Wenn der Metrikpfad nicht /metrics lautet, definieren Sie ihn mit dieser Anmerkung.
prometheus.io/port String 9102 Geben Sie einen Port an, von dem abgerufen werden soll. Wenn der Port nicht festgelegt ist, wird standardmäßig 9102 verwendet.
monitor_kubernetes_pods_namespaces String Durch Trennzeichen getrenntes Array Eine Positivliste der Namespaces zum Abrufen von Metriken von Kubernetes-Pods.
Zum Beispiel, monitor_kubernetes_pods_namespaces = ["default1", "default2", "default3"]
Knotenweit urls String Durch Trennzeichen getrenntes Array HTTP-Endpunkt (entweder IP-Adresse oder gültiger URL-Pfad angegeben). Beispiel: urls=[$NODE_IP/metrics]. („$NODE_IP“ ist ein spezifischer Container Insights-Parameter und kann anstelle der Knoten-IP-Adresse verwendet werden. Er darf nur Großbuchstaben enthalten.)
Knotenweit oder clusterweit interval String 60s Der Standardwert für das Sammlungsintervall ist eine Minute (60 Sekunden). Sie können die Sammlung entweder für [prometheus_data_collection_settings.node] und/oder für [prometheus_data_collection_settings.cluster] in Zeiteinheiten wie s, m und h ändern.
Knotenweit oder clusterweit fieldpass
fielddrop		 String Durch Trennzeichen getrenntes Array Sie können bestimmte Metriken angeben, die vom Endpunkt erfasst werden sollen oder nicht, indem Sie die Zulassungs- (fieldpass) und Sperrauflistung (fielddrop) festlegen. Sie müssen zunächst die Positivliste festlegen.

Konfigurieren von ConfigMaps zum Angeben der Prometheus-Scrapekonfiguration (für als Protokolle gespeicherte Metriken)

Führen Sie die folgenden Schritte aus, um Ihre ConfigMap-Konfigurationsdatei für Ihren Cluster zu konfigurieren. ConfigMaps ist eine globale Liste, und es kann nur eine ConfigMap auf den Agent angewendet werden. Es kann keine andere ConfigMaps vorhanden sein, die die Sammlungen außer Kraft setzt.

  1. Laden Sie die YAML-Vorlagendatei für ConfigMap herunter und speichern Sie sie unter container-azm-ms-agentconfig.yaml. Wenn Sie bereits eine ConfigMap in Ihrem Cluster bereitgestellt haben und sie mit einer neueren Konfiguration aktualisieren möchten, können Sie die zuvor verwendete ConfigMap-Datei bearbeiten.

  2. Passen Sie die ConfigMap YAML-Datei für das Auslesen von Prometheus-Metriken wie gewünscht an.

    Zum Sammeln von Kubernetes-Diensten für den gesamten Cluster konfigurieren Sie die ConfigMap-Datei anhand des folgenden Beispiels:

    prometheus-data-collection-settings: |- ​
# Custom Prometheus metrics data collection settings
[prometheus_data_collection_settings.cluster] ​
interval = "1m"  ## Valid time units are s, m, h.
fieldpass = ["metric_to_pass1", "metric_to_pass12"] ## specify metrics to pass through ​
fielddrop = ["metric_to_drop"] ## specify metrics to drop from collecting
kubernetes_services = ["http://my-service-dns.my-namespace:9102/metrics"]

  3. Führen Sie den folgenden kubectl-Befehl aus: kubectl apply -f <configmap_yaml_file.yaml>.

    Beispiel: kubectl apply -f container-azm-ms-agentconfig.yaml.

Die Änderung der Konfiguration kann einige Minuten dauern, bevor sie wirksam wird. Alle ama-logs-Pods im Cluster werden neu gestartet. Wenn die Neustarts abgeschlossen sind, wird eine Meldung angezeigt, die der folgenden ähnelt und das Ergebnis configmap "container-azm-ms-agentconfig" created enthält.

Überprüfen der Konfiguration

Verwenden Sie den folgenden Befehl zum Überprüfen der Protokolle aus einem Agent-Pod, um sich zu vergewissern, dass die Konfiguration erfolgreich auf einen Cluster angewandt wurde: kubectl logs ama-logs-fdf58 -n=kube-system.

Bei Konfigurationsfehlern aus den Azure Monitor-Agent-Pods werden in der Ausgabe Fehler ähnlich dem folgenden Beispiel angezeigt:

***************Start Config Processing******************** 
config::unsupported/missing config schema version - 'v21' , using defaults

Fehler im Zusammenhang mit der Anwendung von Konfigurationsänderungen können ebenfalls überprüft werden. Die folgenden Optionen stehen zur zusätzlichen Problembehandlung bei Konfigurationsänderungen und dem Abrufen von Prometheus-Metriken zur Verfügung:

  • In einem Agent-Pod-Protokoll mithilfe desselben kubectl logs-Befehls.

  • Aus Livedaten. In Livedatenprotokollen werden ähnliche Fehler wie im folgenden Beispiel angezeigt:

    2019-07-08T18:55:00Z E! [inputs.prometheus]: Error in plugin: error making HTTP request to http://invalidurl:1010/metrics: Get http://invalidurl:1010/metrics: dial tcp: lookup invalidurl on 10.0.0.10:53: no such host

  • In der Tabelle KubeMonAgentEvents in Ihrem Log Analytics Arbeitsbereich. Die Daten werden stündlich mit dem Schweregrad Warnung für Abruffehler und dem Schweregrad Fehler für Konfigurationsfehler gesendet. Wenn keine Fehler vorliegen, enthält der Tabelleneintrag Daten mit dem Schweregrad Info, der Fehlerfreiheit angibt. Die Tags-Eigenschaft enthält weitere Informationen zum Pod und der Container-ID, für die der Fehler aufgetreten ist, sowie zum ersten Vorkommen, zum letzten Vorkommen und zur Anzahl in der letzten Stunde.

  • Überprüfen Sie bei Azure Red Hat OpenShift v3.x und v4.x die Azure Monitor-Agent-Protokolle, indem Sie die Tabelle ContainerLog durchsuchen, um zu überprüfen, ob die Protokollsammlung von „openshift-azure-logging“ aktiviert ist.

Fehler verhindern die Analyse der Datei durch den Azure Monitor-Agent, weshalb ein Neustart erfolgt und die Standardkonfiguration verwendet wird. Nachdem Sie für andere Cluster als Azure Red Hat OpenShift v3.x die Fehler in der ConfigMap korrigiert haben, speichern Sie die YAML-Datei, und führen Sie die aktualisierte ConfigMap mit dem Befehl kubectl apply -f <configmap_yaml_file.yaml aus.

Im Fall von Azure Red Hat OpenShift v3.x bearbeiten und speichern Sie die aktualisierte ConfigMap, indem Sie den Befehl oc edit configmaps container-azm-ms-agentconfig -n openshift-azure-logging ausführen.

Abfragen von Prometheus-Metrikdaten

Weitere Informationen zum Anzeigen von Prometheus-Metriken, die von Azure Monitor abgerufen wurden, und vom Agent gemeldeten Konfigurations-/Scraping-Fehlern finden Sie unter Abfragen von Prometheus-Metrikdaten.

Anzeigen von Prometheus-Metriken in Grafana

Container Insights unterstützt das Anzeigen von Metriken, die in Ihrem Log Analytics Arbeitsbereich in Grafana-Dashboards gespeichert sind. Wir haben eine Vorlage bereitgestellt, die Sie aus dem Dashboard-Repository von Grafana herunterladen können. Verwenden Sie die Vorlage für die ersten Schritte und verweisen Sie darauf, um zu lernen, wie Sie andere Daten aus Ihren überwachten Clustern abfragen können, um in benutzerdefinierten Grafana-Dashboards zu visualisieren.

Nächste Schritte