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 Lambda-Webfunktionen

Beginnen Sie mit dem Ressourcenstatus, der HTTP-Antwort und den Protokollen für die Anfrage. Webfunktionen stellen einen separaten Status für die Funktion, die Revision, den Endpunkt und jede Region eines MultiRegion PerRegion OR-Endpunkts bereit. Ein Ausfall einer Ressource ändert nicht immer den Status der anderen.

Sammeln von Diagnoseinformationen

Probleme bei der Bereitstellung und beim Start

Um wiederholte Bereitstellungsfehler zu vermeiden, überprüfen Sie die Konfiguration und den Start in einer Testrevision, bevor Sie eine Produktionsrevision erstellen.

CLI- und Paketfehler

Fehler bei HTTP-Anfragen

Grenzwerte für Header anfordern

Für Anforderungsheader gelten zwei Grenzwerte. Lambda begrenzt den Header-Block auf 128 KiB und lehnt größere Anfragen ab, bevor sie Ihre Funktion erreichen. Der Node.js HTTP-Server in Ihrer Funktion begrenzt auch die Anzahl der Header-Zeilen, die er akzeptiert. Beide geben HTTP 431 Request Header Fields Too Large zurück, wie in der folgenden Tabelle dargestellt. Informationen zu den Plattformbeschränkungen finden Sie unterHeader-Grenzwerte.

Die Größenbeschränkung zählt jedes Byte des Anforderungskopfs, wenn der Client ihn sendet. Dazu gehören die Anforderungszeile, jede Header-Zeile (einschließlich Host aller Header, die die Client-Bibliothek hinzufügt) und die Zeilenabschlüsse. Header, die Lambda hinzufügt, werden nicht auf die Größenbeschränkung angerechnet.

Wenn eine Anforderung die Größenbeschränkung überschreitet, lehnt Lambda sie ab, bevor sie Ihre Funktion erreicht, sodass die Anforderung keinen Aufruf und keinen Eintrag im Anwendungsprotokoll erzeugt. Der lambda-web-error-type Antwort-Header identifiziert die Ursache.

Bei der Node.js Zählbegrenzung werden Kopfzeilen gezählt, keine eindeutigen Header-Namen. Ein Header, der dreimal wiederholt wird, zählt dreimal. Daher kann eine Anfrage, die Header sammelt x-forwarded-for oder über eine Kette von Proxys verfolgt, das Limit erreichen. Damit das passiert, muss kein einzelner Header ungewöhnlich aussehen. Das Limit wird anhand der Anfrage gemessen, die Ihre Funktion empfängt, einschließlich der von Lambda hinzugefügten Header. Das hat zur Folge, dass ein Client, der etwas weniger als 1.000 Header-Zeilen sendet, diesen Wert erreichen kann. In diesem Fall erreicht die Anfrage Ihre Ausführungsumgebung und der Node.js Server lehnt sie beim Parsen ab. Ihr Handler läuft nicht. Die Antwort enthält die lambda-web-logstream Header lambda-web-request-id und, aber sie enthält nicht den lambda-web-error-type Header.

Wenn Ihre Anwendung mehr Kopfzeilen akzeptieren muss, als die Node.js Standardeinstellung zulässt, erhöhen Sie das Node.js Limit in Ihrem Servercode. Stellen Sie server.maxHeadersCount die Anzahl der Kopfzeilen ein, die akzeptiert werden sollen, oder setzen Sie sie auf, 0 um die Node.js Zählprüfung zu deaktivieren. Die Größenbeschränkung von 128 KiB gilt weiterhin.

const server = http.createServer(handler);
server.maxHeadersCount = 2000;
server.listen(port, host);

Sie müssen die Größenbeschränkung für Node.js Header nicht ändern. In den verwalteten Node.js Laufzeiten ist es so eingestellt, dass es dem Plattformlimit entspricht, sodass das Plattformlimit für die Header-Größe gilt. Sie können das Plattformlimit nicht anhand des Anwendungscodes erhöhen.

Um die Grenzwerte einzuhalten, verschieben Sie den Massenstatus aus den Headern in den Anforderungstext, kürzen Sie Cookies und reduzieren Sie redundante Proxy- und Tracing-Header, bevor die Anfrage den Endpunkt erreicht. Wenn sich eine CloudFront Distribution vor dem Endpunkt befindet, leiten Sie nur die Header weiter, die Ihre Anwendung in der ursprünglichen Anforderungsrichtlinie benötigt.

Fehlertypen der Webfunktion

Wenn eine Anfrage an einen Webfunktions-Endpunkt fehlschlägt, gibt Lambda einen lambda-web-error-type Antwortheader zurück, der angibt, was schief gelaufen ist. Der Wert verwendet das Format<Prefix>.<ErrorReason>: Das Präfix gibt an, wo der Fehler aufgetreten ist, und der Grund gibt die Ursache an.

Runtime.RequestTimeoutBedeutet beispielsweise, dass die verwaltete Laufzeit gemeldet hat, dass Ihre Funktion nicht innerhalb des konfigurierten Timeouts reagiert hat, und Application.InitCodeError dass Ihr eigener Initialisierungscode einen Fehler ausgelöst hat.

Lambda schließt den lambda-web-error-type Header ein, wenn der Fehler durch die Anfrage selbst oder durch Ihre Funktion, ihre Konfiguration oder ihren Code verursacht wurde. Lambda lässt den Header für interne Dienstfehler und für Autorisierungsfehler weg, sodass einem nicht autorisierten Anrufer keine Details preisgegeben werden. Ein Wert weist auf ein Problem auf dem Pfad zwischen der Lambda-Plattform und Ihrer Funktion hin. Im Anforderungspfad gibt der Fehler an, wo die Anfrage fehlgeschlagen ist. Verwenden Sie im Antwortpfad den Wert zusammen mit Ihrer Anwendungstelemetrie, um zu verstehen, was passiert ist.

Die Einschränkungsmetriken, die angeben, welcher Grenzwert angewendet wurde (für die Platform.EndpointMaxEnvThrottle FehlertypenPlatform.AccountRequestThrottle,Platform.EndpointRequestThrottle, und)Platform.AccountActiveVCPUArm64Throttle, finden Sie unter. Regionale Nutzungs- und Drosselungsmetriken

Protokolle oder Metriken fehlen

Wenn überhaupt keine Anwendungsprotokolle angezeigt werden, fehlen der Ausführungsrolle möglicherweise die Amazon CloudWatch Logs-Berechtigungen. Hängen Sie die AWSLambdaBasicExecutionRole verwaltete Richtlinie an die Ausführungsrolle an oder gewähren Sie logs:CreateLogGrouplogs:CreateLogStream, undlogs:PutLogEvents. Die erforderlichen Berechtigungen finden Sie unter Rolle „Ausführung“.

Probleme mit Codespeicherung und Verschlüsselung

Probleme mit und Endpunkten MultiRegionPerRegion

Verwenden Sie das regionalEndpoints Feld, um die betroffene Region zu identifizieren. Vergleichen Sie seine stateReason und updateStatusReason mit den gesunden Regionen. Prüfen Sie die regionalen Kontingente, die AWS KMS wichtigsten Replikate, die Laufzeitverfügbarkeit und den Replikationsstatus der Revision. Nachdem Sie die Ursache behoben haben, wiederholen Sie das Endpunkt-Update. Informationen zum Replikationsmodell finden Sie unterMulti-Region Einsatz.

Bei einem MultiRegion Endpunkt garantiert latenzbasiertes Routing (das Anfragen an die Region mit der niedrigsten gemessenen Latenz weiterleitet) nicht, dass jede Anfrage an die Region mit der niedrigsten Latenz gesendet wird. Testen Sie vom betroffenen Client-Standort aus und überprüfen Sie die Anwendungsprotokolle, um festzustellen, welche Region die Anfrage bearbeitet hat. Überprüfen Sie für einen PerRegion Endpunkt auch Ihre externe DNS- oder Front-Door-Routing-Konfiguration.

Netzwerk- und Verbindungsprobleme

Die meisten Verbindungsprobleme sind auf eine Serverversion zurückzuführen, die keine Connector-Referenz enthält oder auf eine ältere Connector-Version verweist, oder auf Connector-Subnetze, Sicherheitsgruppen oder Routen, die den Datenverkehr blockieren.

Verwenden Sie die folgende Reihenfolge, um ein Verbindungsproblem zu isolieren:

Zu den häufigsten Symptomen gehören die folgenden.

Es gibt keinen interaktiven Zugriff auf eine Ausführungsumgebung für Webfunktionen. Verwenden Sie Anwendungsprotokolle, Endpunkt-Antwort-Header, Ressourcenstatusfelder, CloudWatch Metriken und VPC-Flow-Logs, um Fehler zu diagnostizieren.

Bereiten Sie ein Eskalationspaket vor

Wenn bei den vorherigen Prüfungen die Ursache nicht ermittelt wurde, sammeln Sie die folgenden Informationen, bevor Sie einen AWS Support Fall eröffnen. Auf diese Weise kann der Support-Techniker den Betrieb der Steuerungsebene, den regionalen Einsatz, die Anfrage und die Telemetrie miteinander korrelieren:

Ähnliche Informationen