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.
Fehlerbehebung bei App Mesh-Skalierung
Wichtig
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag Migration von AWS App Mesh zu Amazon ECS Service Connect
In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der App Mesh-Skalierung auftreten können.
Konnektivität schlägt fehl und Container-Integritätsprüfungen schlagen fehl, wenn mehr als 50 Replikate für einen virtuellen Knoten/ein virtuelles Gateway skaliert werden
Symptome
Wenn Sie die Anzahl der Replikate, z. B. Amazon ECS-Aufgaben, Kubernetes-Pods oder EC2 Amazon-Instances, für ein virtuelles node/virtual gateway beyond 50, Envoy container health checks for new
and currently running Envoys begin to fail. Downstream applications sending traffic to the
virtual node/virtual Gateway skalieren, werden Anforderungsfehler mit HTTP-Statuscode angezeigt. 503
Auflösung
Das Standardkontingent von App Mesh für die Anzahl der Envoys pro virtuellem Knoten/virtuellem Gateway beträgt 50. Wenn die Anzahl der laufenden Envoys dieses Kontingent überschreitet, können neue und aktuell laufende Envoys mit dem gRPC-Statuscode () keine Verbindung zum Envoy-Verwaltungsdienst von App Mesh herstellen. 8 RESOURCE_EXHAUSTED Dieses Kontingent kann erhöht werden. Weitere Informationen finden Sie unter App Mesh Mesh-Dienstkontingente.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem
Anfragen schlagen fehl503, wenn ein virtuelles Service-Backend horizontal nach oben oder unten skaliert wird
Symptome
Wenn ein virtueller Back-End-Dienst horizontal nach oben oder unten skaliert wird, schlagen Anfragen von Downstream-Anwendungen fehl und es wird ein HTTP 503 Statuscode angezeigt.
Auflösung
App Mesh empfiehlt mehrere Ansätze, um Fehlerfälle zu minimieren und gleichzeitig Anwendungen horizontal zu skalieren. Ausführliche Informationen darüber, wie Sie diese Fehler verhindern können, finden Sie unterBewährte Methoden für App Mesh.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem
Der Envoy-Container stürzt bei erhöhter Last mit Segfault ab
Symptome
Bei hoher Verkehrslast stürzt der Envoy-Proxy aufgrund eines Segmentierungsfehlers (Linux-Exit-Code) ab. 139 Die Envoy-Prozessprotokolle enthalten eine Aussage wie die folgende.
Caught Segmentation fault, suspect faulting address 0x0"Auflösung
Der Envoy-Proxy hat wahrscheinlich das standardmäßige Nofile-Ulimit des Betriebssystems überschritten, das Limit für die Anzahl der Dateien, die ein Prozess gleichzeitig geöffnet haben kann. Dieser Verstoß ist darauf zurückzuführen, dass der Datenverkehr mehr Verbindungen verursacht, die zusätzliche Betriebssystem-Sockets verbrauchen. Um dieses Problem zu beheben, erhöhen Sie den Wert ulimit nofile auf dem Host-Betriebssystem. Wenn Sie Amazon ECS verwenden, kann dieses Limit über die Ulimit-Einstellungen in den Ressourcenlimiteinstellungen der Aufgabendefinition geändert werden.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem
Die Erhöhung der Standardressourcen spiegelt sich nicht in den Service-Limits wider
Symptome
Nachdem Sie das Standardlimit für App Mesh Mesh-Ressourcen erhöht haben, wird der neue Wert nicht berücksichtigt, wenn Sie sich Ihre Dienstlimits ansehen.
Auflösung
Die neuen Limits werden derzeit zwar nicht angezeigt, Kunden können sie aber trotzdem nutzen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem
Die Anwendung stürzt aufgrund einer großen Anzahl von Aufrufen von Health Checks ab.
Symptome
Nach der Aktivierung aktiver Integritätsprüfungen für einen virtuellen Knoten nimmt die Anzahl der Health Check-Aufrufe zu. Die Anwendung stürzt ab, weil die Anzahl der an die Anwendung gesendeten Health-Check-Aufrufe stark angestiegen ist.
Auflösung
Wenn die aktive Integritätsprüfung aktiviert ist, sendet jeder Envoy-Endpunkt des Downstreams (Client) Integritätsanfragen an jeden Endpunkt des Upstream-Clusters (Server), um Routing-Entscheidungen zu treffen. Folglich würde die Gesamtzahl der Anfragen zur Zustandsprüfung number of
client Envoys * number of server Envoys * active health check
frequency betragen.
Um dieses Problem zu beheben, ändern Sie die Häufigkeit der Zustandsprüfungen, wodurch sich das Gesamtvolumen der Zustandsprüfungen verringern würde. Zusätzlich zu aktiven Zustandsprüfungen ermöglicht App Mesh die Konfiguration der Erkennung von Ausreißern als Mittel zur passiven Zustandsprüfung. Verwenden Sie die Ausreißererkennung, um anhand aufeinanderfolgender 5xx Antworten zu konfigurieren, wann ein bestimmter Host entfernt werden soll.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem
