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](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-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 ein virtuelles node/virtual Gateway skaliert werden
**Symptome**
Wenn Sie die Anzahl der Replikate, z. B. Amazon ECS-Aufgaben, Kubernetes-Pods oder Amazon EC2 EC2-Instances, für ein virtuelles node/virtual Gateway auf über 50 skalieren, schlagen die Integritätsprüfungen des Envoy-Containers für neue und aktuell laufende Envoys fehl. Downstream-Anwendungen, die Datenverkehr an das virtuelle node/virtual Gateway senden, beginnen, Anforderungsfehler mit HTTP-Statuscode zu erkennen. `503`
**Auflösung**
Das Standardkontingent von App Mesh für die Anzahl der Envoys pro virtuellem node/virtual 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](service-quotas.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Anfragen schlagen fehl`503`, 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 unter[Bewährte Methoden für App Mesh](best-practices.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) in den [Ressourcenlimiteinstellungen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) der Aufgabendefinition geändert werden.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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` \$1 `number of server Envoys` \$1 `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](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).