

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
<a name="microvms-troubleshooting"></a>

In diesem Abschnitt wird beschrieben, wie Sie häufig auftretende Probleme bei der Arbeit mit AWS Lambda MicroVMs debuggen und beheben.

## Shell-Zugriff
<a name="microvms-troubleshooting-shell"></a>

Verwenden Sie den Shell-Zugriff, um zum Debuggen und zur Fehlerbehebung eine direkte Verbindung zu einer laufenden MicroVM herzustellen.

Sie können auf zwei Arten eine Verbindung zu einer MicroVM-Shell herstellen:
+ **Konsole ** — Wählen Sie Ihre MicroVM in der Lambda-Konsole aus und wählen Sie Connect.
+ **CLI ** — Generieren Sie ein Shell-Token mit `create-microvm-shell-auth-token` und verwenden Sie das Token dann, um eine Verbindung herzustellen.

Generieren Sie ein Shell-Token und stellen Sie dann eine Verbindung her:

```
aws lambda-microvms create-microvm-shell-auth-token \
  --microvm-identifier <id> --expiration-in-minutes 30
# In Console: select MicroVM -> Connect
# In shell: ctr task ls, then ctr task exec -t --exec-id shell <id> /bin/sh
```

Die MicroVM muss mit dem `SHELL_INGRESS` Netzwerkanschluss (`arn:aws:lambda:{{us-east-1}}:aws:network-connector:aws-network-connector:SHELL_INGRESS`) ausgeführt worden sein. Wenn die MicroVM nicht mit diesem Connector gestartet wurde, wird ein `create-microvm-shell-auth-token` zurückgegeben. `ValidationException`

Für andere Probleme:
+ Überprüfen Sie das `terminationMessage` Feld in der `get-microvm` Antwort auf terminierte MicroVMs.
+ Überprüfen Sie die CloudWatch Build-Protokolle auf Probleme bei der Image-Erstellung.
+ Überprüfen Sie das `StateReason` Feld auf Netzwerkanschlüsse im `FAILED` Status.

## Fehlerbehebung
<a name="microvms-troubleshooting-troubleshooting"></a>

Dieser Abschnitt enthält Lösungen für häufig auftretende Probleme bei der Arbeit mit Lambda microVMs.


| Symptom | Mögliche Ursache und Lösung | 
| --- | --- | 
| Die Image-Erstellung schlägt fehl (CREATION\_FAILED) | Überprüfen Sie die Build-Protokolle unter/aws/lambda/microvms/<image-name>. Überprüfen Sie die Dockerfile Syntax, die Amazon S3-Berechtigungen und die Verfügbarkeit des Basis-Images. Zur Reproduktion docker build lokal ausführen. | 
| MicroVM steckt fest PENDING | Warten Sie und versuchen Sie es erneut. Falls dies der Fall ist, überprüfen Sie den Zustand des Dienstes. Stellen Sie sicher, dass Ihr Kontingent für Parallelität nicht ausgeschöpft ist. | 
| Die Bewerbung reagiert nach dem Lebenslauf nicht | Implementieren Sie den /resume Lifecycle-Hook, um die Verbindungen wiederherzustellen und den Status zu überprüfen. Stellen Sie nach dem Fortsetzen sicher, dass Ihre App an Port 8080 (oder den konfigurierten Port) gebunden ist. | 
| 502 Fehlerhaftes Gateway vom Endpunkt | Die Anwendung ist abgestürzt oder hört nicht zu. Überprüfen Sie die Laufzeitprotokolle. Verifizieren EXPOSE und CMD reinDockerfile. Bei der automatischen Wiederaufnahme konnte die MicroVM möglicherweise nicht wieder aufgenommen werden (überprüfen Sie den Status mithilfe get-microvm von). | 
| 429 Zu viele Anfragen | Die Anforderungsrate wurde überschritten. Versuchen Sie es erneut mit exponentiellem Backoff und Jitter. | 
| Verbindungen werden unterbrochen | Das Leerlauf-Timeout wurde ausgelöst. Implementieren Sie ping/pong Keepalives. Oder verlängern Sie die maxIdleDurationSeconds Idle-Richtlinie. | 
| Hohe Latenz am Endpunkt | Bandbreitensättigung. Prüfen Sie, ob der Datenverkehr die Bandbreitenkapazität für Ihre MicroVM-Größe überschreitet. Skalieren Sie auf eine größere Größe. | 
| Das Authentifizierungstoken ist abgelaufen (403) | Token haben ein konfigurierbares Ablaufdatum. Generieren Sie ein neues Token, bevor das alte abläuft. Implementieren Sie die Token-Aktualisierungslogik in Ihrem Client. | 
| VPC-Ausgang funktioniert nicht | Stellen Sie sicher, dass der Netzwerkanschluss in ACTIVE Ordnung ist. Überprüfen Sie, ob die Sicherheitsgruppenregeln ausgehenden Verkehr zulassen. Vergewissern Sie sich, dass Subnetze Routen zu Ihren Zielressourcen haben. | 

## Häufige Fehler (Image-Erstellung)
<a name="microvms-troubleshooting-image-errors"></a>


| Fehler | Ursache | Lösung | 
| --- | --- | --- | 
| S3\_ACCESS\_DENIED | Der Build-Rolle fehlen die Berechtigungen zum Abrufen des Amazon S3-Artefakts. | Fügen Sie s3:GetObject die Berechtigung für Ihren Artefakt-Bucket hinzu. | 
| S3\_NO\_SUCH\_KEY | Der Artefaktschlüssel ist im Bucket nicht vorhanden. | Stellen Sie sicher, dass der Amazon S3-Pfad korrekt ist. | 
| S3\_NO\_SUCH\_BUCKET | Der Amazon S3-Bucket ist nicht vorhanden. | Überprüfen Sie den Bucket-Namen und bestätigen Sie, dass er erstellt wurde. | 
| S3\_INVALID\_OBJECT | Artefakt in der Speicherklasse Glacier oder in der Speicherklasse, auf die nicht direkt zugegriffen werden kann. | Verschiebe das Artefakt in die Speicherklasse Standard. | 
| S3\_CROSS\_REGION\_ACCESS\_DENIED | Das Artefakt befindet sich in einer anderen Region als das MicroVM-Image. | Stellen Sie sicher, dass sich Ihr Artefakt in derselben Region wie Ihr MicroVM-Image befindet. | 
| ARCHIVE\_DOCKERFILE\_NOT\_FOUND | Im Zip-Archiv fehlt ein Dockerfile im Stammverzeichnis. | Fügen Sie a Dockerfile zum Stammverzeichnis Ihres ZIP-Archivs hinzu. | 
| ARCHIVE\_INVALID | Die Archivdatei ist kein gültiges ZIP-Archiv oder beschädigt. | Re-create das ZIP-Archiv und erneut hochladen. | 
| CONTAINER\_BUILD\_FAILED | Ungültige Dockerfile Anweisungen, fehlende Dateien oder Syntaxfehler. | Debuggen Sie Ihre Dockerfile lokal mitdocker build. | 
| DISK\_STORAGE\_FULL | MicroVM ging während des Builds der Speicherplatz aus. | Reduzieren Sie die Größe der Artefakte oder wenden Sie sich an den Support. | 
| INTERNAL\_PLATFORM\_ERROR | Es ist ein interner Fehler aufgetreten. | Wiederholen Sie den Vorgang. Wenn das Problem weiterhin besteht, wenden Sie sich an den Support. | 

## Fehlerbehebung beim Netzwerkanschluss
<a name="microvms-troubleshooting-connector-errors"></a>


| Fehlercode | Ursache | Lösung | 
| --- | --- | --- | 
| DisallowedByVpcEncryptionControl | Die VPC verfügt über eine Verschlüsselungskontrollrichtlinie, die unverschlüsselte Netzwerkschnittstellen oder Datenverkehr verhindert. Lambda kann keine ENIs erstellen, die die Verschlüsselungsanforderungen erfüllen. | Fügen Sie Lambda zur Ausschlussliste der VPC-Verschlüsselungskontrolle hinzu. Wenn ein Ausschluss nicht möglich ist, verwenden Sie eine VPC oder ein Subnetz, auf das keine restriktiven Verschlüsselungskontrollen angewendet wurden. | 
| Ec2RequestLimitExceeded | Lambda führt EC2-API-Aufrufe durch (z. B.,DescribeSubnets)CreateNetworkInterface, um die Konnektivität einzurichten. Zu viele gleichzeitige EC2-API-Aufrufe führen zu einer Drosselung. | Versuchen Sie den Vorgang nach einer kurzen Verzögerung erneut. Wenn der Vorgang andauert, reduzieren Sie die gleichzeitigen Netzwerkverbindungsvorgänge oder fordern Sie beim Support eine Erhöhung des EC2-API-Drosselungslimits an. AWS  | 
| InsufficientRolePermissions | Für die Betreiberrolle fehlen die erforderlichen EC2-Berechtigungen. | Stellen Sie sicher, dass die IAM-Rolle über die erforderlichen EC2-Netzwerkberechtigungen verfügt. | 
| InternalError | Während der Verarbeitung der Network Connector-Anfrage ist im Lambda-Dienst ein unerwarteter Fehler aufgetreten. | Wiederholen Sie den Vorgang. Wenn der Fehler auch nach mehreren Versuchen weiterhin besteht, wenden Sie sich mit dem ARN des Netzwerkkonnektors und dem ungefähren Zeitstempel an den AWS Support. | 
| InvalidSecurityGroup | Die Sicherheitsgruppen-ID ist nicht vorhanden, wurde gelöscht oder gehört nicht zu derselben VPC wie die angegebenen Subnetze. | Stellen Sie sicher, dass alle Sicherheitsgruppen-IDs existieren und zu derselben VPC gehören wie die Subnetze. aws ec2 describe-security-groups --group-ids <sg-id>Zur Validierung verwenden. | 
| InvalidSubnet | Die Subnetz-ID ist nicht vorhanden, wurde gelöscht oder gehört zu einer anderen VPC als erwartet. | Stellen Sie sicher, dass alle Subnetz-IDs existieren und zur richtigen VPC gehören. aws ec2 describe-subnets --subnet-ids <subnet-id>Zur Validierung verwenden. | 
| SubnetOutOfIPAddresses | Der CIDR-Block des Subnetzes ist erschöpft — alle IPs sind ENIs, Instances und anderen Ressourcen zugewiesen, sodass Lambda keine Netzwerkschnittstelle erstellen kann. | Geben Sie IP-Adressen frei, indem Sie ungenutzte entfernen ENIs/instances, oder verwenden Sie ein anderes Subnetz mit verfügbarer Kapazität. Ziehen Sie größere Subnetze (z. B. /24 oder größer) für Netzwerkanschlüsse in Betracht. | 