**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Überwachung Ihrer Cluster-Metriken mit Prometheus [Prometheus](https://prometheus.io/) ist eine Überwachungs- und Zeitreihendatenbank, die Endpunkte durchsucht. Sie bietet die Möglichkeit, gesammelte Daten abzufragen, zu aggregieren und zu speichern. Sie können sie auch für Warnungen und für die Aggregation von Warnungen verwenden. In diesem Thema wird erläutert, wie Sie Prometheus entweder als verwaltete oder als Open-Source-Option einrichten. Die Überwachung der Metriken der Amazon-EKS-Steuerebene ist ein häufiger Anwendungsfall. Amazon Managed Service for Prometheus ist ein Prometheus-kompatibler Überwachungs- und Warndienst, der es einfach macht, containerisierte Anwendungen und Infrastruktur im großen Maßstab zu überwachen. Es ist ein vollständig verwalteter Service, der die Aufnahme, Speicherung, Abfrage und Warnung Ihrer Metriken automatisch skaliert. Es lässt sich auch in AWS-Sicherheits-Services integrieren, um einen schnellen und sicheren Zugriff auf Ihre Daten zu ermöglichen. Sie können die Open-Source-PromQL-Abfragesprache verwenden, um Ihre Metriken abzufragen und darauf zu warnen. Außerdem können Sie den Alarmmanager im Amazon Managed Service für Prometheus verwenden, um Warnregeln für kritische Alarme einzurichten. Diese kritischen Warnmeldungen können Sie dann als Benachrichtigungen an ein Amazon-SNS-Thema senden. Es gibt mehrere verschiedene Möglichkeiten, Prometheus mit Amazon EKS zu verwenden: + Sie können die Prometheus-Metriken beim erstmaligen Erstellen eines Amazon-EKS-Clusters aktivieren oder einen eigenen Prometheus-Scraper für vorhandene Cluster erstellen. Beide Optionen werden in diesem Thema behandelt. + Sie können Prometheus mithilfe von Helm bereitstellen. Weitere Informationen finden Sie unter [Prometheus mithilfe von Helm bereitstellen](deploy-prometheus.md). + Sie können die Rohdaten der Steuerebene im Prometheus-Format anzeigen. Weitere Informationen finden Sie unter [Rohmetriken der Steuerebene im Prometheus-Format abrufen](view-raw-metrics.md). ## Schritt 1: Prometheus-Metriken aktivieren **Wichtig** Amazon Managed Service für Prometheus-Ressourcen liegen außerhalb des Cluster-Lebenszyklus und müssen unabhängig vom Cluster verwaltet werden. Wenn Sie Ihren Cluster löschen, löschen Sie auch alle relevanten Scraper, um damit verbundenen Kosten zu vermeiden. Weitere Informationen finden Sie unter [Suchen und Löschen eine Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*. Prometheus entdeckt und erfasst Metriken aus Ihrem Cluster mithilfe eines Abruf-basierten Modells, das als Scraping bezeichnet wird. Scraper sind dafür eingerichtet, Daten aus Ihrer Cluster-Infrastruktur und containerisierten Anwendungen zu sammeln. Wenn Sie die Option zum Senden von Prometheus-Metriken aktivieren, stellt Amazon Managed Service for Prometheus einen vollständig verwalteten, agentenlosen Scraper zur Verfügung. Falls Sie den Cluster noch nicht erstellt haben, können Sie die Option zum Senden von Metriken an Prometheus bei der erstmaligen Erstellung des Clusters aktivieren. In der Amazon-EKS-Konsole finden Sie diese Option im Schritt **Beobachtbarkeit konfigurieren** bei der Erstellung eines neuen Clusters. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md). Wenn Sie bereits über einen vorhandenen Cluster verfügen, können Sie Ihren eigenen Prometheus-Scraper erstellen. Navigieren Sie dazu in der Amazon-EKS-Konsole zur Registerkarte **Beobachtbarkeit** Ihres Clusters und wählen Sie die Schaltfläche **Scraper hinzufügen**. Wenn Sie dies lieber mit der AWS-API oder AWS CLI tun möchten, finden Sie weitere Informationen unter [Erstellen eines Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) im *Benutzerhandbuch für Amazon Managed Service für Prometheus*. Beim Erstellen des Scrapers mit der Amazon-EKS-Konsole stehen die folgenden Optionen zur Verfügung. **Scraper-Alias** (Optional) Geben Sie einen eindeutigen Alias für den Scraper ein. **Zieladresse** Wählen Sie einen Workspace für Amazon Managed Service für Prometheus aus. Ein Workspace ist ein logischer Bereich, der der Speicherung und Abfrage von Prometheus-Metriken gewidmet ist. Mit diesem Arbeitsbereich können Sie Prometheus-Metriken für alle Konten anzeigen, die darauf zugreifen können. Die Option **Neuen Workspace erstellen** weist Amazon EKS an, unter Verwendung des von Ihnen angegebenen **Workspace-Alias** einen Workspace in Ihrem Namen zu erstellen. Mit der Option **Bestehenden Workspace auswählen** können Sie einen vorhandenen Workspace aus einer Dropdown-Liste auswählen. Weitere Informationen zu Workspaces finden Sie unter [Workspaces verwalten](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-manage-ingest-query.html) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*. **Service-Zugriff** Dieser Abschnitt fasst die Berechtigungen zusammen, die Sie beim Senden von Prometheus-Metriken gewähren: + Zulassen, dass Amazon Managed Service für Prometheus den gescrapten Amazon-EKS-Cluster beschreibt + Schreiben aus der Ferne in den Amazon-Managed-Prometheus-Arbeitsbereich zulassen Wenn `AmazonManagedScraperRole` bereits vorhanden ist, verwendet der Scraper diese Rolle. Wählen Sie den `AmazonManagedScraperRole`-Link aus, um die **Berechtigungsdetails** anzuzeigen. Wenn `AmazonManagedScraperRole` noch nicht vorhanden ist, wählen Sie den Link **Berechtigungsdetails anzeigen**, um die spezifischen Berechtigungen anzuzeigen, die Sie durch das Senden von Prometheus-Metriken gewähren. **Subnets** Ändern Sie die Subnetze, die der Scraper übernehmen soll, nach Bedarf. Wenn Sie eine ausgegraute Subnetzoption hinzufügen müssen, kehren Sie zum Schritt der Cluster-Erstellung unter **Netzwerk angeben** zurück. **Scraper-Konfiguration** Ändern Sie die Scraper-Konfiguration nach Bedarf im YAML-Format. Verwenden Sie dazu das Formular oder laden Sie eine YAML-Ersatzdatei hoch. Weitere Informationen finden Sie unter [Scraper-Konfiguration](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*. Amazon Managed Service für Prometheus bezieht sich auf den agentenlosen Scraper, der zusammen mit dem Cluster als verwalteter AWS-Sammler erstellt wird. Weitere Informationen zu von AWS verwalteten Kollektoren finden Sie unter [Erfassen von Metriken mit von AWS verwalteten Kollektoren](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) im *Benutzerhandbuch zu Amazon Managed Service für Prometheus*. **Wichtig** Wenn Sie einen Prometheus-Scraper mithilfe der AWS CLI oder AWS-API erstellen, müssen Sie seine Konfiguration anpassen, um dem Scraper Berechtigungen im Cluster zu gewähren. Weitere Informationen finden Sie unter [Konfigurieren Ihres Amazon-EKS-Clusters](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*. Wenn Sie einen Prometheus-Scraper haben, der vor dem 11. November 2024 erstellt wurde und `aws-auth` `ConfigMap` anstelle von Zugriffseinträgen verwendet, müssen Sie ihn aktualisieren, um auf zusätzliche Metriken aus der Amazon-EKS-Cluster-Steuerebene zugreifen zu können. Informationen zur aktualisierten Konfiguration finden Sie unter [Manuelle Konfiguration von Amazon EKS für Scraper-Zugriff](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-manual-setup) im *Benutzerhandbuch zu Amazon Managed Service für Prometheus*. ## Schritt 2: Prometheus-Metriken verwenden Weitere Informationen zur Verwendung der Prometheus-Metriken, nachdem Sie sie für Ihren Cluster aktiviert haben, finden Sie im [Benutzerhandbuch für Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html). ## Schritt 3: Prometheus-Scraper verwalten Wählen Sie zur Verwaltung von Scrapern in der Amazon-EKS-Konsole die Registerkarte **Beobachtbarkeit** aus. Eine Tabelle zeigt eine Liste der Scraper für den Cluster, einschließlich Informationen wie Scraper-ID, Alias, Status und Erstellungsdatum. Sie können weitere Scraper hinzufügen, Scraper bearbeiten, Scraper löschen oder weitere Informationen zu den aktuellen Scrapern anzeigen. Um weitere Details zu einem Scraper anzuzeigen, wählen Sie den Scraper-ID-Link. Sie können beispielsweise ARN, Umgebung, Arbeitsbereichs-ID, IAM-Rolle, Konfiguration und Netzwerkinformationen anzeigen. Sie können die Scraper-ID als Eingabe für Operationen in der Amazon-Managed-Service-für-Prometheus-API wie [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html), [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html) und [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html) verwenden. Weitere Informationen zur Verwendung der Prometheus-API finden Sie in der [API-Referenz zu Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-APIReference.html). # Prometheus mithilfe von Helm bereitstellen Als Alternative zur Verwendung von Amazon Managed Service für Prometheus können Sie Prometheus mit Helm in Ihrem Cluster bereitstellen. Wenn Sie Helm bereits installiert haben, können Sie Ihre Version mit dem `helm version`-Befehl überprüfen. Helm ist ein Paket-Manager für Kubernetes-Cluster. Weitere Informationen zu Helm und zur Installation finden Sie unter [Bereitstellung von Anwendungen mit Helm in Amazon EKS](helm.md). Nachdem Sie Helm für Ihren Amazon-EKS-Cluster konfiguriert haben, können Sie damit die folgenden Schritte ausführen, um Prometheus bereitzustellen. 1. Erstellen Sie einen Prometheus-Namespace. ``` kubectl create namespace prometheus ``` 1. Fügen Sie das `prometheus-community`-Diagramm-Repository hinzu. ``` helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ``` 1. Stellen Sie Prometheus bereit. ``` helm upgrade -i prometheus prometheus-community/prometheus \ --namespace prometheus \ --set alertmanager.persistence.storageClass="gp2" \ --set server.persistentVolume.storageClass="gp2" ``` **Anmerkung** Wenn Sie bei der Ausführung dieses Befehls die Fehlermeldung `Error: failed to download "stable/prometheus" (hint: running helm repo update may help)` erhalten, führen Sie `helm repo update prometheus-community` aus, und versuchen Sie dann erneut, den Befehl aus Schritt 2 auszuführen. Wenn Sie die Fehlermeldung `Error: rendered manifests contain a resource that already exists` erhalten, führen Sie `helm uninstall your-release-name -n namespace ` aus, und versuchen Sie dann, den Befehl aus Schritt 3 erneut auszuführen. 1. Stellen Sie sicher, dass alle Pods im `prometheus`-Namespace den Status `READY` haben. ``` kubectl get pods -n prometheus ``` Eine Beispielausgabe sieht wie folgt aus. ``` NAME READY STATUS RESTARTS AGE prometheus-alertmanager-59b4c8c744-r7bgp 1/2 Running 0 48s prometheus-kube-state-metrics-7cfd87cf99-jkz2f 1/1 Running 0 48s prometheus-node-exporter-jcjqz 1/1 Running 0 48s prometheus-node-exporter-jxv2h 1/1 Running 0 48s prometheus-node-exporter-vbdks 1/1 Running 0 48s prometheus-pushgateway-76c444b68c-82tnw 1/1 Running 0 48s prometheus-server-775957f748-mmht9 1/2 Running 0 48s ``` 1. Verwenden Sie `kubectl`, um die Prometheus-Konsole auf Ihren lokalen Computer weiterzuleiten. ``` kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090 ``` 1. Richten Sie einen Web-Browser auf `http://localhost:9090`, um die Prometheus-Konsole anzuzeigen. 1. Wählen Sie eine Metrik aus dem Menü **- insert metric at cursor** (Metrik bei Cursor eingeben) und danach **Execute** (Ausführen). Wählen Sie die Registerkarte **Graph** (Diagramm) aus, um die Metrik im Zeitverlauf anzuzeigen. Das folgende Image zeigt `container_memory_usage_bytes` im Zeitverlauf. ![\[Prometheus-Metriken\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/prometheus-metric.png) 1. Wählen Sie in der oberen Navigationsleiste **Status**, dann **Targets** (Ziele). ![\[Prometheus-Konsole\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/prometheus.png) Es werden alle Kubernetes-Endpunkte angezeigt, die über die Service-Erkennung mit Prometheus verbunden sind. # Rohmetriken der Steuerebene im Prometheus-Format abrufen Die Kubernetes-Steuerebene stellt eine Reihe von Metriken bereit, die im [Prometheus-Format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) dargestellt werden. Diese Metriken sind für die Überwachung und Analyse hilfreich. Sie werden intern über Metrik-Endpunkte bereitgestellt und können ohne vollständige Bereitstellung von Prometheus abgerufen werden. Die Bereitstellung von Prometheus vereinfacht jedoch die Analyse von Metriken im Zeitverlauf. Um die Rohdaten der Metriken anzuzeigen, ersetzen Sie `endpoint` und führen Sie den folgenden Befehl aus. ``` kubectl get --raw endpoint ``` Mit diesem Befehl können Sie einen beliebigen Endpunktpfad übergeben und erhalten die Rohdaten als Antwort zurück. Die Ausgabe listet zeilenweise verschiedene Metriken auf, wobei jede Zeile einen Metriknamen, Tags und einen Wert enthält. ``` metric_name{tag="value"[,...]} value ``` ## Metriken vom API-Server abrufen Der allgemeine API-Server-Endpunkt wird in der Amazon-EKS-Steuerebene bereitgestellt. Dieser Endpunkt ist vor allem nützlich, wenn Sie eine bestimmte Metrik betrachten möchten. ``` kubectl get --raw /metrics ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] # HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host. # TYPE rest_client_requests_total counter rest_client_requests_total{code="200",host="127.0.0.1:21362",method="POST"} 4994 rest_client_requests_total{code="200",host="127.0.0.1:443",method="DELETE"} 1 rest_client_requests_total{code="200",host="127.0.0.1:443",method="GET"} 1.326086e+06 rest_client_requests_total{code="200",host="127.0.0.1:443",method="PUT"} 862173 rest_client_requests_total{code="404",host="127.0.0.1:443",method="GET"} 2 rest_client_requests_total{code="409",host="127.0.0.1:443",method="POST"} 3 rest_client_requests_total{code="409",host="127.0.0.1:443",method="PUT"} 8 # HELP ssh_tunnel_open_count Counter of ssh tunnel total open attempts # TYPE ssh_tunnel_open_count counter ssh_tunnel_open_count 0 # HELP ssh_tunnel_open_fail_count Counter of ssh tunnel failed open attempts # TYPE ssh_tunnel_open_fail_count counter ssh_tunnel_open_fail_count 0 ``` Diese Rohausgabe zeigt exakt das, was der API-Server bereitstellt. ## Metriken der Steuerebene mit `metrics.eks.amazonaws.com` abrufen Für Cluster mit Kubernetes-Version `1.28` und höher stellt Amazon EKS auch Metriken unter der API-Gruppe `metrics.eks.amazonaws.com` bereit. Diese Metriken umfassen Steuerebenen-Komponenten wie `kube-scheduler` und `kube-controller-manager`. **Anmerkung** Wenn Sie über eine Webhook-Konfiguration verfügen, welche die Erstellung der neuen `APIService`-Ressource `v1.metrics.eks.amazonaws.com` in Ihrem Cluster blockieren könnte, ist das Feature des Metrik-Endpunkts möglicherweise nicht verfügbar. Sie können dies im Überwachungsprotokoll `kube-apiserver` überprüfen, indem Sie nach dem Schlüsselwort `v1.metrics.eks.amazonaws.com` suchen. ### `kube-scheduler`-Metriken abrufen Verwenden Sie zum Abrufen von `kube-scheduler`-Metriken den folgenden Befehl. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics" ``` Eine Beispielausgabe sieht wie folgt aus. ``` # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 0 scheduler_pending_pods{queue="backoff"} 0 scheduler_pending_pods{queue="gated"} 0 scheduler_pending_pods{queue="unschedulable"} 18 # HELP scheduler_pod_scheduling_attempts [STABLE] Number of attempts to successfully schedule a pod. # TYPE scheduler_pod_scheduling_attempts histogram scheduler_pod_scheduling_attempts_bucket{le="1"} 79 scheduler_pod_scheduling_attempts_bucket{le="2"} 79 scheduler_pod_scheduling_attempts_bucket{le="4"} 79 scheduler_pod_scheduling_attempts_bucket{le="8"} 79 scheduler_pod_scheduling_attempts_bucket{le="16"} 79 scheduler_pod_scheduling_attempts_bucket{le="+Inf"} 81 [...] ``` ### `kube-controller-manager`-Metriken abrufen Verwenden Sie zum Abrufen von `kube-controller-manager`-Metriken den folgenden Befehl. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics" ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] workqueue_work_duration_seconds_sum{name="pvprotection"} 0 workqueue_work_duration_seconds_count{name="pvprotection"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-08"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-07"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-05"} 19 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.001"} 109 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.01"} 139 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.1"} 181 workqueue_work_duration_seconds_bucket{name="replicaset",le="1"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="10"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="+Inf"} 191 workqueue_work_duration_seconds_sum{name="replicaset"} 4.265655885000002 [...] ``` ### Metriken des Schedulers und des Controller-Managers verstehen In der folgenden Tabelle werden die Scheduler- und Controller-Manager-Metriken beschrieben, die für das Scraping im Prometheus-Stil verfügbar gemacht werden. eitere Informationen zu diesen Metriken finden Sie in der [Kubernetes-Metriken-Referenz](https://kubernetes.io/docs/reference/instrumentation/metrics/) in der Kubernetes-Dokumentation. | Metrik | Komponente der Steuerebene | Beschreibung | | --- | --- | --- | | scheduler\$1pending\$1pods | Scheduler | Die Anzahl der Pods, die darauf warten, zur Ausführung in einen Knoten geplant zu werden. | | scheduler\$1schedule\$1attempts\$1total | Scheduler | Die Anzahl der Versuche, Pods zu planen. | | scheduler\$1preemption\$1attempts\$1total | Scheduler | Die Anzahl der Versuche des Schedulers, Pods mit höherer Priorität zu planen, indem Pods mit niedrigerer Priorität entfernt werden. | | scheduler\$1preemption\$1victims | Scheduler | Die Anzahl der Pods, die zur Bereinigung ausgewählt wurden, um Platz für Pods mit höherer Priorität zu schaffen. | | scheduler\$1pod\$1scheduling\$1attempts | Scheduler | Die Anzahl der Versuche, einen Pod erfolgreich zu planen. | | scheduler\$1scheduling\$1attempt\$1duration\$1seconds | Scheduler | Gibt an, wie schnell oder langsam der Scheduler in der Lage ist, einen geeigneten Ausführungsort für einen Pod zu finden, basierend auf verschiedenen Faktoren wie Ressourcenverfügbarkeit und Planungsregeln. | | scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | Scheduler | Die durchgängige Latenz für einen Pod, der geplant wird, ab dem Zeitpunkt, an dem der Pod in die Planungswarteschlange aufgenommen wird. Dies kann mehrere Planungsversuche umfassen. | | cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | controller manager | Der Zeitraum zwischen der geplanten Ausführung eines Cronjobs und der Erstellung des entsprechenden Auftrags. | | workqueue\$1depth | controller manager | Die aktuelle Ebene der Warteschlange. | | workqueue\$1adds\$1total | controller manager | Die Gesamtzahl der von der Arbeitswarteschlange bearbeiteten Einträge. | | workqueue\$1queue\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die ein Element in der Arbeitswarteschlange verbleibt, bevor es angefordert wird. | | workqueue\$1work\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die für die Bearbeitung eines Elements aus der Arbeitswarteschlange benötigt wird. | ## Prometheus-Scraper einsetzen, um Metriken konsistent zu scrapen Um einen Prometheus-Scraper einzusetzen, der die Metriken konsistent scrapt, verwenden Sie die folgende Konfiguration: ``` --- apiVersion: v1 kind: ConfigMap metadata: name: prometheus-conf data: prometheus.yml: |- global: scrape_interval: 30s scrape_configs: # apiserver metrics - job_name: apiserver-metrics kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Scheduler metrics - job_name: 'ksh-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Controller Manager metrics - job_name: 'kcm-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https --- apiVersion: v1 kind: Pod metadata: name: prom-pod spec: containers: - name: prom-container image: prom/prometheus ports: - containerPort: 9090 volumeMounts: - name: config-volume mountPath: /etc/prometheus/ volumes: - name: config-volume configMap: name: prometheus-conf ``` Die folgende Berechtigung ist erforderlich, damit der Pod auf den neuen Metrik-Endpunkt zugreifen kann. ``` { "effect": "allow", "apiGroups": [ "metrics.eks.amazonaws.com" ], "resources": [ "kcm/metrics", "ksh/metrics" ], "verbs": [ "get" ] }, ``` Um die verwendete Rolle zu patchen, können Sie den folgenden Befehl verwenden. ``` kubectl patch clusterrole --type=json -p='[ { "op": "add", "path": "/rules/-", "value": { "verbs": ["get"], "apiGroups": ["metrics.eks.amazonaws.com"], "resources": ["kcm/metrics", "ksh/metrics"] } } ]' ``` Anschließend können Sie das Prometheus-Dashboard anzeigen, indem Sie den Port des Prometheus-Scrapers auf Ihren lokalen Port umstellen. ``` kubectl port-forward pods/prom-pod 9090:9090 ``` Für Ihren Amazon-EKS-Cluster werden die Kernmetriken der Kubernetes-Steuerebene auch unter dem `AWS/EKS`-Namespace in Amazon CloudWatch-Metriken aufgenommen. Um sie anzuzeigen, öffnen Sie die [CloudWatch-Konsole](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) und wählen Sie im linken Navigationsbereich **Alle Metriken** aus. Wählen Sie auf der Auswahlseite **Metriken** den `AWS/EKS`-Namespace und eine Metrikdimension für Ihren Cluster aus.