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.
Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm
Sie können entweder das Amazon CloudWatch Observability EKS-Add-on oder das Amazon CloudWatch Observability Helm-Diagramm verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Amazon EKS-Cluster zu installieren. Sie können das Helm-Diagramm auch verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Kubernetes-Cluster zu installieren, der nicht auf Amazon EKS gehostet wird.
Die Verwendung einer der beiden Methoden auf einem Amazon EKS-Cluster ermöglicht standardmäßig sowohl Container Insights mit verbesserter Observability für Amazon EKS als auch CloudWatch Application Signals. Beide Funktionen helfen Ihnen bei der Erfassung von Infrastrukturmetriken, Telemetrie zur Anwendungsleistung und Container-Protokollen aus dem Cluster.
Bei Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS werden die Container-Insights-Metriken pro Beobachtung abgerechnet, anstatt pro gespeicherter Metrik oder aufgenommenem Protokoll. Bei Application Signals basiert die Abrechnung auf eingehenden Anfragen an Ihre Anwendungen, ausgehenden Anfragen von Ihren Anwendungen und jedem konfigurierten Servicelevel-Ziel (SLO). Jede eingehende Anfrage generiert ein Anwendungssignal, und jede ausgehende Anfrage generiert ein Anwendungssignal. Jeder SLO erzeugt zwei Anwendungssignale pro Messzeitraum. Weitere Informationen zur CloudWatch Preisgestaltung finden Sie unter CloudWatch Amazon-Preise
Beide Methoden ermöglichen Container Insights sowohl auf Linux- als auch auf Windows-Worker-Knoten im Amazon EKS-Cluster. Um Container Insights unter Windows zu aktivieren, müssen Sie Version 1.5.0 oder höher des Amazon EKS-Add-ons oder das Helm-Diagramm verwenden. Derzeit wird Application Signals unter Windows in Amazon EKS-Clustern nicht unterstützt.
Das Amazon CloudWatch Observability EKS-Add-on wird auf Amazon EKS-Clustern unterstützt, die mit Kubernetes Version 1.23 oder höher ausgeführt werden.
Wenn Sie das Add-on oder das Helm-Diagramm installieren, müssen Sie auch IAM-Berechtigungen erteilen, damit der CloudWatch Agent Metriken, Protokolle und Traces an senden kann. CloudWatch Es gibt zwei Möglichkeiten dafür:
Fügen Sie eine Richtlinie an die IAM-Rolle Ihrer Worker-Knoten an. Diese Option gewährt Worker-Knoten die Erlaubnis, Telemetrie an sie zu senden. CloudWatch
Verwenden Sie eine IAM-Rolle für Servicekonten für die Agenten-Pods und fügen Sie die Richtlinie an diese Rolle an. Dies funktioniert nur für Amazon-EKS-Cluster. Diese Option gewährt nur CloudWatch Zugriff auf die entsprechenden Agenten-Pods.
Themen
Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten
Option 3: Installation mithilfe der IAM-Servicekontorolle (gilt nur für die Verwendung des Add-ons)
Konfiguration von Anwendungssignalen für Ihren Amazon EKS-Cluster
Fehlerbehebung für das Amazon CloudWatch Observability EKS-Add-on oder das Helm-Diagramm
Option 1: Installation mit EKS Pod Identity
Wenn Sie Version 3.1.0 oder höher des Add-ons verwenden, können Sie EKS Pod Identity verwenden, um dem Add-on die erforderlichen Berechtigungen zu erteilen. EKS Pod Identity ist die empfohlene Option und bietet Vorteile wie geringste Rechte, Rotation von Anmeldeinformationen und Überprüfbarkeit. Darüber hinaus können Sie mit EKS Pod Identity das EKS-Add-On als Teil der Clustererstellung selbst installieren.
Um diese Methode zu verwenden, folgen Sie zunächst den Schritten zur EKS Pod Identity-Zuordnung, um die IAM-Rolle zu erstellen und den EKS Pod Identity-Agenten einzurichten.
Installieren Sie anschließend das Amazon CloudWatch Observability EKS-Add-on. Um das Add-on zu installieren, können Sie die AWS CLI Amazon EKS-Konsole oder Terraform verwenden. AWS CloudFormation
Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten
Um diese Methode zu verwenden, fügen Sie zunächst die CloudWatchAgentServerPolicyIAM-Richtlinie Ihren Worker-Knoten hinzu, indem Sie den folgenden Befehl eingeben. Ersetzen Sie my-worker-node-role
diesen Befehl durch die IAM-Rolle, die von Ihren Kubernetes-Worker-Knoten verwendet wird.
aws iam attach-role-policy \ --role-name
my-worker-node-role
\ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
Installieren Sie anschließend das Amazon CloudWatch Observability EKS-Add-on. Um das Add-on zu installieren, können Sie die AWS CLI, die Konsole oder AWS CloudFormation Terraform verwenden.
Option 3: Installation mithilfe der IAM-Servicekontorolle (gilt nur für die Verwendung des Add-ons)
Diese Methode ist nur gültig, wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden. Vor dem Verwenden dieser Methode, überprüfen Sie die folgenden Voraussetzungen:
-
Sie besitzen einen funktionsfähigen Amazon-EKS-Cluster mit angefügten Knoten in einer der AWS-Regionen , von denen Container Insights unterstützt wird. Eine Liste der unterstützten Regionen finden Sie unter Container Insights.
-
Sie haben
kubectl
für den Cluster installiert und konfiguriert. Weitere Informationen finden Sie unter Installieren vonkubectl
im Amazon-EKS-Benutzerhandbuch. -
Sie haben
eksctl
installiert. Weitere Informationen finden Sie unter Installieren oder Aktualisieren voneksctl
im Amazon-EKS-Benutzerhandbuch.
Überlegungen zu Amazon EKS-Hybridknoten
Metriken auf Knotenebene sind für Hybridknoten nicht verfügbar, da dies von der Verfügbarkeit des EC2 Instance Metadata Service (IMDS) für Metriken auf Knotenebene Container Insights abhängt. Metriken auf Cluster-Pod, Workload- und Container-Ebene sind für Hybridknoten verfügbar.
Nachdem Sie das Add-on gemäß den Schritten in den vorherigen Abschnitten installiert haben, müssen Sie das Add-On-Manifest aktualisieren, damit der Agent erfolgreich auf Hybridknoten ausgeführt werden kann. Bearbeiten Sie die amazoncloudwatchagents
Ressource im Cluster, um die RUN_WITH_IRSA
Umgebungsvariable hinzuzufügen, die den folgenden Werten entspricht.
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ...
(Optional) Zusätzliche Konfiguration
Themen
Deaktivieren Sie das Sammeln von Container-Logs
Standardmäßig verwendet das Add-on Fluent Bit, um Container-Logs von allen Pods zu sammeln und sendet die Logs dann an CloudWatch Logs. Informationen darüber, welche Protokolle gesammelt werden, finden Sie unter Einrichten von Fluent Bit.
Anmerkung
Weder das Add-On noch das Helm-Diagramm verwalten vorhandene Fluentd- oder Fluent Bit-Ressourcen in einem Cluster. Sie können die vorhandenen Fluentd- oder Fluent-Bit-Ressourcen löschen, bevor Sie das Add-on oder das Helm-Diagramm installieren. Um Ihr bestehendes Setup beizubehalten und zu verhindern, dass das Add-on oder das Helm-Diagramm Fluent Bit ebenfalls installieren, können Sie Fluent Bit alternativ deaktivieren, indem Sie den Anweisungen in diesem Abschnitt folgen.
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden, übergeben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option:
--configuration-values '{ "containerLogs": { "enabled": false } }'
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Helm-Diagramm verwenden, geben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option an:
--set containerLogs.enabled=false
Verwenden Sie eine benutzerdefinierte Fluent Bit-Konfiguration
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons können Sie die Fluent Bit-Konfiguration ändern, wenn Sie das Add-on oder das Helm-Diagramm erstellen oder aktualisieren. Sie geben die benutzerdefinierte Fluent Bit-Konfiguration im Abschnitt auf containerLogs
Stammebene der erweiterten Konfiguration des Add-ons an oder die Wertüberschreibungen im Helm-Diagramm. In diesem Abschnitt geben Sie die benutzerdefinierte Fluent-Bit-Konfiguration im config
Abschnitt (für Linux) oder configWindows
Abschnitt (für Windows) an. Der config
ist weiter in die folgenden Unterabschnitte unterteilt:
service
— Dieser Abschnitt stellt dieSERVICE
Konfiguration zur Definition des globalen Verhaltens der Fluent Bit-Engine dar.customParsers
— Dieser Abschnitt stellt alle globalenPARSER
s dar, die Sie einbeziehen möchten und die in der Lage sind, unstrukturierte Protokolleinträge zu verarbeiten und ihnen eine Struktur zu geben, um sie einfacher zu verarbeiten und weiter zu filtern.extraFiles
— Dieser Abschnitt kann verwendet werden, um zusätzlicheconf
Fluent-Bit-Dateien hinzuzufügen. Standardmäßig sind die folgenden 3conf
Dateien enthalten:.application-log.conf
— Eineconf
Datei zum Senden von Anwendungsprotokollen von Ihrem Cluster an die Protokollgruppe/aws/containerinsights/
in CloudWatch Logs.my-cluster-name
/applicationdataplane-log.conf
— Eineconf
Datei zum Senden von Protokollen, die den Datenebenenkomponenten Ihres Clusters entsprechen, einschließlich der CRI-Logs, Kubelet-Logs, Kube-Proxy-Logs und Amazon VPC-CNI-Logs, an die Protokollgruppe unter Logs./aws/containerinsights/
CloudWatchmy-cluster-name
/dataplanehost-log.conf
— Aconf
zum Senden von Protokollen von/var/log/dmesg
/var/log/messages
, und unter Linux und System unter Windows/var/log/secure
winlogs
an die Protokollgruppe in./aws/containerinsights/
CloudWatchmy-cluster-name
/host
Anmerkung
Geben Sie die vollständige Konfiguration für jeden dieser einzelnen Abschnitte an, auch wenn Sie nur ein Feld innerhalb eines Unterabschnitts ändern. Wir empfehlen, die unten angegebene Standardkonfiguration als Grundlage zu verwenden und sie dann entsprechend zu ändern, damit Sie die standardmäßig aktivierten Funktionen nicht deaktivieren. Sie können die folgende YAML-Konfiguration verwenden, wenn Sie die erweiterte Konfiguration für das Amazon EKS-Add-on ändern oder wenn Sie Wertüberschreibungen für das Helm-Diagramm angeben.
Den config
Abschnitt für Ihren Cluster finden Sie unter aws-observability /helm-charts/charts/amazon-cloudwatch-observability/values.yaml
zu dem config
Abschnitt (für Linux) und dem configWindows
Abschnitt (für Windows) im Abschnitt unten. fluentBit
containerLogs
Als Beispiel finden Sie hier die Standard-Fluent Bit-Konfiguration für Version 1.7.0.
Wir empfehlen, dass Sie das config
als YAML angeben, wenn Sie es mit der erweiterten Konfiguration des Amazon EKS-Add-ons bereitstellen oder wenn Sie es als Wertüberschreibungen für Ihre Helm-Installation angeben. Stellen Sie sicher, dass YAML der folgenden Struktur entspricht.
containerLogs: fluentBit: config: service: | ... customParsers: | ... extraFiles: application-log.conf: | ... dataplane-log.conf: | ... host-log.conf: | ...
Im folgenden Beispiel wird die globale Einstellung für das Spülintervall auf 45 Sekunden config
geändert. Auch wenn die einzige Änderung das Flush
Feld betrifft, müssen Sie dennoch die vollständige SERVICE
Definition für den Service-Unterabschnitt angeben. Da in diesem Beispiel keine Überschreibungen für die anderen Unterabschnitte angegeben wurden, werden für sie die Standardwerte verwendet.
containerLogs: fluentBit: config: service: | [SERVICE] Flush 45 Grace 30 Log_Level error Daemon off Parsers_File parsers.conf storage.path /var/fluent-bit/state/flb-storage/ storage.sync normal storage.checksum off storage.backlog.mem_limit 5M
Die folgende Beispielkonfiguration beinhaltet eine zusätzliche Fluent-Bit-Datei. conf
In diesem Beispiel fügen wir ein benutzerdefiniertes my-service.conf
unter hinzu extraFiles
und es wird zusätzlich zu den drei extraFiles
Standardwerten hinzugefügt.
containerLogs: fluentBit: config: extraFiles: my-service.conf: | [INPUT] Name tail Tag myservice.* Path /var/log/containers/*myservice*.log DB /var/fluent-bit/state/flb_myservice.db Mem_Buf_Limit 5MB Skip_Long_Lines On Ignore_Older 1d Refresh_Interval 10 [OUTPUT] Name cloudwatch_logs Match myservice.* region ${AWS_REGION} log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice log_stream_prefix ${HOST_NAME}- auto_create_group true
Im nächsten Beispiel wird eine bestehende conf
Datei vollständig von entferntextraFiles
. Dadurch wird die application-log.conf
vollständig ausgeschlossen, indem sie mit einer leeren Zeichenfolge überschrieben wird. Das einfache Weglassen application-log.conf
von extraFiles
würde stattdessen bedeuten, die Standardeinstellung zu verwenden, was wir in diesem Beispiel nicht erreichen wollen. Das Gleiche gilt für das Entfernen von benutzerdefinierten conf
Dateien, zu denen Sie möglicherweise zuvor etwas hinzugefügt haben. extraFiles
containerLogs: fluentBit: config: extraFiles: application-log.conf: ""
Verwalten Sie die Kubernetes-Toleranzen für die installierten Pod-Workloads
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons legen das Add-on und das Helm-Diagramm standardmäßig Kubernetes-Toleranzen fest, um alle Fehler in den Pod-Workloads zu tolerieren, die durch das Add-on oder das Helm-Diagramm installiert werden. Dadurch wird sichergestellt, dass Daemonsets wie der CloudWatch Agent und Fluent Bit standardmäßig Pods auf allen Knoten in Ihrem Cluster planen können. Weitere Informationen zu Toleranzen und Taints finden Sie unter Taints and Tolerations in der Kubernetes-Dokumentation
Die vom Add-on oder dem Helm-Diagramm festgelegten Standardtoleranzen lauten wie folgt:
tolerations: - operator: Exists
Sie können die Standardtoleranzen überschreiben, indem Sie das tolerations
Feld auf der Stammebene festlegen, wenn Sie die erweiterte Konfiguration des Add-ons verwenden oder wenn Sie das Helm-Diagramm mit Wertüberschreibungen installieren oder aktualisieren. Ein Beispiel würde wie folgt aussehen:
tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"
Um Toleranzen komplett wegzulassen, können Sie eine Konfiguration verwenden, die wie folgt aussieht:
tolerations: []
Alle Änderungen an den Toleranzen gelten für alle Pod-Workloads, die durch das Add-on oder das Helm-Diagramm installiert werden.
Deaktivieren Sie die beschleunigte Erfassung von Rechenmetriken
Standardmäßig erfasst Container Insights mit verbesserter Observability Metriken für die Accelerated Compute-Überwachung, darunter NVIDIA-GPU-Metriken, AWS Neuron-Metriken für AWS Trainium und AWS Inferentia sowie AWS Elastic Fabric Adapter (EFA) -Metriken.
NVIDIA-GPU-Metriken von Amazon EKS-Workloads werden standardmäßig erfasst, beginnend mit v1.3.0-eksbuild.1
der Version des EKS-Add-ons oder des Helm-Diagramms und 1.300034.0
der Version des CloudWatch Agenten. Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unterNVIDIA GPU-Metriken.
AWS Neuronenmetriken für AWS Trainium- und AWS Inferentia-Beschleuniger werden standardmäßig ab v1.5.0-eksbuild.1
der Version des EKS-Add-ons oder des Helm-Diagramms und der Version des Agenten erfasst. 1.300036.0
CloudWatch Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unter. AWS Neuronenmetriken für AWS Trainium und Inferentia AWS
AWS Elastic Fabric Adapter (EFA) -Metriken von Linux-Knoten auf Amazon EKS-Clustern werden standardmäßig erfasst, beginnend mit v1.5.2-eksbuild.1
der Version des EKS-Add-ons oder des Helm-Diagramms und 1.300037.0
der Version des CloudWatch Agenten. Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unterAWS Metriken für Elastic Fabric Adapter (EFA) .
Sie können die Erfassung dieser Metriken deaktivieren, indem Sie das accelerated_compute_metrics
Feld in der CloudWatch Agentenkonfigurationsdatei auf setzenfalse
. Dieses Feld befindet sich im kubernetes
Abschnitt des metrics_collected
Abschnitts in der CloudWatch Konfigurationsdatei. Im Folgenden finden Sie ein Beispiel für eine Opt-Out-Konfiguration. Weitere Informationen zur Verwendung benutzerdefinierter CloudWatch Agentenkonfigurationen finden Sie im folgenden Abschnitt,Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "accelerated_compute_metrics": false } } } }
Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration
Um andere Metriken, Logs oder Traces mithilfe des CloudWatch Agenten zu erfassen, können Sie eine benutzerdefinierte Konfiguration angeben und gleichzeitig Container Insights und CloudWatch Application Signals aktiviert lassen. Betten Sie dazu die CloudWatch Agentenkonfigurationsdatei in den Konfigurationsschlüssel unter dem Agentenschlüssel der erweiterten Konfiguration ein, den Sie bei der Erstellung oder Aktualisierung des EKS-Add-ons oder des Helm-Diagramms verwenden können. Im Folgenden wird die standardmäßige Agentenkonfiguration dargestellt, wenn Sie keine zusätzliche Konfiguration angeben.
Wichtig
Jede benutzerdefinierte Konfiguration, die Sie mithilfe zusätzlicher Konfigurationseinstellungen angeben, hat Vorrang vor der vom Agenten verwendeten Standardkonfiguration. Achten Sie darauf, standardmäßig aktivierte Funktionen wie Container Insights mit verbesserter Beobachtbarkeit und CloudWatch Application Signals nicht ungewollt zu deaktivieren. In dem Szenario, bei dem Sie eine benutzerdefinierte Agentenkonfiguration bereitstellen müssen, empfehlen wir, die folgende Standardkonfiguration als Basiskonfiguration zu verwenden und sie dann entsprechend zu ändern.
Für die Verwendung des Amazon CloudWatch Observability EKS-Add-ons
--configuration-values '{ "agent": { "config": { "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } } }'
-
Für die Verwendung des Helm-Diagramms
--set agent.config='{ "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } }'
Das folgende Beispiel zeigt die Standard-Agentenkonfiguration für den CloudWatch Agenten unter Windows. Der CloudWatch Agent unter Windows unterstützt keine benutzerdefinierte Konfiguration.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true }, } } }
Webhook-TLS-Zulassungszertifikate verwalten
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm nutzen Kubernetes-ZulassungswebhooksInstrumentation
benutzerdefinierte Ressourcenanfragen (CR) AmazonCloudWatchAgent
und optional Kubernetes-Pod-Anfragen auf dem Cluster, wenn Application Signals aktiviert ist. CloudWatch In Kubernetes benötigen Webhooks ein TLS-Zertifikat, dem der API-Server vertraut, um die sichere Kommunikation zu gewährleisten.
Standardmäßig generieren das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm automatisch eine selbstsignierte CA und ein von dieser CA signiertes TLS-Zertifikat, um die Kommunikation zwischen dem API-Server und dem Webhook-Server zu sichern. Dieses automatisch generierte Zertifikat hat eine Standardablaufzeit von 10 Jahren und wird nach Ablauf nicht automatisch verlängert. Darüber hinaus werden das CA-Paket und das Zertifikat jedes Mal neu generiert, wenn das Add-on oder das Helm-Diagramm aktualisiert oder neu installiert wird, wodurch der Ablauf zurückgesetzt wird. Wenn Sie den Standardablauf des automatisch generierten Zertifikats ändern möchten, können Sie beim Erstellen oder Aktualisieren des Add-Ons die folgenden zusätzlichen Konfigurationen verwenden. Ersetzen Sie es expiry-in-days
durch die gewünschte Ablaufdauer in Tagen.
Verwenden Sie dies für das Amazon CloudWatch Observability EKS-Add-on
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays":
expiry-in-days
} } }'Verwenden Sie dies für das Helm-Diagramm
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
Für eine sicherere und featurereichere Zertifizierungsstellen-Lösung bietet das Add-On optionale Unterstützung für cert-manager
Wir empfehlen Ihnen, sich mit den bewährten Methoden für die Verwaltung von TLS-Zertifikaten auf Ihren Clustern vertraut zu machen und sich für Produktionsumgebungen für cert-manager zu entscheiden. Beachten Sie, dass Sie, wenn Sie sich dafür entscheiden, den Cert-Manager für die Verwaltung der Zulassungs-Webhook-TLS-Zertifikate zu aktivieren, cert-manager auf Ihrem Amazon EKS-Cluster vorinstallieren müssen, bevor Sie das Amazon CloudWatch Observability EKS-Add-on oder das Helm-Diagramm installieren. Weitere Informationen zu den verfügbaren Installationsoptionen finden Sie in der cert-manager-Dokumentation.
Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Wenn Sie das Helm-Diagramm verwenden
--set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Die in diesem Abschnitt beschriebene erweiterte Konfiguration verwendet standardmäßig einen SelfSigned
Amazon EBS-Volume sammeln IDs
Wenn Sie das Amazon EBS-Volume IDs in den Leistungsprotokollen erfassen möchten, müssen Sie der IAM-Rolle, die den Worker-Knoten oder dem Dienstkonto zugeordnet ist, eine weitere Richtlinie hinzufügen. Fügen Sie Folgendes als eingebundenen Richtlinie hinzu. Weitere Informationen finden Sie unter Hinzufügen und Entfernen von IAM-Identitätsberechtigungen.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeVolumes" ], "Resource": "*", "Effect": "Allow" } ] }
Erfassen Sie Metriken zu Java Management Extensions (JMX)
Der CloudWatch Agent unterstützt die Erfassung von Java Management Extensions (JMX) -Metriken auf Amazon EKS. Auf diese Weise können Sie zusätzliche Metriken von Java-Anwendungen sammeln, die auf Amazon EKS-Clustern ausgeführt werden, sodass Sie Einblicke in Leistung, Speicherverbrauch, Datenverkehr und andere wichtige Metriken erhalten. Weitere Informationen finden Sie unter Erfassen Sie Metriken zu Java Management Extensions (JMX).
Aktivieren Sie Warteschlangen-Metriken
Ab v2.4.0-eksbuild.1
der Version des CloudWatch Observability EKS-Add-ons unterstützt Container Insights for Amazon EKS die Erfassung von Kueue-Metriken aus Amazon EKS-Clustern. Weitere Informationen zu diesen Metriken finden Sie unter Metriken für die Warteschlange .
Wenn Sie das Amazon SageMaker AI Hyperpod Task Governance EKS-Add-on verwenden, können Sie die Schritte im Abschnitt Voraussetzungen überspringen und einfach den Schritten unter folgen. Aktivieren Sie das Konfigurations-Flag
Voraussetzungen
Bevor Sie Kueue in Ihrem Amazon EKS-Cluster installieren, nehmen Sie die folgenden Aktualisierungen in der Manifestdatei vor:
Aktivieren Sie die optionalen Cluster-Warteschlangenressourcen-Metriken für Kueue. Ändern Sie dazu die Inline
controller_manager_config.yaml
in der.kueue-system
ConfigMap Fügen Sie in demmetrics
Abschnitt die Zeile hinzu oder entfernen Sie den Kommentar.enableClusterQueueResources: true
apiVersion: v1 data: controller_manager_config.yaml: | apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8080 enableClusterQueueResources: true
<-- ADD/UNCOMMENT THIS LINE
Standardmäßig sind alle
k8s
Dienste clusterweit verfügbar. Kueue erstellt einen Dienstkueue-controller-manager-metrics-service
zum Bereitstellen von Metriken. Um doppelte Beobachtungen für Metriken zu vermeiden, ändern Sie diesen Service so, dass nur der Zugriff auf den Metrik-Service von demselben Knoten aus möglich ist. Fügen Sie dazu die ZeileinternalTrafficPolicy: Local
zurkueue-controller-manager-metrics-service
Definition hinzu.apiVersion: v1 kind: Service metadata: labels: ... name: kueue-controller-manager-metrics-service namespace: kueue-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: https internalTrafficPolicy: Local
<-- ADD THIS LINE
selector: control-plane: controller-managerSchließlich erstellt der
kueue-controller-manager
Pod einenkube-rbac-proxy
Container. Dieser Container weist derzeit einen hohen Grad an Logging-Ausführlichkeit auf, was dazu führt, dass das Bearer-Token des Clusters von diesem Container protokolliert wird, wenn der Metrik-Scraper auf den zugreift.kueue-controller-manager-metrics-service
Wir empfehlen, diese Ausführlichkeit der Protokollierung zu verringern. Der Standardwert in dem von Kueue verteilten Manifest ist 10. Wir empfehlen, ihn auf 0 zu ändern.apiVersion: apps/v1 kind: Deployment metadata: labels: ... name: kueue-controller-manager namespace: kueue-system spec: ... template: ... spec: containers: ... - args: - --secure-listen-address=0.0.0.0:8443 - --upstream=http://127.0.0.1:8080/ - --logtostderr=true - --v=0
<-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: kube-rbac-proxy ...
Aktivieren Sie das Konfigurations-Flag
Um die Kueue-Metriken zu aktivieren, müssen Sie kueue_container_insights
im Add-on eine zusätzliche Konfiguration aktivieren. Sie können dies entweder mit dem AWS CLI zur Einrichtung des EKS Observability Add-ons oder mit der Amazon EKS-Konsole tun.
Nachdem Sie das EKS Observability-Add-on mit einer der folgenden Methoden erfolgreich installiert haben, können Sie Ihre Amazon EKS-Cluster-Metriken auf der Registerkarte Dashboard der HyperPod Konsole einsehen.
OpenTelemetry Collector-Konfigurationsdateien anhängen
Der CloudWatch Agent unterstützt neben seinen eigenen Konfigurationsdateien zusätzliche OpenTelemetry Collector-Konfigurationsdateien. Mit dieser Funktion können Sie CloudWatch Agentenfunktionen wie CloudWatch Application Signals oder Container Insights über die CloudWatch Agentenkonfiguration nutzen und Ihre bestehende OpenTelemetry Collector-Konfiguration mit einem einzigen Agenten integrieren.
Um Zusammenführungskonflikte mit automatisch vom CloudWatch Agenten erstellten Pipelines zu vermeiden, empfehlen wir, dass Sie jeder Komponente und Pipelines in Ihrer OpenTelemetry Collector-Konfiguration ein benutzerdefiniertes Suffix hinzufügen. Dadurch werden Konflikte und Zusammenführungskonflikte vermieden.
Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
--configuration-values file://values.yaml
or
--configuration-values ' agent: otelConfig: receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Wenn Sie das Helm-Diagramm verwenden
--set agent.otelConfig=' receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Konfiguration von Anwendungssignalen für Ihren Amazon EKS-Cluster
Application Signals ist standardmäßig aktiviert, wenn entweder das CloudWatch Observability EKS-Add-on oder das Helm-Diagramm installiert wird. Sie können spezifische Einstellungen mithilfe der erweiterten Konfiguration für das Amazon EKS-Add-on weiter anpassen oder indem Sie Werte mit dem Helm-Diagramm überschreiben.
Automatische Überwachung von Anwendungssignalen
Version 4.0.0 des Amazon EKS-Add-ons CloudWatch Observability und des Helm-Diagramms bietet neue Funktionen. Sie können Application Signals jetzt automatisch für alle oder bestimmte Service-Workloads in Ihrem EKS-Cluster über die automatische Monitor-Konfiguration aktivieren. Die folgenden autoMonitor
Einstellungen können im applicationSignals
Abschnitt unter dem manager
Abschnitt der erweiterten Konfiguration angegeben werden.
monitorAllServices— Ein boolesches Flag, um die Überwachung aller Service-Workloads durch Auto Monitor zu aktivieren (true) oder zu deaktivieren (false). Standardwert "false". Durch die Aktivierung dieses Flags wird sichergestellt, dass alle Kubernetes-Workloads (Deployments DaemonSets, und StatefulSets) im Cluster, die einem Kubernetes-Dienst zugeordnet sind, für die automatische Aktivierung von Application Signals gelten, wenn sie zum ersten Mal gestartet werden (oder wenn sie für bestehende Workloads neu gestartet werden). Das System schließt standardmäßig Workloads in den Namespaces und aus.
kube-system
amazon-cloudwatch
Sprachen — Eine Liste von Zeichenketten, die angeben, mit welchen Sprachen Application Signals versuchen wird, Ihre Dienste automatisch zu instrumentieren, wenn sie aktiviert ist.
monitorAllServices
Standardmäßig werden alle unterstützten Sprachen verwendet.RestartPods — Ein boolesches Flag steuert, ob Workloads nach Konfigurationsänderungen neu gestartet werden. Standardwert "false". Durch die Aktivierung dieses Flags wird
true
gesteuert, ob Kubernetes-Workloads im Bereich Auto Monitor beim Speichern von Konfigurationsänderungen automatisch neu gestartet werden. Alle Einstellungen in Ihren Kubernetes-Workloads, die sich beispielsweise auf den Neustart der Pods auswirken, werden berücksichtigt.updateStrategy
Bedenken Sie, dass ein Neustart zu Dienstausfällen führen kann.CustomSelector — Einstellungen zur Auswahl bestimmter Kubernetes-Namespaces oder Workloads für die automatische Überwachung.
java — Geben Sie Workloads an, die automatisch mit Java instrumentiert werden sollen
python — Spezifiziert Workloads für die automatische Instrumentierung mit Python
nodejs — Geben Sie Workloads an, die automatisch mit Node.js instrumentiert werden sollen
dotnet — Geben Sie Workloads an, die automatisch mit .NET instrumentiert werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
Namespaces — Eine Liste von Zeichenketten, die die auszuwählenden Namespaces angeben. Standardmäßig ist eine leere Liste, das ist []
Bereitstellungen — Eine Liste von Zeichenketten, die die auszuwählenden Bereitstellungen angeben. Geben Sie das Format an
namespace/deployment
. Standardmäßig ist eine leere Liste, das ist []daemonsets — Eine Liste von Zeichenketten, die die auszuwählenden Daemonsets angeben. Geben Sie das Format an.
namespace/daemonset
Standardmäßig ist eine leere Liste, das ist []statefulsets — Eine Liste von Zeichenketten, die die auszuwählenden Statefulsets angeben. Geben
namespace/statefulset
Sie das Format an. Standardmäßig ist eine leere Liste, das ist []
exclude — Einstellungen zum Ausschluss bestimmter Kubernetes-Namespaces oder Workloads von der automatischen Überwachung. Das Ausschließen eines Workloads hat Vorrang, wenn derselbe Workload auch im Geltungsbereich von oder liegt.
monitorAllServices
customSelector
java — Geben Sie Workloads an, die von der automatischen Instrumentierung mit Java ausgeschlossen werden sollen
python — Spezifiziert Workloads, die von der automatischen Instrumentierung mit Python ausgeschlossen werden sollen
nodejs — Geben Sie Workloads an, die von der automatischen Instrumentierung mit Node.js ausgeschlossen werden sollen
dotnet — Geben Sie Workloads an, die von der automatischen Instrumentierung mit.NET ausgeschlossen werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
Namespaces — Eine Liste von Zeichenketten, die die auszuschließenden Namespaces angeben. Standardmäßig ist eine leere Liste, das ist []
Bereitstellungen — Eine Liste von Zeichenketten, die die auszuschließenden Bereitstellungen angeben. Geben Sie das Format an
namespace/deployment
. Standardmäßig ist eine leere Liste, das ist []daemonsets — Eine Liste von Zeichenketten, die angeben, welche Daemonsets ausgeschlossen werden sollen. Geben Sie das Format an.
namespace/daemonset
Standardmäßig ist eine leere Liste, das ist []statefulsets — Eine Liste von Zeichenketten, die die auszuschließenden Statefulsets angeben. Geben
namespace/statefulset
Sie das Format an. Standardmäßig ist eine leere Liste, das ist []
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für alle vorhandenen und neuen Service-Workloads auf dem Cluster aktiviert.
manager: applicationSignals: autoMonitor: monitorAllServices: true restartPods: true
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für jeden neuen Service-Workload aktiviert, der gestartet wird, und für jeden vorhandenen Service-Workload, der explizit auf dem Cluster neu gestartet wird.
manager: applicationSignals: autoMonitor: monitorAllServices: true
Die folgende Beispielkonfiguration aktiviert automatisch Application Signals mit Java für alle vorhandenen und neuen Pods, die einem Workload im pet-warehouse
Namespace entsprechen.
manager: applicationSignals: autoMonitor: restartPods: true customSelector: java: namespaces: ["pet-warehouse"]
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals with Python automatisch für alle vorhandenen und neuen Service-Workloads im Cluster mit Ausnahme der pet-clinic
Bereitstellung aktiviert.
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["python"] restartPods: true exclude: python: deployments: ["pet-warehouse/pet-clinic"]
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals with Java automatisch für alle Service-Workloads im Cluster mit Ausnahme der Workloads im python-apps
Namespace aktiviert und außerdem Application Signals with Python speziell für die sample-python-app
Bereitstellung im Namespace aktiviert. python-apps
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["java"] restartPods: true customSelector: python: deployments: ["python-apps/sample-python-app"] exclude: java: namespaces: ["python-apps"]
Fehlerbehebung für das Amazon CloudWatch Observability EKS-Add-on oder das Helm-Diagramm
Verwenden Sie die folgenden Informationen, um Probleme mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm zu beheben
Themen
Aktualisieren und Löschen des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Diagramms
Anweisungen zum Aktualisieren oder Löschen des Amazon CloudWatch Observability EKS-Add-ons finden Sie unter Amazon EKS-Add-Ons verwalten. Verwenden Sie als amazon-cloudwatch-observability
Name des Add-Ons.
Geben Sie den folgenden Befehl ein, um das Helm-Diagramm in einem Cluster zu löschen.
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
Überprüfen Sie die Version des CloudWatch Agenten, die vom Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm verwendet wird
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm installieren eine benutzerdefinierte Art von RessourceAmazonCloudWatchAgent
, die das Verhalten des CloudWatch Agenten-Daemonsets auf dem Cluster steuert, einschließlich der Version des verwendeten CloudWatch Agenten. Sie können eine Liste aller auf Ihrem Cluster installierten, benutzerdefinierten AmazonCloudWatchAgent
-Ressourcen abrufen, indem Sie den folgenden Befehl eingeben:
kubectl get amazoncloudwatchagent -A
In der Ausgabe dieses Befehls sollten Sie die Version des Agenten überprüfen können. CloudWatch Alternativ können Sie auch die amazoncloudwatchagent
-Ressource oder einen der cloudwatch-agent-*
-Pods beschreiben, die auf Ihrem Cluster ausgeführt werden, um das verwendete Image zu überprüfen.
Umgang mit a ConfigurationConflict bei der Verwaltung des Add-ons oder des Helm-Charts
Wenn Sie bei der Installation oder Aktualisierung des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Diagramms einen Fehler feststellen, der durch vorhandene Ressourcen verursacht wird, liegt dies wahrscheinlich daran, dass Sie den CloudWatch Agenten und die zugehörigen Komponenten wie den ServiceAccount, den ClusterRole und den bereits auf dem Cluster ClusterRoleBinding installiert haben.
Der vom Add-on angezeigte Fehler beinhaltet: Conflicts found when trying to apply. Will not continue due to resolve conflicts mode
Der im Helm-Diagramm angezeigte Fehler wird ähnlich sein wieError: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.
.
Wenn das Add-on oder das Helm-Diagramm versucht, den CloudWatch Agenten und die zugehörigen Komponenten zu installieren und dabei eine Änderung des Inhalts feststellt, schlägt die Installation oder Aktualisierung standardmäßig fehl, um zu verhindern, dass der Status der Ressourcen auf dem Cluster überschrieben wird.
Wenn Sie versuchen, das Amazon CloudWatch Observability EKS-Add-on zu integrieren und dieser Fehler auftritt, empfehlen wir, ein vorhandenes CloudWatch Agenten-Setup zu löschen, das Sie zuvor auf dem Cluster installiert hatten, und dann das EKS-Add-on oder das Helm-Diagramm zu installieren. Stellen Sie sicher, dass Sie alle Anpassungen, die Sie möglicherweise am ursprünglichen CloudWatch Agenten-Setup vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese bei der nächsten Installation oder Aktualisierung in das Add-on oder das Helm-Diagramm übernehmen. Wenn Sie den CloudWatch Agenten für das Onboarding in Container Insights bereits installiert hatten, finden Sie Den CloudWatch Agenten und Fluent Bit für Container Insights löschen weitere Informationen unter.
Alternativ unterstützt das Add-On eine Konfigurationsoption zur Konfliktlösung, die OVERWRITE
spezifizieren kann. Sie können diese Option verwenden, um mit der Installation oder Aktualisierung des Add-Ons fortzufahren, indem Sie die Konflikte auf dem Cluster überschreiben. Wenn Sie die Amazon-EKS-Konsole verwenden, finden Sie die Methode zur Konfliktlösung, wenn Sie beim Erstellen oder Aktualisieren des Add-Ons die optionalen Konfigurationseinstellungen auswählen. Wenn Sie den verwenden AWS CLI, können Sie den in Ihren Befehl eingeben, --resolve-conflicts OVERWRITE
um das Add-on zu erstellen oder zu aktualisieren.