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.

# Behebung SnapStart von Fehlern für Lambda-Funktionen
<a name="snapstart-troubleshooting"></a>

Auf dieser Seite werden häufig auftretende Probleme behandelt, die bei der Verwendung von Lambda auftreten SnapStart, darunter Fehler bei der Snapshot-Erstellung, Timeoutfehler und interne Dienstfehler.

## SnapStartNotReadyException
<a name="snapstartnotreadyexception"></a>

**Fehler:** Beim Aufrufen der Operation Invoke20150331 ist ein Fehler aufgetreten (SnapStartNotReadyException): Lambda initialisiert Ihre Funktion. Sie ist aufrufbereit, sobald der Status Ihrer Funktion auf AKTIV gesetzt wird.

### Häufige Ursachen
<a name="snapstartnotreadyexception-cause"></a>

Dieser Fehler tritt auf, wenn Sie versuchen, eine Funktionsversion aufzurufen, die sich im `Inactive` [Status](snapstart-activate.md#snapstart-function-states) befindet. Die Version Ihrer Funktion wird zu `Inactive`, wenn sie 14 Tage lang nicht mehr aufgerufen wurde oder wenn Lambda die Ausführungsumgebung periodisch recycelt

### Auflösung
<a name="snapstartnotreadyexception-resolution"></a>

Warten Sie, bis die Funktionsversion den `Active`-Status erreicht hat, und rufen Sie es dann erneut auf.

## SnapStartTimeoutException
<a name="snapstart-invocation-failure"></a>

**Problem:** Sie erhalten eine, `SnapStartTimeoutException` wenn Sie versuchen, eine Funktionsversion aufzurufen. SnapStart 

### Häufige Ursache
<a name="snapstart-invocation-failure-cause"></a>

In der [Wiederherstellungs](lambda-runtime-environment.md#runtimes-lifecycle-restore)phase stellt Lambda die Java-Laufzeit wieder her und führt alle [Laufzeit-Hooks](snapstart-runtime-hooks.md) nach der Wiederherstellung aus. Wenn ein Laufzeit-Hook nach der Wiederherstellung länger als 10 Sekunden läuft, wird die `Restore`-Phase unterbrochen und Sie erhalten einen Fehler, wenn Sie versuchen, die Funktion aufzurufen. Probleme mit der Netzwerkverbindung und den Anmeldeinformationen können auch zu `Restore`-Phase-Timeouts führen.

### Auflösung
<a name="snapstart-invocation-failure-resolution"></a>

Suchen Sie in den CloudWatch Protokollen der Funktion nach Timeoutfehlern, die während der [Wiederherstellungsphase](lambda-runtime-environment.md#runtimes-lifecycle-restore) aufgetreten sind. Stellen Sie sicher, dass alle Hooks nach der Wiederherstellung in weniger als 10 Sekunden abgeschlossen sind.

**Example CloudWatch protokollieren**  

```
{ "cause": "Lambda couldn't restore the snapshot within the timeout limit. (Service: Lambda, Status Code: 408, Request ID: 11a222c3-410f-427c-ab22-931d6bcbf4f2)", "error": "Lambda.SnapStartTimeoutException"}
```

## 500 Interner Dienstfehler
<a name="snapstart-500-error"></a>

**Fehler:** Lambda konnte keinen neuen Snapshot erstellen, weil Sie das Limit für die gleichzeitige Erstellung von Snapshots erreicht haben.

### Häufige Ursache
<a name="snapstart-500-error-cause"></a>

Ein 500-Fehler ist ein interner Fehler innerhalb des Lambda-Service selbst und kein Problem mit Ihrer Funktion oder Ihrem Code. Diese Fehler treten häufig sporadisch auf.

### Auflösung
<a name="snapstart-500-error-resolution"></a>

Versuchen Sie erneut, die Funktionsversion zu veröffentlichen.

## 401 Nicht autorisiert
<a name="snapstart-401-unauthorized"></a>

**Fehler:** Falsches Sitzungstoken oder Header-Schlüssel

### Häufige Ursache
<a name="snapstart-401-unauthorized-cause"></a>

Dieser Fehler tritt auf, wenn der [AWS Systems Manager Parameter Store und die AWS Secrets Manager Erweiterung](with-secrets-manager.md) mit Lambda SnapStart verwendet werden.

### Auflösung
<a name="snapstart-401-unauthorized-resolution"></a>

Der AWS Systems Manager Parameterspeicher und die AWS Secrets Manager Erweiterung sind nicht kompatibel mit SnapStart. Die Erweiterung generiert Anmeldeinformationen für die Kommunikation mit ihnen AWS Secrets Manager während der Funktionsinitialisierung, was bei Verwendung von zu Fehlern mit abgelaufenen Anmeldeinformationen führt. SnapStart

## UnknownHostException (Java)
<a name="snapstart-dns-caching"></a>

**Fehler:** HTTP-Anfrage kann nicht ausgeführt werden: Das Zertifikat für `abc.us-east-1.amazonaws.com` stimmt mit keinem der alternativen Namen des Betreffs überein.

### Häufige Ursache
<a name="snapstart-dns-caching-cause"></a>

Lambda-Funktionen speichern DNS-Antworten bereits im Cache. Wenn Sie einen anderen DNS-Cache mit verwenden SnapStart, kann es zu Verbindungs-Timeouts kommen, wenn die Funktion von einem Snapshot aus wieder aufgenommen wird.

### Auflösung
<a name="snapstart-dns-caching-resolution"></a>

Um `UnknownHostException`-Ausfälle in der Java 11-Laufzeit zu vermeiden, empfehlen wir, `networkaddress.cache.negative.ttl` auf 0 zu setzen. In Java 17 und späteren Laufzeiten ist dieser Schritt nicht erforderlich. Sie können diese Eigenschaft für eine Lambda-Funktion mit der Umgebungsvariablen `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0` festlegen.

## Fehler bei der Erstellung von Snapshots
<a name="snapstart-creation-failure"></a>

**Fehler: Ihre** AWS Lambda Funktion konnte nicht aufgerufen werden. SnapStart Wenn dieser Fehler weiterhin besteht, überprüfen Sie die CloudWatch Protokolle Ihrer Funktion auf Initialisierungsfehler.

### Auflösung
<a name="snapstart-creation-failure-resolution"></a>

Überprüfen Sie die CloudWatch Amazon-Logs Ihrer Funktion auf Timeouts vor dem [Checkpoint-Runtime-Hook](snapstart-runtime-hooks.md). Sie können auch versuchen, eine neue Funktionsversion zu veröffentlichen, wodurch das Problem manchmal behoben werden kann.

## Latenzzeit bei der Snapshot-Erstellung
<a name="snapstart-creation-latency"></a>

**Problem:** Wenn Sie eine neue Funktionsversion veröffentlichen, bleibt die Funktion lange im `Pending` [Status](snapstart-activate.md#snapstart-function-states).

### Häufige Ursache
<a name="snapstart-creation-latency-cause"></a>

Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist.

Wenn Ihre Funktion mit einer [VPC verbunden ist](configuration-vpc.md#configuration-vpc-attaching), muss Lambda möglicherweise auch Netzwerkschnittstellen erstellen, bevor die Funktion `Active` wird. Wenn Sie versuchen, die Funktionsversion aufzurufen, während die Funktion `Pending` ist, erhalten Sie möglicherweise eine 409 `ResourceConflictException`. Wenn die Funktion über einen Amazon-API-Gateway-Endpunkt aufgerufen wird, erhalten Sie möglicherweise einen 500-Fehler im API Gateway.

### Auflösung
<a name="snapstart-creation-latency-resolution"></a>

Warten Sie mindestens 15 Minuten, bis die Funktionsversion initialisiert ist, bevor Sie sie aufrufen.