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-Ereignisfunktionen
<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 Event-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 Sie den [AWS Systems Manager Parameter Store und die AWS Secrets Manager Erweiterung](with-secrets-manager.md) mit Lambda SnapStart verwenden. Wenn Ihre Funktion verwendet SnapStart, ruft sie Anmeldeinformationen von einem Container-Endpunkt ab, und Lambda legt die `AWS_SESSION_TOKEN` Umgebungsvariable nicht fest. Wenn Ihre Funktion den `X-Aws-Parameters-Secrets-Token` Header aus dieser Umgebungsvariablen festlegt, ist der Header leer und die Erweiterung lehnt die Anfrage ab.

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

Um diesen Fehler zu beheben, verwenden Sie die AWS SDK-Anmeldeinformationsanbieterkette, um das Sitzungstoken abzurufen, anstatt die `AWS_SESSION_TOKEN` Umgebungsvariable direkt zu lesen. Setzen Sie den `X-Aws-Parameters-Secrets-Token` Header auf das von der Anbieterkette zurückgegebene Token. Die Anbieterkette für Anmeldeinformationen gibt in allen Initialisierungsmodi das richtige Sitzungstoken zurück, einschließlich. SnapStart Einen Beispielcode finden Sie unter [Verwenden Sie Secrets Manager Manager-Geheimnisse in Lambda-Ereignisfunktionen](with-secrets-manager.md).

## 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-Ereignisfunktionen speichern bereits DNS-Antworten im Cache. Wenn Sie einen anderen DNS-Cache mit verwenden SnapStart, kann es zu Verbindungstimeouts 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-Ereignisfunktion mit der `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0` Umgebungsvariablen festlegen.

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

**Fehler:** Ihre AWS Lambda SnapStart Funktion konnte nicht aufgerufen werden. 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.