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.
Erweiterte Konfiguration für oTEL Container Insights auf Amazon EKS
Dieses Thema behandelt erweiterte Konfigurationsszenarien für oTEL Container Insights auf Amazon EKS. Verwenden Sie diese Konfigurationen, um die Metrikerfassung anzupassen, Protokolle zu filtern, kontenübergreifende Telemetriedaten zu sammeln, benutzerdefinierte Dimensionen hinzuzufügen und die Ressourcenzuweisung für große Cluster zu optimieren.
Voraussetzungen
Bevor Sie erweiterte Einstellungen konfigurieren, stellen Sie sicher, dass Sie die folgenden Anforderungen erfüllen.
-
oTEL Container Insights ist auf Ihrem Amazon EKS-Cluster installiert und befindet sich im
ACTIVEStatus -
Amazon EKS-Cluster mit Kubernetes Version 1.28 oder höher
-
AWS CLI Version 2.15.0 oder höher
-
kubectlkonfiguriert für die Kommunikation mit Ihrem Zielcluster -
IAM-Berechtigungen:
eks:UpdateAddoneks:DescribeAddon, undiam:AttachRolePolicy(erforderlich für die kontoübergreifende Konfiguration)
Allgemeines Konfigurationsmuster
Alle erweiterten Konfigurationen folgen demselben Muster. Sie übergeben eine JSON-Konfiguration mit dem aws eks
update-addon Befehl an das amazon-cloudwatch-observability Add-on.
aws eks update-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --configuration-values 'JSON-configuration' \ --resolve-conflicts OVERWRITE
Wichtig
Das --resolve-conflicts OVERWRITE Flag ersetzt jede bestehende Add-On-Konfiguration. Um bestehende Einstellungen beizubehalten, führen Sie sie mit Ihrer neuen Konfiguration zusammen, bevor Sie den Befehl ausführen.
Filtern von Protokollen
Sie können die CloudWatch Protokollkosten senken, indem Sie Protokolle ausschließen, die bestimmten Kriterien entsprechen. Verwenden Sie die Protokollfilterung, um Protokolle auf Debug-Ebene oder ausführliche Protokolle zu löschen, bevor der Agent sie an sie sendet. CloudWatch
Um die Protokollfilterung zu konfigurieren
-
Führen Sie den folgenden Befehl aus, um das Add-on mit einer Protokollfilterkonfiguration zu aktualisieren.
cluster-nameErsetzen Sie durch den Namen Ihres Amazon EKS-Clusters.aws eks update-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --configuration-values '{ "otelContainerInsights": { "enabled": true }, "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true } }, "exclude_filters": [ { "type": "log_level_filter", "log_level": "DEBUG" } ] } } } }' \ --resolve-conflicts OVERWRITE -
Stellen Sie sicher, dass der Status des Add-ons
ACTIVEnach dem Update lautet.aws eks describe-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --query "addon.status" \ --output text
Die exclude_filters Konfiguration entfernt Protokolleinträge, die der angegebenen Protokollebene entsprechen, bevor der Agent sie an CloudWatch Logs sendet. Dadurch werden das Volumen der Protokollaufnahme und die damit verbundenen Kosten reduziert.
Multi-account Sammlung
Sie können Telemetriedaten von Workload-Konten an ein zentrales Überwachungskonto senden, indem Sie die kontoübergreifende IAM-Rollenübernahme konfigurieren. Dieser Ansatz bietet Ihnen eine zentrale Ansicht von Metriken und Protokollen aus mehreren Amazon EKS-Clustern über verschiedene AWS Konten hinweg.
So richten Sie die Erfassung mehrerer Konten ein
Um die kontenübergreifende Rolle im Überwachungskonto zu erstellen
-
Erstellen Sie im zentralen Überwachungskonto eine IAM-Rolle mit einer Vertrauensrichtlinie, die es dem Workload-Konto ermöglicht, diese Rolle zu übernehmen.
workload-account-idErsetzen Sie es durch die AWS Konto-ID des Workload-Kontos.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::workload-account-id:root" }, "Action": "sts:AssumeRole" } ] } -
Ordnen Sie die
CloudWatchAgentServerPolicyverwaltete Richtlinie der kontoübergreifenden Rolle zu.
Um das Add-on für die kontoübergreifende Bereitstellung zu konfigurieren
-
Aktualisieren Sie das Add-on im Workload-Konto, sodass es die kontoübergreifende Rolle übernimmt.
cluster-nameErsetzen Sie durch den Namen Ihres Amazon EKS-Clusters undmonitoring-account-iddurch die AWS Konto-ID des zentralen Monitoring-Kontos.aws eks update-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --configuration-values '{ "otelContainerInsights": { "enabled": true }, "agent": { "config": { "credentials": { "role_arn": "arn:aws:iam::monitoring-account-id:role/CrossAccountCWObservabilityRole" } } } }' \ --resolve-conflicts OVERWRITE -
Stellen Sie sicher, dass sich der Status des Add-ons
ACTIVEnach dem Update befindet.aws eks describe-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --query "addon.status" \ --output text
Benutzerdefinierte metrische Abmessungen
Sie können Ihren Container Insights-Metriken benutzerdefinierte Dimensionen hinzufügen, die von Kubernetes-Labels abgeleitet wurden. Mit benutzerdefinierten Dimensionen können Sie Metriken detaillierter filtern und gruppieren, z. B. nach Team, Umgebung oder Anwendungsebene.
Um benutzerdefinierte Dimensionen aus Kubernetes-Labels hinzuzufügen
-
Führen Sie den folgenden Befehl aus, um benutzerdefinierte Dimensionen zu konfigurieren.
cluster-nameErsetzen Sie es durch den Namen Ihres Amazon EKS-Clusters undlabel-keydurch das Kubernetes-Label, das als Dimension verwendet werden soll.aws eks update-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --configuration-values '{ "otelContainerInsights": { "enabled": true }, "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "metric_dimensions": { "custom_dimensions": ["label-key"] } } } } } } }' \ --resolve-conflicts OVERWRITE -
Stellen Sie sicher, dass sich der Status des Add-ons
ACTIVEnach dem Update befindet.aws eks describe-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --query "addon.status" \ --output text
Nachdem die Konfiguration wirksam geworden ist, werden die angegebenen Kubernetes-Labels als Dimensionen in Ihren Container Insights-Metriken in angezeigt. CloudWatch
Ressourcenoptimierung für große Cluster
Bei großen Clustern müssen Sie möglicherweise die CPU- und Speicherlimits für den CloudWatch Agenten erhöhen DaemonSet. Die Standardressourcenzuweisung funktioniert gut für kleine Cluster, aber größere Cluster generieren mehr Telemetriedaten und erfordern zusätzliche Agentenressourcen.
Die folgende Tabelle enthält Richtlinien zur Größenbestimmung, die auf der Clustergröße basieren.
| Cluster-Größe | CPU-Anfrage | CPU-Limit | Speicheranforderung | Speicherlimit |
|---|---|---|---|---|
| Klein (20 Knoten oder weniger) | 100 m | 200m | 128 Minuten | 256 Mi |
| Mittel (21—100 Knoten) | 200m | 400 m | 256 Meilen | 512 Mi |
| Groß (über 100 Knoten) | 300 m | 500 m | 384 Meilen | 768 Mi |
| Extra-large (500+ Knoten) | 500 m | 1000m | 512 Mi | 1 Gi |
Um Ressourcenlimits für den Agenten zu konfigurieren DaemonSet
-
Führen Sie den folgenden Befehl aus, um Ressourcenanforderungen und Grenzwerte festzulegen.
cluster-nameErsetzen Sie durch den Namen Ihres Amazon EKS-Clusters und die Ressourcenwerte durch Werte aus der vorherigen Tabelle.aws eks update-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --configuration-values '{ "otelContainerInsights": { "enabled": true }, "agent": { "resources": { "requests": { "cpu": "cpu-request", "memory": "memory-request" }, "limits": { "cpu": "cpu-limit", "memory": "memory-limit" } } } }' \ --resolve-conflicts OVERWRITE -
Vergewissern Sie sich, dass der Status des Add-ons lautet
ACTIVEund dass die Agent-Pods mit der neuen Ressourcenzuweisung neu gestartet werden.aws eks describe-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --query "addon.status" \ --output text -
Vergewissern Sie sich, dass die Agent-Pods mit den neuen Ressourcenlimits ausgeführt werden.
kubectl get pods -n amazon-cloudwatch -l app.kubernetes.io/name=cloudwatch-agent -o jsonpath='{.items[0].spec.containers[0].resources}'
Überprüfen Sie die Konfigurationsänderungen
Nachdem Sie eine erweiterte Konfiguration angewendet haben, stellen Sie sicher, dass das Add-on fehlerfrei ist und dass die Agent-Pods erfolgreich neu gestartet wurden.
Um die Konfigurationsänderungen zu überprüfen
-
Überprüfen Sie, ob der Status des Add-ons lautet
ACTIVE.cluster-nameErsetzen Sie durch den Namen Ihres Amazon EKS-Clusters.aws eks describe-addon \ --cluster-namecluster-name\ --addon-name amazon-cloudwatch-observability \ --query "addon.{Status:status,ConfigValues:configurationValues}" \ --output table -
Stellen Sie sicher, dass die Agenten-Pods neu gestartet wurden und sich im
RunningStatus befinden.kubectl get pods -n amazon-cloudwatch -l app.kubernetes.io/name=cloudwatch-agentAlle Agenten-Pods müssen
Runningden Status mit einer kürzlichen Neustartzeit anzeigen.
Fehlerbehebung
Verwenden Sie die folgenden Anleitungen, um häufig auftretende Probleme mit erweiterten Konfigurationen zu lösen.
Add-on Das Update schlägt fehl mit ConfigurationConflict
Symptom: Der aws eks update-addon Befehl gibt einen ConfigurationConflict Fehler zurück.
Ursache: Die von Ihnen angegebene JSON-Konfiguration ist falsch formatiert oder enthält ungültige Schlüssel.
Lösung: Gehen Sie wie folgt vor, um dieses Problem zu beheben.
-
Überprüfen Sie Ihre JSON-Konfiguration, indem Sie einen JSON-Linter verwenden oder den folgenden Befehl ausführen.
echo 'your-json-configuration' | python3 -m json.tool -
Stellen Sie sicher, dass alle Konfigurationsschlüssel für das
amazon-cloudwatch-observabilityAdd-on gültig sind. -
Versuchen Sie erneut, das Update mit dem korrigierten JSON durchzuführen.
Cross-account Metriken, die nicht im Monitoring-Konto erscheinen
Symptom: Nachdem Sie die Erfassung mehrerer Konten konfiguriert haben, werden die Messwerte nicht im zentralen Überwachungskonto angezeigt.
Ursache: Die kontoübergreifende IAM-Rollen-Vertrauensrichtlinie oder die Berechtigungen sind falsch.
Lösung: Gehen Sie wie folgt vor, um dieses Problem zu beheben.
-
Stellen Sie sicher, dass die Vertrauensrichtlinie im Überwachungskonto es dem Workload-Konto ermöglicht, die Rolle zu übernehmen.
-
Stellen Sie sicher, dass der kontoübergreifenden Rolle die
CloudWatchAgentServerPolicyverwaltete Richtlinie angehängt ist. -
Überprüfen Sie die Agentenprotokolle auf
AssumeRoleFehler.kubectl logs -n amazon-cloudwatch -l app.kubernetes.io/name=cloudwatch-agent --tail=100 | grep -i "AssumeRole\|AccessDenied" -
Stellen Sie sicher, dass die Agent-IAM-Rolle im Workload-Konto über die
sts:AssumeRoleBerechtigung für die kontoübergreifende Rolle ARN verfügt.