

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.

# Protokollieren und Überwachen in Amazon EKS
<a name="amazon-eks-logging-monitoring"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) ist in CloudWatch Logs für die Kubernetes-Steuerebene integriert. Die Kontrollebene wird als verwalteter Service von Amazon EKS bereitgestellt, und Sie können die [Protokollierung aktivieren, ohne einen CloudWatch Agenten zu installieren](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html). Der CloudWatch Agent kann auch zur Erfassung von Knoten- und Container-Protokollen von Amazon EKS eingesetzt werden. [Fluent Bit und Fluentd](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-logs.html) werden auch für das Senden Ihrer Container-Protokolle an Logs unterstützt. CloudWatch 

CloudWatch Container Insights bietet eine umfassende Lösung zur Überwachung von Kennzahlen für Amazon EKS auf Cluster-, Knoten-, Pod-, Aufgaben- und Serviceebene. Amazon EKS unterstützt auch mehrere Optionen für die Erfassung von Metriken mit [Prometheus](https://prometheus.io/). Die Amazon EKS-Kontrollebene [bietet einen Metriken-Endpunkt](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html), der Metriken in einem Prometheus-Format bereitstellt. Sie können Prometheus in Ihrem Amazon EKS-Cluster bereitstellen, um diese Metriken zu nutzen. 

Sie können [den CloudWatch Agenten auch so einrichten, dass er Prometheus-Metriken scannt und CloudWatch Metriken erstellt und zusätzlich andere Prometheus-Endpunkte](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html) nutzt. [Container Insights Monitoring for Prometheus](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html) kann auch automatisch Prometheus-Metriken von unterstützten, containerisierten Workloads und Systemen erkennen und erfassen. 

Sie können den CloudWatch Agenten auf Ihren Amazon EKS-Knoten installieren und konfigurieren, ähnlich wie bei Amazon EC2 mit Distributor und State Manager, um Ihre Amazon EKS-Knoten an Ihre standardmäßigen Systemprotokollierungs- und Überwachungskonfigurationen anzupassen.

# Protokollierung für Amazon EKS
<a name="kubernetes-eks-logging"></a>

Die Kubernetes-Protokollierung kann in die Protokollierung der Kontrollebene, die Protokollierung von Knoten und die Protokollierung von Anwendungen unterteilt werden. Die [Kubernetes-Steuerebene](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) besteht aus einer Reihe von Komponenten, die Kubernetes-Cluster verwalten und Protokolle erstellen, die für Prüf- und Diagnosezwecke verwendet werden. Mit Amazon EKS können Sie [Protokolle für verschiedene Komponenten der Steuerungsebene aktivieren](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html) und an diese senden CloudWatch. 

Kubernetes führt auch Systemkomponenten wie `kubelet` und `kube-proxy` auf jedem Kubernetes-Knoten aus, auf dem Ihre Pods ausgeführt werden. Diese Komponenten schreiben Protokolle innerhalb jedes Knotens, und Sie können Container Insights so konfigurieren CloudWatch , dass diese Protokolle für jeden Amazon EKS-Knoten erfasst werden. 

Container sind als [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) innerhalb eines Kubernetes-Clusters gruppiert und für die Ausführung auf Ihren Kubernetes-Knoten geplant. Die meisten containerisierten Anwendungen schreiben auf Standardausgabe und Standardfehler, und die Container-Engine leitet die Ausgabe an einen Protokollierungstreiber weiter. In Kubernetes befinden sich die Container-Logs im `/var/log/pods` Verzeichnis auf einem Knoten. Sie können Container Insights so konfigurieren CloudWatch , dass diese Protokolle für jeden Ihrer Amazon EKS-Pods erfasst werden. 

## Amazon-EKS-Steuerebenen-Protokollierung
<a name="eks-control-plane-logging"></a>

Ein Amazon EKS-Cluster besteht aus einer hochverfügbaren Single-Tenant-Steuerebene für Ihren Kubernetes-Cluster und die Amazon EKS-Knoten, auf denen Ihre Container ausgeführt werden. Die Knoten der Kontrollebene werden in einem Konto ausgeführt, das von verwaltet wird. AWS Die Knoten der Amazon EKS-Cluster-Steuerebene sind integriert CloudWatch und Sie können die Protokollierung für bestimmte Komponenten der Steuerungsebene aktivieren.

Für jede Instanz der Kubernetes-Steuerebenenkomponente werden Protokolle bereitgestellt. AWS verwaltet den Zustand Ihrer Knoten auf der Kontrollebene und bietet ein [Service Level Agreement (SLA) für](https://aws.amazon.com//eks/sla/) den Kubernetes-Endpunkt.

## Amazon EKS Knoten- und Anwendungsprotokollierung
<a name="eks-node-application-logging"></a>

Wir empfehlen, [CloudWatchContainer Insights](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html) zur Erfassung von Protokollen und Metriken für Amazon EKS zu verwenden. Container Insights implementiert Metriken auf Cluster-, Knoten- und Pod-Ebene mit dem CloudWatch Agenten und Fluent Bit oder Fluentd für die Protokollerfassung. CloudWatch Container Insights bietet auch automatische Dashboards mit mehrschichtigen Ansichten Ihrer erfassten Metriken. CloudWatch Container Insights wird als CloudWatch DaemonSet Fluent Bit bereitgestellt DaemonSet , das auf jedem Amazon EKS-Knoten ausgeführt wird. Fargate-Knoten werden von Container Insights nicht unterstützt, da die Knoten von verwaltet werden AWS und dies nicht tun. DaemonSets Die Fargate-Protokollierung für Amazon EKS wird in diesem Handbuch separat behandelt. 

 Die folgende Tabelle zeigt die CloudWatch Protokollgruppen und Protokolle, die mit der [standardmäßigen Fluentd- oder Fluent Bit-Protokollerfassungskonfiguration](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) für Amazon EKS erfasst wurden.


|  |  | 
| --- |--- |
| /aws/containerinsights/Cluster\$1Name/application | Alle Protokolldateien in. /var/log/containers Dieses Verzeichnis enthält symbolische Links zu allen Kubernetes-Container-Logs in der /var/log/pods Verzeichnisstruktur. Dadurch werden Ihre Anwendungscontainer-Logs erfasst, die in oder schreiben. stdout stderr Es umfasst auch Protokolle für Kubernetes-Systemcontainer wie aws-vpc-cni-initkube-proxy, und. coreDNS  | 
| /aws/containerinsights/Cluster\$1Name/host | Protokolle von /var/log/dmesg/var/log/secure, und. /var/log/messages | 
| /aws/containerinsights/Cluster\$1Name/dataplane | Die Protokolle in /var/log/journal für kubelet.service, kubeproxy.service und docker.service. | 

Wenn Sie Container Insights nicht mit Fluent Bit oder Fluentd für die Protokollierung verwenden möchten, können Sie Knoten- und Container-Protokolle mit dem auf Amazon EKS-Knoten installierten CloudWatch Agenten erfassen. Amazon EKS-Knoten sind EC2-Instances, was bedeutet, dass Sie sie in Ihren Standardansatz für die Protokollierung auf Systemebene für Amazon EC2 einbeziehen sollten. Wenn Sie den CloudWatch Agenten mithilfe von Distributor und State Manager installieren, sind Amazon EKS-Knoten auch in der Installation, Konfiguration und Aktualisierung des CloudWatch Agenten enthalten. 

Die folgende Tabelle zeigt Protokolle, die spezifisch für Kubernetes sind und die Sie erfassen müssen, wenn Sie Container Insights with Fluent Bit oder Fluentd nicht für die Protokollierung verwenden.


|  |  | 
| --- |--- |
| /var/log/containers | Dieses Verzeichnis enthält symbolische Links zu allen Kubernetes-Container-Logs unter der Verzeichnisstruktur. /var/log/pods Dadurch werden Ihre Anwendungscontainer-Logs effektiv erfasst, die in oder schreiben. stdout stderr Dazu gehören Protokolle für Kubernetes-Systemcontainer wie aws-vpc-cni-initkube-proxy, und. coreDNS Wichtig: Dies ist nicht erforderlich, wenn Sie Container Insights verwenden. | 
| var/log/aws-routed-eni/ipamd.log/var/log/aws-routed-eni/plugin.log | Die Logs für den L-IPAM-Daemon finden Sie hier | 

Sie müssen sicherstellen, dass Amazon EKS-Knoten den CloudWatch Agenten so installieren und konfigurieren, dass er entsprechende Protokolle und Metriken auf Systemebene sendet. Das für Amazon EKS optimierte AMI beinhaltet jedoch nicht den Systems Manager Manager-Agenten. Mithilfe von [Startvorlagen](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) können Sie die Installation des Systems Manager Manager-Agenten und eine CloudWatch Standardkonfiguration automatisieren, die wichtige Amazon EKS-spezifische Protokolle mit einem Startskript erfasst, das über den Benutzerdatenbereich implementiert wird. Amazon EKS-Knoten werden mithilfe einer Auto Scaling Scaling-Gruppe entweder als [verwaltete Knotengruppe](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html) oder als [selbstverwaltete Knoten](https://docs.aws.amazon.com//eks/latest/userguide/worker.html) bereitgestellt.

Bei verwalteten Knotengruppen stellen Sie eine [Startvorlage](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) bereit, die den Abschnitt mit den Benutzerdaten enthält, um die Installation und CloudWatch Konfiguration des Systems Manager Manager-Agenten zu automatisieren. Sie können die Vorlage [amazon\$1eks\$1managed\$1node\$1group\$1launch\$1config.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon_eks_managed_node_group_launch_config.yaml) anpassen und verwenden, um eine CloudFormation Startvorlage zu erstellen, die den Systems Manager Manager-Agenten und -Agenten installiert und dem Konfigurationsverzeichnis auch eine Amazon EKS-spezifische Protokollierungskonfiguration hinzufügt. CloudWatch CloudWatch Diese Vorlage kann verwendet werden, um Ihre Startvorlage für Amazon EKS-verwaltete Knotengruppen mit einem infrastructure-as-code (IaC) -Ansatz zu aktualisieren. Jede Aktualisierung der CloudFormation Vorlage stellt eine neue Version der Startvorlage bereit. Anschließend können Sie die Knotengruppe so aktualisieren, dass sie die neue Vorlagenversion verwendet, und Ihre Knoten im Rahmen des [verwalteten Lebenszyklusprozesses](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-update-behavior.html) ohne Ausfallzeiten aktualisieren lassen. Stellen Sie sicher, dass die auf Ihre verwaltete Knotengruppe angewendete IAM-Rolle `CloudWatchAgentServerPolicy` und das Instanzprofil die `AmazonSSMManagedInstanceCore` AWS verwalteten Richtlinien enthalten. 

Mit selbstverwalteten Knoten können Sie den Lebenszyklus und die Aktualisierungsstrategie für Ihre Amazon EKS-Knoten direkt bereitstellen und verwalten. [Selbstverwaltete Knoten ermöglichen es Ihnen, Windows-Knoten auf Ihrem Amazon EKS-Cluster und [Bottlerocket](https://aws.amazon.com//bottlerocket/) zusammen mit anderen Optionen auszuführen.](https://docs.aws.amazon.com//eks/latest/userguide/eks-compute.html) Sie können CloudFormation damit selbstverwaltete Knoten in Ihren Amazon EKS-Clustern bereitstellen, was bedeutet, dass Sie einen IaC- und Managed-Change-Ansatz für Ihre Amazon EKS-Cluster verwenden können. AWS stellt die CloudFormation Vorlage „[amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml)“ bereit, die Sie unverändert verwenden oder anpassen können. Die Vorlage stellt alle erforderlichen Ressourcen für Amazon EKS-Knoten in einem Cluster bereit (z. B. eine separate IAM-Rolle, Sicherheitsgruppe, Amazon EC2 Auto Scaling Scaling-Gruppe und eine Startvorlage). Bei der CloudFormation Vorlage [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) handelt es sich um eine aktualisierte Version, die den erforderlichen Systems Manager Manager-Agenten und CloudWatch -Agenten installiert und dem Konfigurationsverzeichnis außerdem eine Amazon EKS-spezifische CloudWatch Protokollierungskonfiguration hinzufügt.

## Protokollierung für Amazon EKS auf Fargate
<a name="eks-fargate-logging"></a>

Mit Amazon EKS on Fargate können Sie Pods bereitstellen, ohne Ihre Kubernetes-Knoten zuzuweisen oder zu verwalten. Dadurch entfällt die Notwendigkeit, Protokolle auf Systemebene für Ihre Kubernetes-Knoten zu erfassen. Um die Protokolle von Ihren Fargate-Pods zu erfassen, können Sie Fluent Bit verwenden, um die Protokolle direkt an weiterzuleiten. CloudWatch Auf diese Weise können Sie Protokolle CloudWatch ohne weitere Konfiguration automatisch an einen Sidecar-Container für Ihre Amazon EKS-Pods auf Fargate weiterleiten. Weitere Informationen dazu finden Sie unter [Fargate-Protokollierung](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) in der Amazon EKS-Dokumentation und unter [Fluent Bit for Amazon EKS](https://aws.amazon.com//blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/) im AWS Blog. Diese Lösung erfasst die `STDOUT` und `STDERR` input/output (I/O) -Streams aus Ihrem Container und sendet sie CloudWatch über Fluent Bit an, basierend auf der Fluent Bit-Konfiguration, die für den Amazon EKS-Cluster auf Fargate eingerichtet wurde. 

# Metriken für Amazon EKS und Kubernetes
<a name="kubernetes-eks-metrics"></a>

Kubernetes bietet eine Metrik-API, mit der Sie auf Metriken zur Ressourcennutzung zugreifen können (z. B. die CPU- und Speicherauslastung für Knoten und Pods). Die API stellt jedoch nur point-in-time Informationen und keine historischen Kennzahlen bereit. [Der [Kubernetes-Metrikserver wird in der Regel für Amazon EKS- und Kubernetes-Bereitstellungen verwendet, um Metriken](https://github.com/kubernetes-sigs/metrics-server) zu aggregieren, kurzfristige historische Informationen zu Metriken bereitzustellen und Funktionen wie Horizontal Pod Autoscaler zu unterstützen.](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 

Amazon EKS stellt Metriken der Kontrollebene über den Kubernetes-API-Server [in einem Prometheus-Format](https://docs.aws.amazon.com//eks/latest/userguide/prometheus.html) zur Verfügung und CloudWatch kann diese Metriken erfassen und aufnehmen. CloudWatch und Container Insights können auch so konfiguriert werden, dass sie eine umfassende Erfassung, Analyse und Alarmierung von Kennzahlen für Ihre Amazon EKS-Knoten und -Pods ermöglichen. 

## Metriken der Kubernetes-Steuerebene
<a name="kubernetes-control-plane-metrics"></a>

Kubernetes stellt Metriken der Kontrollebene mithilfe des HTTP-API-Endpunkts in einem Prometheus-Format zur Verfügung. `/metrics` Sie sollten [Prometheus](https://prometheus.io/) in Ihrem Kubernetes-Cluster installieren, um diese Metriken grafisch darzustellen und mit einem Webbrowser anzuzeigen. Sie können auch die vom [Kubernetes-API-Server bereitgestellten Metriken](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) in aufnehmen. CloudWatch

## Knoten- und Systemmetriken für Kubernetes
<a name="kubernetes-node-system-metrics"></a>

Kubernetes stellt den [Prometheus-Metrics-Server-Pod](https://github.com/kubernetes-sigs/metrics-server) bereit, den Sie für CPU- und Speicherstatistiken auf Cluster-, [Knoten- und Pod-Ebene bereitstellen und auf Ihren Kubernetes-Clustern ausführen](https://docs.aws.amazon.com//eks/latest/userguide/metrics-server.html) können. [https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) CloudWatch kann diese Metriken auch bereitstellen. 

Sie sollten den Kubernetes Metrics Server installieren, wenn Sie das [Kubernetes-Dashboard](https://github.com/kubernetes/dashboard) oder die horizontalen und vertikalen Pod-Autoscaler verwenden. Das Kubernetes-Dashboard hilft Ihnen beim Durchsuchen und Konfigurieren Ihres Kubernetes-Clusters, Ihrer Knoten, Pods und der zugehörigen Konfiguration sowie beim Anzeigen der CPU- und Speichermetriken auf dem Kubernetes Metrics Server.

Die vom Kubernetes Metrics Server bereitgestellten Metriken können nicht für Zwecke verwendet werden, die nicht auto skaliert werden (z. B. zur Überwachung). Die Metriken sind für point-in-time Analysen und nicht für historische Analysen gedacht. Das Kubernetes-Dashboard stellt das bereit`dashboard-metrics-scraper`, um Metriken vom Kubernetes Metrics Server für ein kurzes Zeitfenster zu speichern. 

Container Insights verwendet eine containerisierte Version des CloudWatch Agenten, der in einem Kubernetes ausgeführt wird, um alle laufenden Container in einem Cluster DaemonSet zu ermitteln und Metriken auf Knotenebene bereitzustellen. Es sammelt Leistungsdaten auf jeder Ebene des Performance-Stacks. Sie können den Quick Start von AWS Quick Starts verwenden oder Container Insights separat konfigurieren. Der Quick Start richtet die Metriküberwachung mit dem CloudWatch Agenten und die Protokollierung mit Fluent Bit ein, sodass Sie ihn nur einmal für die Protokollierung und Überwachung bereitstellen müssen. 

Da es sich bei Amazon EKS-Knoten um EC2-Instances handelt, sollten Sie zusätzlich zu den von Container Insights erfassten Metriken auch Metriken auf Systemebene erfassen, indem Sie die Standards verwenden, die Sie für Amazon EC2 definiert haben. Sie können denselben Ansatz aus dem [Richten Sie State Manager und Distributor für die Bereitstellung und Konfiguration von CloudWatch Agenten ein](install-cloudwatch-systems-manager.md#set-up-systems-manager-distributor) Abschnitt dieses Handbuchs verwenden, um den CloudWatch Agenten für Ihre Amazon EKS-Cluster zu installieren und zu konfigurieren. Sie können Ihre Amazon EKS-spezifische CloudWatch Konfigurationsdatei so aktualisieren, dass sie sowohl Metriken als auch Ihre Amazon EKS-spezifische Protokollkonfiguration enthält. 

Der CloudWatch Agent mit Prometheus-Unterstützung kann die Prometheus-Metriken von [unterstützten](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus.html), containerisierten Workloads und Systemen automatisch erkennen und auslesen. Er nimmt sie als CloudWatch Logs im eingebetteten metrischen Format zur Analyse mit Logs Insights auf und erstellt automatisch Metriken. CloudWatch CloudWatch

**Wichtig**  
Sie müssen [eine spezielle Version des CloudWatch Agenten bereitstellen](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup.html#ContainerInsights-Prometheus-Setup-install-agent), um Prometheus-Metriken zu sammeln. Dies ist ein anderer Agent als der für Container CloudWatch Insights bereitgestellte Agent. Sie können die Java-Beispielanwendung [prometheus\$1jmx](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/eks/prometheus_jmx) verwenden, die die Bereitstellungs- und Konfigurationsdateien für den CloudWatch Agenten und die Amazon EKS-Pod-Bereitstellung enthält, um die Erkennung von Prometheus-Metriken zu demonstrieren. Weitere Informationen finden Sie in der Dokumentation unter [ Java/JMX Beispiel-Workload auf Amazon EKS und Kubernetes einrichten](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Sample-Workloads-javajmx.html). CloudWatch Sie können den CloudWatch Agenten auch so konfigurieren, dass er Metriken von anderen Prometheus-Zielen erfasst, die in Ihrem Amazon EKS-Cluster ausgeführt werden.

## Anwendungsmetriken
<a name="application-metrics-eks"></a>

Mit dem [CloudWatcheingebetteten Metrikformat können Sie Ihre eigenen benutzerdefinierten Metriken erstellen.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) Um Anweisungen im eingebetteten metrischen Format aufzunehmen, müssen Sie Einträge im eingebetteten metrischen Format an einen Endpunkt im eingebetteten metrischen Format senden. Der CloudWatch Agent kann als [Sidecar-Container in Ihrem Amazon EKS-Pod](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html) konfiguriert werden. Die CloudWatch Agentenkonfiguration wird als Kubernetes gespeichert ConfigMap und von Ihrem CloudWatch Agent-Sidecar-Container gelesen, um den eingebetteten Endpunkt im metrischen Format zu starten.

Sie können Ihre Anwendung auch als Prometheus-Ziel einrichten und den CloudWatch Agenten mit Prometheus-Unterstützung so konfigurieren, dass er Ihre Metriken erkennt, scrapiert und in sie einspeist. CloudWatch Sie können beispielsweise den [Open-Source-JMX-Exporter mit Ihren Java-Anwendungen verwenden, um JMX-Beans](https://github.com/prometheus/jmx_exporter) für den Prometheus-Verbrauch durch den Agenten verfügbar zu machen. CloudWatch 

[https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html) Wir empfehlen diesen Ansatz jedoch nicht, da er Überwachung und Anwendungslogik kombiniert.

## Metriken für Amazon EKS auf Fargate
<a name="metrics-fargate-eks-workloads"></a>

Fargate stellt automatisch Amazon EKS-Knoten für die Ausführung Ihrer Kubernetes-Pods bereit, sodass Sie keine Metriken auf Knotenebene überwachen und sammeln müssen. Sie müssen jedoch die Metriken für Pods überwachen, die auf Ihren Amazon EKS-Knoten auf Fargate ausgeführt werden. Container Insights ist derzeit nicht für Amazon EKS auf Fargate verfügbar, da es die folgenden Funktionen benötigt, die derzeit nicht unterstützt werden:
+ DaemonSets werden derzeit nicht unterstützt. Container Insights wird bereitgestellt, indem der CloudWatch Agent DaemonSet auf jedem Clusterknoten als ausgeführt wird.
+ HostPath persistente Volumes werden nicht unterstützt. Der CloudWatch Agent-Container verwendet persistente HostPath-Volumes als Voraussetzung für die Erfassung von Container-Metrikdaten. 
+ Fargate verhindert privilegierte Container und den Zugriff auf Host-Informationen.

Sie können den [integrierten Log-Router für Fargate](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) verwenden, um eingebettete Anweisungen im metrischen Format an zu CloudWatch senden. Der Log-Router verwendet Fluent Bit, das über ein CloudWatch Plugin verfügt, das so konfiguriert werden kann, dass es eingebettete Anweisungen im metrischen Format unterstützt.

Sie können Metriken auf Pod-Ebene für Ihre Fargate-Knoten abrufen und erfassen, indem Sie den Prometheus-Server in Ihrem Amazon EKS-Cluster einsetzen, um Metriken von Ihren Fargate-Knoten zu sammeln. Da Prometheus persistenten Speicher benötigt, können Sie Prometheus auf Fargate bereitstellen, wenn Sie Amazon Elastic File System (Amazon EFS) für persistenten Speicher verwenden. Sie können Prometheus auch auf einem von Amazon EC2 unterstützten Knoten bereitstellen. Weitere Informationen finden Sie im Blog unter [Überwachung AWS Fargate von Amazon EKS zur Verwendung von Prometheus und Grafana](https://aws.amazon.com//blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/). AWS 