Beheben von Ausführungsproblemen in Lambda

Wenn die Lambda-Laufzeitumgebung Ihren Funktionscode ausführt, wird das Ereignis möglicherweise auf einer Instance der Funktion verarbeitet, auf der schon länger Ereignisse verarbeitet werden, oder muss möglicherweise eine neue Instance initialisiert werden. Fehler können während der Funktionsinitialisierung, wenn Ihr Handler-Code das Ereignis verarbeitet oder wenn Ihre Funktion eine Antwort zurückgibt (oder nicht zurückgibt), auftreten.

Funktionsausführungsfehler können durch Probleme mit Code, Funktionskonfiguration, nachgeschalteten Ressourcen oder Berechtigungen verursacht werden. Wenn Sie Ihre Funktion direkt aufrufen, sehen Sie Funktionsfehler in der Antwort von Lambda. Wenn Sie Ihre Funktion asynchron mit einer Ereignisquellen-Zuweisung oder über einen anderen Service aufrufen, finden Sie möglicherweise Fehler in Protokollen, eine Warteschlange für unzustellbare Nachrichten oder ein Ziel bei Ausfall. Die Optionen für die Fehlerbehandlung und das Wiederholungsverhalten variieren je nachdem, wie Sie Ihre Funktion aufrufen, und nach der Art des Fehlers.

Wenn Ihr Funktionscode oder die Lambda-Laufzeit einen Fehler zurückgibt, ist der Statuscode in der Antwort von Lambda „200 OK“. Das Vorhandensein eines Fehlers in der Antwort wird durch einen Header namens X-Amz-Function-Error angezeigt. Statuscodes der Serien 400 und 500 sind für Aufruffehler reserviert.

Lambda: Remote-Debugging mit Visual Studio Code

Problem: Schwierigkeiten bei der Behebung des komplexen Verhaltens von Lambda-Funktionen in der tatsächlichen Umgebung AWS

Lambda bietet ein Remote-Debugging-Feature über das AWS Toolkit for Visual Studio Code. Anweisungen zur Einrichtung und allgemeinen Nutzung finden Sie unter Remote-Debugging von Lambda-Funktionen mit Visual Studio Code.

Ausführliche Anweisungen zur Fehlerbehebung, zu erweiterten Anwendungsfällen und zur regionalen Verfügbarkeit finden Sie unter Lambda-Funktionen per Fernzugriff im AWS Toolkit for Visual Studio Code Benutzerhandbuch.

Lambda: Die Ausführung dauert zu lange

Problem: Die Ausführung der Funktion dauert zu lange.

Wenn die Ausführung Ihres Codes in Lambda viel länger dauert als auf Ihrem lokalen Computer, kann er durch den der Funktion zur Verfügung stehenden Speicher oder die Rechenleistung eingeschränkt sein. Konfigurieren Sie die Funktion mit zusätzlichem Arbeitsspeicher, um sowohl Arbeitsspeicher als auch CPU zu erhöhen.

Lamda: Unerwartete Ereignis-Nutzdaten

Problem: Funktionsfehler im Zusammenhang mit fehlerhaftem JSON oder unzureichender Datenvalidierung

Alle Lambda-Funktionen erhalten eine Ereignis-Nutzdaten im ersten Parameter des Handlers. Die Ereignis- Nutzdaten sind eine JSON-Struktur, die Arrays und verschachtelte Elemente enthalten kann.

Missgebildetes JSON kann auftreten, wenn es von vorgelagerten Diensten bereitgestellt wird, die kein robustes Verfahren zur Überprüfung von JSON-Strukturen verwenden. Dies tritt auf, wenn Dienste Textzeichenfolgen miteinander verknüpfen oder Benutzereingaben einbetten, die nicht bereinigt wurden. JSON wird auch häufig für die Weitergabe zwischen Diensten serialisiert. Analysieren Sie JSON-Strukturen immer sowohl als Produzent als auch als Nutzer von JSON, um sicherzustellen, dass die Struktur gültig ist.

Ebenso kann es zu Fehlern kommen, wenn nicht auf Wertebereiche in den Ereignis-Nutzdaten geprüft wird. Eine Funktion, die an den Wert des Handlers übergeben wird:

exports.handler = async (event) => {
    let pct = event.taxPct
    let salary = event.salary

    // Calculate % of paycheck for taxes
    return (salary * pct)
}

Diese Funktion verwendet ein Gehalt und einen Steuersatz aus den Ereignis-Nutzdaten, um die Berechnung durchzuführen. Der Code überprüft jedoch nicht, ob die Attribute vorhanden sind. Außerdem werden Datentypen nicht überprüft oder Grenzen nicht gewährleistet, z. B. die Sicherstellung, dass der Steuersatz zwischen 0 und 1 liegt. Daher führen Werte außerhalb dieser Grenzen zu unsinnigen Ergebnissen. Ein falscher Typ oder ein fehlendes Attribut führt zu einem Laufzeitfehler.

Erstellen Sie Tests, um sicherzustellen, dass Ihre Funktion größere Nutzdaten verarbeitet. Die maximale Größe für eine Lambda-Ereignis-Nutzlast beträgt 1 MB. Je nach Inhalt können größere Nutzdaten bedeuten, dass mehr Elemente an die Funktion übergeben werden oder dass mehr Binärdaten in ein JSON-Attribut eingebettet sind. In beiden Fällen kann dies zu mehr Verarbeitung für eine Lambda-Funktion führen.

Größere Nutzdaten können auch zu Timeouts führen. Eine Lambda-Funktion verarbeitet beispielsweise einen Datensatz pro 100 ms und hat ein Timeout von 3 Sekunden. Die Verarbeitung ist für 0-29 Elemente in den Nutzdaten erfolgreich. Sobald die Nutzdaten jedoch mehr als 30 Elemente enthalten, bricht die Funktion ab und gibt einen Fehler aus. Um dies zu vermeiden, stellen Sie sicher, dass die Timeouts so eingestellt sind, dass sie die zusätzliche Verarbeitungszeit für die maximale Anzahl erwarteter Elemente berücksichtigen.

Lambda: Unerwartet große Nutzdaten

Problem: Funktionen verursachen Timeouts und Fehler aufgrund großer Nutzdaten

Größere Nutzdaten können zu Timeouts und Fehlern führen. Wir empfehlen, Tests zu erstellen, um sicherzustellen, dass Ihre Funktion die größten zu erwartenden Nutzdaten verarbeiten kann, und zu prüfen, ob das Zeitlimit für die Funktion richtig eingestellt ist.

Darüber hinaus können bestimmte Ereignis-Nutzdaten Verweise auf andere Ressourcen enthalten. Beispielsweise kann eine Lambda-Funktion mit 128 MB Speicher eine Bildverarbeitung für eine JPG-Datei durchführen, die als Objekt in S3 gespeichert ist. Die Funktion funktioniert erwartungsgemäß mit kleineren Bilddateien. Wenn jedoch eine größere JPG-Datei als Eingabe bereitgestellt wird, gibt die Lambda-Funktion einen Fehler aus, da nicht genügend Speicherplatz zur Verfügung steht. Um dies zu vermeiden, sollten die Testfälle Beispiele aus dem oberen Bereich der erwarteten Datengrößen enthalten. Der Code sollte auch die Nutzdatengröße validieren.

Lambda: Fehler beim Kodieren und Dekodieren von JSON

Problem: NoSuchKey Ausnahme beim Parsen von JSON-Eingaben.

Stellen Sie sicher, dass Sie JSON-Attribute korrekt verarbeiten. Für Ereignisse, die von S3 generiert wurden, enthält das Attribut s3.object.key beispielsweise einen URL-codierten Objektschlüsselnamen. Viele Funktionen verarbeiten dieses Attribut als Text, um das referenzierte S3-Objekt zu laden:

const originalText = await s3.getObject({
  Bucket: event.Records[0].s3.bucket.name,
  Key: event.Records[0].s3.object.key
}).promise()

Dieser Code funktioniert mit dem Schlüsselnamen james.jpg, löst aber einen NoSuchKey-Fehler aus, wenn der Name james beswick.jpg lautet. Da die URL-Kodierung Leerzeichen und andere Zeichen in einem Schlüsselnamen konvertiert, müssen Sie sicherstellen, dass Funktionen Schlüssel dekodieren, bevor Sie diese Daten verwenden:

const originalText = await s3.getObject({
  Bucket: event.Records[0].s3.bucket.name,
  Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "))
}).promise()

Lambda: Protokolle oder Ablaufverfolgungen erscheinen nicht

Problem: Protokolle werden nicht in CloudWatch Logs angezeigt.

Problem: Spuren werden nicht in angezeigt AWS X-Ray.

Ihre Funktion benötigt die Erlaubnis, CloudWatch Logs und X-Ray aufzurufen. Aktualisieren Sie die Ausführungsrolle, um ihr die Berechtigung zu erteilen. Fügen Sie die folgenden verwalteten Richtlinien hinzu, um Protokolle und Ablaufverfolgung zu aktivieren.

Wenn Sie Ihrer Funktion Berechtigungen hinzufügen, führen Sie auch eine triviale Aktualisierung ihres Codes oder ihrer Konfiguration durch. Dies zwingt ausgeführte Instances Ihrer Funktion, die veraltete Anmeldeinformationen haben, anzuhalten und ersetzt zu werden.

Lambda: Nicht alle Protokolle meiner Funktion werden angezeigt

Problem: Funktionsprotokolle fehlen in CloudWatch Logs, obwohl meine Berechtigungen korrekt sind

Wenn Ihr System die Kontingentgrenzen für CloudWatch Logs AWS-Konto erreicht, wird die Funktionsprotokollierung CloudWatch gedrosselt. In diesem Fall werden einige der von Ihren Funktionen ausgegebenen Protokolle möglicherweise nicht in CloudWatch den Protokollen angezeigt.

Wenn Ihre Funktion Logs mit einer zu hohen Rate ausgibt, als dass Lambda sie verarbeiten könnte, kann dies auch dazu führen, dass Protokollausgaben nicht in CloudWatch Logs erscheinen. Wenn Lambda Protokolle nicht mit der Geschwindigkeit senden kann, CloudWatch an die Ihre Funktion sie generiert, werden Protokolle gelöscht, um zu verhindern, dass die Ausführung Ihrer Funktion verlangsamt wird. Gehen Sie davon aus, dass gelöschte Protokolle konsistent beobachtet werden, wenn Ihr Protokolldurchsatz MB/s für einen einzelnen Protokollstream 2 überschreitet.

Wenn Ihre Funktion für die Verwendung von Protokollen im JSON-Format konfiguriert ist, versucht Lambda, beim Löschen von Protokollen ein logsDroppedEreignis an CloudWatch Logs zu senden. Wenn jedoch die Protokollierung Ihrer Funktion CloudWatch gedrosselt wird, erreicht dieses Ereignis möglicherweise nicht CloudWatch Logs, sodass Sie nicht immer einen Datensatz sehen, wenn Lambda Logs löscht.

Gehen Sie wie folgt vor, um zu überprüfen, ob Ihr System die Kontingentgrenzen für CloudWatch Logs erreicht AWS-Konto hat:

Sie können auch CloudWatch Alarme einrichten, die Sie benachrichtigen, wenn Ihre Kontoauslastung ein von Ihnen für diese Kontingente festgelegtes Limit überschreitet. Weitere Informationen finden Sie unter Einen CloudWatch Alarm auf der Grundlage eines statischen Schwellenwerts erstellen.

Wenn die standardmäßigen Kontingentgrenzen für CloudWatch Logs für Ihren Anwendungsfall nicht ausreichen, können Sie eine Erhöhung des Kontingents beantragen.

Lambda: Die Funktion kehrt zurück, bevor die Ausführung beendet ist

Problem: (Node.js) Rückgabe der Funktion erfolgt, bevor Code ausgeführt wird

Viele Bibliotheken, einschließlich des AWS SDK, arbeiten asynchron. Wenn Sie einen Netzwerkaufruf tätigen oder einen anderen Vorgang ausführen, für den auf eine Antwort gewartet werden muss, geben Bibliotheken ein Objekt zurück, das als Zusage bezeichnet wird und mit dem der Status der Operation im Hintergrund nachverfolgt wird.

Um zu warten, bis die Zusage in eine Antwort aufgelöst wird, verwenden Sie das Schlüsselwort await. Dadurch wird verhindert, dass der Handler-Code ausgeführt wird, bis die Zusage in ein Objekt aufgelöst wird, das die Antwort enthält. Wenn Sie die Daten aus der Antwort in Ihrem Code nicht verwenden müssen, können Sie die Zusage direkt an die Laufzeit zurückgeben.

Einige Bibliotheken geben keine Zusagen zurück, können aber in Code verpackt werden, der dies tut. Weitere Informationen finden Sie unter Lambda-Funktionshandler in Node.js definieren.

Lamda: Ausführen einer unbeabsichtigten Funktionsversion oder eines Alias

Problem: Funktionsversion oder Alias wurde nicht aufgerufen

Wenn Sie neue Lambda-Funktionen in der Konsole veröffentlichen oder verwenden AWS SAM, wird die neueste Codeversion durch $LATEST dargestellt. Standardmäßig zielen Aufrufe, die keine Version oder keinen Alias angeben, automatisch auf die $LATEST-Version Ihres Funktionscodes ab.

Wenn Sie bestimmte Funktionsversionen oder Aliase verwenden, handelt es sich dabei um unveränderliche veröffentlichte Versionen einer Funktion zusätzlich zu $LATEST. Stellen Sie bei der Problembehebung dieser Funktionen zunächst fest, ob der Aufrufer die beabsichtigte Version oder den Alias aufgerufen hat. Überprüfen Sie dazu Ihre Funktionsprotokolle. Die Version der aufgerufenen Funktion wird immer in der START-Protokollzeile angezeigt:

Lambda: Erkennen von Endlosschleifen

Problem: Endlosschleifenmuster im Zusammenhang mit Lambda-Funktionen

Es gibt zwei Arten von Endlosschleifen in Lambda-Funktionen. Die erste befindet sich innerhalb der Funktion selbst und wird durch eine Schleife verursacht, die niemals beendet wird. Der Aufruf endet erst, wenn die Funktion ein Timeout verursacht. Sie können diese identifizieren, indem Sie Timeouts überwachen und dann das Schleifenverhalten beheben.

Die zweite Art von Schleife besteht zwischen Lambda-Funktionen und anderen AWS Ressourcen. Diese treten auf, wenn ein Ereignis aus einer Ressource wie einem S3-Bucket eine Lambda-Funktion aufruft, die dann mit derselben Quellressource interagiert, um ein weiteres Ereignis auszulösen. Dadurch wird die Funktion erneut aufgerufen, wodurch eine weitere Interaktion mit demselben S3-Bucket erstellt wird, und so weiter. Diese Arten von Schleifen können durch eine Reihe verschiedener AWS Ereignisquellen verursacht werden, darunter Amazon SQS SQS-Warteschlangen und DynamoDB-Tabellen. Sie können diese Muster mithilfe der rekursiven Schleifenerkennung identifizieren.

Sie können diese Schleifen vermeiden, indem Sie sicherstellen, dass Lambda-Funktionen in Ressourcen schreiben, die nicht mit der verbrauchenden Ressource identisch sind. Wenn Sie Daten wieder auf der verbrauchenden Ressource veröffentlichen müssen, stellen Sie sicher, dass die neuen Daten nicht dasselbe Ereignis auslösen. Verwenden Sie alternativ die Ereignisfilterung. Hier sind beispielsweise zwei Lösungsvorschläge für Endlosschleifen mit S3- und DynamoDB-Ressourcen:

Allgemein: Nichtverfügbarkeit nachgelagerter Dienste

Problem: Die nachgelagerten Dienste, auf die Ihre Lambda-Funktion angewiesen ist, sind nicht verfügbar

Stellen Sie bei Lambda-Funktionen, die Drittanbieter-Endpunkte oder andere nachgelagerte Ressourcen aufrufen, sicher, dass sie Servicefehler und Timeouts behandeln können. Diese nachgelagerten Ressourcen können unterschiedliche Reaktionszeiten haben oder aufgrund von Serviceunterbrechungen nicht verfügbar sein. Je nach Implementierung können diese nachgelagerten Fehler als Lambda-Timeouts oder Ausnahmen erscheinen, wenn die Fehlerantwort des Dienstes nicht im Code der Funktion behandelt wird.

Implementieren Sie eine geeignete Fehlerbehandlung und Wiederholungslogik, wenn eine Funktion von einem nachgelagerten Dienst abhängt, z. B. von einem API-Aufruf. Für kritische Dienste sollte die Lambda-Funktion Metriken oder Protokolle veröffentlichen. CloudWatch Wenn beispielsweise eine Zahlungs-API eines Drittanbieters nicht mehr verfügbar ist, kann die Lambda-Funktion diese Informationen protokollieren. Sie können dann CloudWatch Alarme einrichten, um Benachrichtigungen zu diesen Fehlern zu senden.

Da Lambda schnell skalieren kann, können nachgelagerte Dienste, die nicht Serverless sind, Schwierigkeiten haben, Datenverkehrsspitzen zu bewältigen. Es gibt drei gängige Ansätze, um damit umzugehen:

AWS SDK: Versionen und Updates

Problem: Das in der Runtime enthaltene AWS SDK ist nicht die neueste Version

Problem: Das in der Runtime enthaltene AWS SDK wird automatisch aktualisiert

Zu den Laufzeiten für interpretierte Sprachen gehört eine Version des AWS SDK. Lambda aktualisiert diese Laufzeiten regelmäßig, um die neueste SDK-Version zu verwenden. Die in Ihrer Laufzeit enthaltene SDK-Version finden Sie in den folgenden Abschnitten:

Um eine neuere Version des AWS SDK zu verwenden oder Ihre Funktionen an eine bestimmte Version zu binden, können Sie die Bibliothek mit Ihrem Funktionscode bündeln oder eine Lambda-Schicht erstellen. Weitere Informationen zum Erstellen eines Bereitstellungspakets mit Abhängigkeiten finden Sie in den folgenden Themen:

Python: Bibliotheken werden falsch geladen

Problem: (Python) Einige Bibliotheken werden nicht korrekt aus dem Bereitstellungspaket geladen

Bibliotheken mit Erweiterungsmodulen, die in C oder C ++ geschrieben sind, müssen in einer Umgebung mit derselben Prozessorarchitektur wie Lambda (Amazon Linux) kompiliert werden. Weitere Informationen finden Sie unter Arbeiten mit ZIP-Dateiarchiven und Python-Lambda-Funktionen.

Java: Ihre Funktion braucht länger, um Ereignisse zu verarbeiten, nachdem sie von Java 11 auf Java 17 aktualisiert wurde

Problem: (Java) Ihre Funktion braucht länger, um Ereignisse zu verarbeiten, nachdem sie von Java 11 auf Java 17 aktualisiert wurde

Optimieren Sie Ihren Compiler mithilfe des JAVA_TOOL_OPTIONS-Parameters. Lambda-Laufzeiten für Java 17 und spätere Java-Versionen ändern die Standard-Compileroptionen. Die Änderung verbessert die Kaltstartzeiten für kurzlebige Funktionen, aber das bisherige Verhalten ist besser für rechenintensive, länger laufende Funktionen geeignet. Setzen Sie JAVA_TOOL_OPTIONS auf -XX:-TieredCompilation, um zum Verhalten von Java 11 zurückzukehren. Weitere Informationen zum Parameter JAVA_TOOL_OPTIONS erhalten Sie unter Die JAVA_TOOL_OPTIONS-Umgebungsvariable verstehen.

Kafka: Probleme bei der Fehlerbehandlung und beim erneuten Versuch der Konfiguration

Problem: Bei der Zuordnung von Kafka-Ereignisquellen können Einstellungen für Wiederholungsversuche oder Ziele für den Fall eines Fehlers nicht konfiguriert werden

Kafka-Wiederholungskonfigurationen und Ziele für den Fall eines Fehlers sind nur für Zuordnungen von Ereignisquellen verfügbar, bei denen der Bereitstellungsmodus aktiviert ist. Stellen Sie sicher, dass Sie Ihre Konfiguration vorgenommen haben, ProvisionedPollerConfig bevor Sie versuchen, MinimumPollers Wiederholungskonfigurationen festzulegen.

Häufige Konfigurationsfehler: