Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Überwachen Prometheus, ein [abgeschlossenes CNCF-Projekt](https://www.cncf.io/projects/), ist mit Abstand das beliebteste Monitoring-System mit nativer Integration in Kubernetes. Prometheus sammelt Metriken rund um Container, Pods, Knoten und Cluster. Darüber hinaus können Sie mit Prometheus Warnmeldungen programmieren AlertsManager , die Sie warnen, wenn etwas in Ihrem Cluster schief läuft. Prometheus speichert die Metrikdaten als Zeitreihendaten, die durch Metriknamen und key/value Paare identifiziert werden. Prometheus bietet eine Möglichkeit, Abfragen mit einer Sprache namens PromQL durchzuführen, was die Abkürzung für Prometheus Query Language ist. Die allgemeine Architektur der Prometheus-Metrikerfassung ist unten dargestellt: ![\[Sammlung Prometheus Metrics\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/windows/prom.png) [Prometheus verwendet einen Pull-Mechanismus und scannt Metriken von Zielen mithilfe von Exportern und von der Kubernetes-API mithilfe der Kube-State-Metriken.](https://github.com/kubernetes/kube-state-metrics) Das bedeutet, dass Anwendungen und Dienste einen HTTP (S) -Endpunkt bereitstellen müssen, der Metriken im Prometheus-Format enthält. Prometheus ruft dann gemäß seiner Konfiguration regelmäßig Metriken von diesen HTTP (S) -Endpunkten ab. Mit einem Exporter können Sie Metriken von Drittanbietern als Metriken im Prometheus-Format verwenden. Ein Prometheus-Exporter wird normalerweise auf jedem Knoten bereitgestellt. [Eine vollständige Liste der Exporteure finden Sie bei den Prometheus-Exporteuren.](https://prometheus.io/docs/instrumenting/exporters/) Der [Node Exporter](https://github.com/prometheus/node_exporter) eignet sich zwar für den Export von Host-Hardware und Betriebssystem-Metriken für Linux-Knoten, funktioniert aber nicht für Windows-Knoten. Wenn Sie in einem **EKS-Cluster mit gemischten Knoten und Windows-Knoten** das stabile [Prometheus-Helmdiagramm](https://github.com/prometheus-community/helm-charts) verwenden, werden Sie ausgefallene Pods auf den Windows-Knoten sehen, da dieser Exporter nicht für Windows vorgesehen ist. Sie müssen den Windows-Worker-Pool separat behandeln und stattdessen den [Windows-Exporter in der Windows-Worker-Knotengruppe](https://github.com/prometheus-community/windows_exporter) installieren. Um die Prometheus-Überwachung für Windows-Knoten einzurichten, müssen Sie den WMI-Exporter herunterladen und auf dem Windows-Server selbst installieren und dann die Ziele in der Scrape-Konfiguration der Prometheus-Konfigurationsdatei einrichten. Auf der [Releases-Seite](https://github.com/prometheus-community/windows_exporter/releases) finden Sie alle verfügbaren .msi-Installationsprogramme mit den entsprechenden Funktionen und Bugfixes. Das Installationsprogramm richtet den windows\$1exporter als Windows-Dienst ein und erstellt eine Ausnahme in der Windows-Firewall. Wenn das Installationsprogramm ohne Parameter ausgeführt wird, wird der Exporter mit den Standardeinstellungen für aktivierte Collectors, Ports usw. ausgeführt. Sie können sich den Abschnitt mit **bewährten Methoden RuntimeClass zur Terminplanung** dieses Handbuchs ansehen, in dem die Verwendung taints/tolerations oder selektive Bereitstellung des Node-Exporters nur für Linux-Knoten empfohlen wird, während der Windows-Exporter auf Windows-Knoten installiert wird, während Sie den Knoten booten oder ein Konfigurationsmanagement-Tool Ihrer Wahl verwenden (z. B. Chef, Ansible, SSM usw.). Beachten Sie, dass im Gegensatz zu den Linux-Knoten, auf denen der Node Exporter als Daemonset installiert ist, der WMI-Exporter auf Windows-Knoten auf dem Host selbst installiert ist. Der Exporter exportiert Messwerte wie die CPU-Auslastung, den Arbeitsspeicher und die I/O Festplattennutzung und kann auch zur Überwachung von IIS-Websites und -Anwendungen, Netzwerkschnittstellen und -diensten verwendet werden. Der windows\$1exporter macht standardmäßig alle Metriken von aktivierten Collectors verfügbar. Dies ist die empfohlene Methode zum Sammeln von Metriken, um Fehler zu vermeiden. Für fortgeschrittene Benutzer kann dem windows\$1exporter jedoch eine optionale Liste von Kollektoren zum Filtern von Metriken übergeben werden. Mit dem Parameter collect [] in der Prometheus-Konfiguration können Sie das tun. Zu den Standardinstallationsschritten für Windows gehört das Herunterladen und Starten des Exporters als Dienst während des Bootstrapping-Vorgangs mit Argumenten, z. B. den Collectors, die Sie filtern möchten. ``` > Powershell Invoke-WebRequest https://github.com/prometheus-community/windows_exporter/releases/download/v0.13.0/windows_exporter-0.13.0-amd64.msi -OutFile > msiexec /i ENABLED_COLLECTORS="cpu,cs,logical_disk,net,os,system,container,memory" ``` Standardmäßig können die Metriken am Endpunkt /metrics auf Port 9182 gescrapt werden. Zu diesem Zeitpunkt kann Prometheus die Metriken verwenden, indem es der Prometheus-Konfiguration die folgende scrape\$1config hinzufügt ``` scrape_configs: - job_name: "prometheus" static_configs: - targets: ['localhost:9090'] ... - job_name: "wmi_exporter" scrape_interval: 10s static_configs: - targets: [':9182', ':9182', ...] ``` Prometheus Prometheus-Konfiguration wird neu geladen mit ``` > ps aux | grep prometheus > kill HUP ``` Eine bessere und empfohlene Methode zum Hinzufügen von Zielen besteht darin, eine benutzerdefinierte Ressourcendefinition namens zu verwenden ServiceMonitor, die Teil des [Prometheus-Operators](https://github.com/prometheus-operator/kube-prometheus/releases) ist], der die Definition für ein ServiceMonitor Objekt und einen Controller bereitstellt, der die We-Definition aktiviert und automatisch die ServiceMonitors erforderliche Prometheus-Konfiguration erstellt. Der ServiceMonitor, der deklarativ festlegt, wie Gruppen von Kubernetes-Diensten überwacht werden sollen, wird verwendet, um eine Anwendung zu definieren, aus der Sie Metriken in Kubernetes auslesen möchten. Darin spezifizieren ServiceMonitor wir die Kubernetes-Labels, anhand derer der Betreiber den Kubernetes-Dienst identifizieren kann, der wiederum die Pods identifiziert, die wir überwachen möchten. Um das zu nutzen ServiceMonitor, erstellen Sie ein Endpunktobjekt, das auf bestimmte Windows-Ziele verweist, einen Headless-Service und einen ServiceMontor für die Windows-Knoten. ``` apiVersion: v1 kind: Endpoints metadata: labels: k8s-app: wmiexporter name: wmiexporter namespace: kube-system subsets: - addresses: - ip: NODE-ONE-IP targetRef: kind: Node name: NODE-ONE-NAME - ip: NODE-TWO-IP targetRef: kind: Node name: NODE-TWO-NAME - ip: NODE-THREE-IP targetRef: kind: Node name: NODE-THREE-NAME ports: - name: http-metrics port: 9182 protocol: TCP --- apiVersion: v1 kind: Service ##Headless Service metadata: labels: k8s-app: wmiexporter name: wmiexporter namespace: kube-system spec: clusterIP: None ports: - name: http-metrics port: 9182 protocol: TCP targetPort: 9182 sessionAffinity: None type: ClusterIP --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor ##Custom ServiceMonitor Object metadata: labels: k8s-app: wmiexporter name: wmiexporter namespace: monitoring spec: endpoints: - interval: 30s port: http-metrics jobLabel: k8s-app namespaceSelector: matchNames: - kube-system selector: matchLabels: k8s-app: wmiexporter ``` Weitere Informationen zum Betreiber und zur Verwendung von finden Sie in der ServiceMonitor offiziellen [Betreiberdokumentation](https://github.com/prometheus-operator/kube-prometheus). Beachten Sie, dass Prometheus die dynamische Zielerkennung mithilfe vieler [Service](https://prometheus.io/blog/2015/06/01/advanced-service-discovery/) Discovery-Optionen unterstützt.