Direkt zum Inhalt
Durch die Nutzung von AWS re:Post stimmt du den AWS re:Post Nutzungsbedingungen
AWS re:Postre:Post
Über re:Post

Wie behebe ich API-Gateway-Integrationsprobleme für Lambda-Funktionen?

Lesedauer: 9 Minute
0

Ich möchte Amazon-API-Gateway-Integrationsprobleme für AWS-Lambda-Funktionen beheben.

Lösung

API-Protokollierung aktivieren

Gehe wie folgt vor:

  1. Öffne die API-Gateway-Konsole.
  2. Wähle im Navigationsbereich APIs und dann deine API aus.
  3. Wähle im Navigationsbereich Stufen und dann deine Stufe aus.
  4. Wähle unter Protokolle und Ablaufverfolgung die Option Bearbeiten aus.
  5. Wähle unter CloudWatch-Protokolle eine Ebene aus der Dropdown-Liste aus.<br id=hardline_break/> Hinweis: Wähle für vollständige Anforderungs- und Antwortprotokolle die Option Ablaufverfolgung von Daten aus, wobei die Protokollierungsebene auf Fehler- und Informationsprotokolle eingestellt ist. Es hat sich bewährt, die Ablaufverfolgung von Daten für Produktions-APIs nicht zu aktivieren, da bei der Ablaufverfolgung von Daten sensible Daten protokolliert werden können.
  6. Wähle Detaillierte Metriken aus.
  7. Führe unter Benutzerdefinierte Zugriffsprotokollierung die folgenden Schritte aus:<br id=hardline_break/> Wähle Zugriffsprotokollierung aktivieren aus.<br id=hardline_break/> Gib für Ziel-ARN des Zugriffsprotokolls den ARN einer Amazon Data Firehose- oder CloudWatch-Protokollgruppe ein.<br id=hardline_break/> Hinweis: Nur REST-APIs unterstützen den Firehose-ARN.
  8. Gib ein Protokollformat ein.
  9. Wähle Speichern aus.

Integrationstypen ermitteln, Fehler überprüfen und die nächsten Schritte zur Behebung ergreifen

Gehe wie folgt vor:

  1. Stelle fest, ob eine Lambda-Proxy-Integration oder eine benutzerdefinierte Lambda-Integration in API Gateway eingerichtet ist. Um den Integrationstyp zu überprüfen, überprüfe den Wert der Lambda-Proxy-Integration unter Integrationsanfrage.

  2. Stelle sicher, dass die Fehler in API Gateway den Fehlern in Lambda entsprechen. Führe die folgende CloudWatch-Logs-Insights-Abfrage aus, um einen Fehlerstatuscode in einem bestimmten Zeitraum zu finden:

    parse @message '(*) *' as reqId, message
    | filter message like /Method completed with status: \d\d\d/
    | parse message 'Method completed with status: *' as status
    | filter status != 200
    | sort @timestamp asc
    | limit 50

  3. Führe die folgende CloudWatch-Logs-Insights-Abfrage aus, um im gleichen Zeitraum nach Lambda-Fehlerprotokollen zu suchen:

    fields @timestamp, @message
    | filter @message like /(?i)(Exception|error|fail)/
    | sort @timestamp desc
    | limit 20

  4. Wähle je nach Art des Fehlers, den du in den Protokollen identifizierst, eine der folgenden Optionen aus:<br id=hardline_break/> Wenn die folgende Fehlermeldung angezeigt wird, führe die Schritte im Abschnitt Beheben von Problemen mit der Parallelität aus.

    (#####) Lambda invocation failed with status: 429. Lambda request id: ##########
() Execution failed due to configuration error: Rate Exceeded.
(#####) Method completed with status: 500

    Wenn eine der folgenden Fehlermeldungen angezeigt wird, führe die Schritte im Abschnitt Beheben von Timeout-Problemen aus.<br id=hardline_break/> Bei einer benutzerdefinierte Lambda-Integration:

    < Integration timeout:
(#####) Method response body after transformations: {"errorMessage":"2019-08-14T02:45:14.133Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
> Integration timeout:
(#####) Execution failed due to a timeout error

    Bei einer Lambda-Proxy-Integration:

    < Integration timeout:
(#####) Endpoint response body before transformations: {"errorMessage":"2019-08-14T02:50:25.865Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
> Integration timeout:
(#####) Execution failed due to a timeout error

    Wenn die folgende Fehlermeldung angezeigt wird, führe die Schritte im Abschnitt Beheben von Funktionsfehlern aus.

    (#####) Execution failed due to configuration error: Malformed Lambda proxy response
(#####) Method response body after transformations: {"errorMessage": "Syntax error in module 'lambda_function'"}

Beheben von Problemen mit der Parallelität

Du erhältst den Drosselungsfehler 429 oder den Fehler 500, wenn zusätzliche Anfragen vom API Gateway schneller eingehen als die Lambda-Funktion skalieren kann.

Analysiere die folgenden CloudWatch-Metriken, um diese Fehler zu beheben: Count (Anzahl) (API Gateway), Throttles (Drosselungen) (Lambda) und ConcurrentExecutions (Gleichzeitige Ausführungen) (Lambda). Beachte Folgendes:

  • Count (Anzahl) (API Gateway) ist die Gesamtzahl der API-Anfragen in einem bestimmten Zeitraum.
  • Throttles (Drosselungen) (Lambda) sind die Anzahl der gedrosselten Aufrufanfragen. Wenn alle Funktions-Instances Anfragen verarbeiten und keine Parallelität zum Hochskalieren verfügbar ist, lehnt Lambda weitere Anfragen mit dem Fehler TooManyRequestsException ab. Gedrosselte Anfragen und andere Aufruffehler gelten nicht als Aufrufe oder Fehler.
  • ConcurrentExecutions (Gleichzeitige Ausführungen) (Lambda) ist die Anzahl der Funktions-Instances, die Ereignisse verarbeiten. Wenn diese Zahl dein Kontingent für gleichzeitige Ausführungen für die AWS-Region erreicht, werden zusätzliche Aufrufanfragen gedrosselt. Lambda drosselt ebenfalls Aufrufanfragen, wenn die Anzahl der Funktions-Instances die reservierte Parallelitätsgrenze erreicht, die du für die Funktion konfiguriert hast.

Hinweis: Weitere Informationen findest du unter API-Gateway-Metriken und CloudWatch-Metriken mit Lambda verwenden.

Wenn du eine Reserve-Parallelität für die Lambda-Funktion festlegst, erhöhe den Wert für die Reserve-Parallelität. Oder entferne den Wert für umgekehrte Parallelität aus der Lambda-Funktion. Die Funktion greift dann auf den Pool der nicht reservierten gleichzeitigen Ausführungen zurück.

Wenn du in der Lambda-Funktion die Reserve-Parallelität nicht festlegst, überprüfe die Verwendung der Metrik ConcurrentExecutions (Gleichzeitige Ausführungen). Weitere Informationen findest du unter Lambda-Kontingente.

Beheben von Timeout-Problemen

Der Standardgrenzwert für das Integrations-Timeout beträgt 29 Sekunden für alle API-Gateway-Integrationen. Du kannst eine Kontingentanforderung stellen, um das standardmäßige Kontingent des Grnzwerts für das Integrations-Timeout für regionale APIs und private APIs auf mehr als 29 Sekunden zu erhöhen. Eine Erhöhung des Integrations-Timeouts kann jedoch eine Reduzierung des Drosselkontingents auf Regionsebene für das AWS-Konto erforderlich machen.

Hinweis: Wenn du den Grenzwert für das Integrations-Timeout erhöhst, stelle sicher, dass du den Standard-Timeout-Wert von 29 Sekunden auf den neuen Wert änderst. Ändere beispielsweise den Standard-Timeout-Wert von 29 Sekunden in den Integrationen, auf die du die Erhöhung anwenden möchtest. Stelle dann die API erneut bereit, damit der neue Timeout-Grenzwert für die Integration wirksam wird.

Wenn du eine API-Gateway-API mit Lambda-Integration erstellst, tritt möglicherweise eines der folgenden Szenarien auf:

  • Der Timeout-Wert ist kleiner als der Integrations-Timeout-Wert.
  • Der Timeout-Wert ist größer als der Integrations-Timeout-Wert.

Wenn das Timeout deiner Lambda-Funktion weniger als 29 Sekunden beträgt, überprüfe die Lambda-Protokolle, um dieses Problem zu untersuchen. Wenn die Lambda-Funktion nach 29 Sekunden ausgeführt werden muss, rufe die Lambda-Funktion asynchron auf.

Führe für die benutzerdefinierte Integration mit asynchronen Aufrufen von Lambda die folgenden Schritte aus:

  1. Öffne die API-Gateway-Konsole.
  2. Wähle im Navigationsbereich APIs und dann die API aus.
  3. Wähle Ressourcen und dann deine Methode aus.
  4. Wähle Integrationsanfrage aus.
  5. Wähle Methodenanfrage aus.
  6. Erweitere HTTP-Anfrage-Header.
  7. Wähle Header hinzufügen.
  8. Gib unter Name einen Namen für den Header ein. Zum Beispiel: X-Amz-Aufruftyp<br id=hardline_break/> Wichtig: Du musst deinen Header von ‚Ereignis‘ zuordnen. Du musst einfache Anführungszeichen verwenden.

Verwende zwei Lambda-Funktionen für die Lambda-Proxy-Integration: Funktion A und Funktion B. API Gateway ruft Funktion A zunächst synchron auf. Dann ruft Funktion A asynchron Funktion B auf. Funktion A kann eine erfolgreiche Antwort an API Gateway zurückgeben, wenn Funktion B asynchron aufgerufen wird.

Wenn du eine Lambda-Proxy-Integration verwendest, kannst du die Integration in eine benutzerdefinierte Integration ändern. Um die Anfrage oder Antwort in dein spezifisches Format umzuwandeln, musst du jedoch die Zuweisungsvorlagen konfigurieren. Weitere Informationen findest du unter Einrichten des asynchronen Aufrufs der Backend-Lambda-Funktion.

Hinweis: Da eine asynchrone Lambda-Funktion im Hintergrund ausgeführt wird, kann dein Client keine Daten direkt von einer Lambda-Funktion empfangen. Du benötigst eine Zwischendatenbank, um persistente Daten zu speichern.

Beheben von Funktionsfehlern

Wenn du beim Aufrufen deiner API einen Funktionsfehler erhältst, überprüfe die Lambda-Funktion auf Syntaxfehler. Dieser Fehler tritt auch auf, wenn deine Lambda-Funktion kein gültiges JSON-Objekt zurückgibt, das API Gateway für Proxy-Integrationen erwartet.

In den API-Gateway-Ausführungsprotokollen kannst du den RequestID-Wert des AWS-Integrationsendpunkts in den Protokollen überprüfen:

(#####) AWS Integration Endpoint RequestId : YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY

Führe dann die folgende CloudWatch-Protokoll-Insights-Abfrage aus, um im gleichen Zeitraum nach Lambda-Fehlerprotokollen zu suchen:

fields @timestamp, @message, @requestId, @logStream
| filter @requestId = 'YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'
| sort @timestamp asc

Um diesen Fehler zu beheben, führe die Schritte im Abschnitt Aktivieren der Protokollierung für die API und Stufe durch.

Falsche Antworten auf den REST-API-Statuscode überschreiben

Wenn API Gateway einen falschen Statuscode zurückgibt, erstelle eine Zuweisungsvorlage, um den falschen Statuscode mit dem richtigen Statuscode zu überschreiben. Du kannst Statuscode-Antworten in Nicht-Proxy-Integrationen mit REST-APIs überschreiben.

Hinweis: Diese Konfiguration der Zuweisungsvorlage gilt nur für REST-APIs. Informationen zu HTTP-APIs findest du unter Wie ordne ich die Antwortstatuscodes für API-Gateway-Integrationen in HTTP-APIs zu?

Wenn API Gateway beispielsweise einen 200-Statuscode anstelle eines 4## oder 5## von einer Lambda-Funktion zurückgibt, führe die folgenden Schritte aus:

  1. Öffne die API-Gateway-Konsole und wähle im Navigationsbereich APIs aus.

  2. Wähle die REST-API und dann die Registerkarte Integrationsantwort.

  3. Wähle in den Einstellungen für Integrationsantworten die Option Bearbeiten aus.

  4. Erweitere Zuweisungsvorlagen und wähle dann Zuweisungsvorlage hinzufügen.

  5. Gib als Inhaltstyp application/json ein.

  6. Gib im Editor der Zuweisungsvorlagen den folgenden Code ein:

    #set($inputRoot = $input.path('$'))
$input.json("$")
#if($inputRoot.toString().contains("error"))
#set($context.responseOverride.status = 400)
#end

  7. Wähle Speichern aus.

Der Parameter $context.responseOverride.status überschreibt den Statuscode auf 400 statt auf die Standardzuweisung im Integrationsantwortbereich.

Weitere Informationen findest du unter Überschreiben der Anforderungs- und Antwortparameter und Statuscodes deiner API für REST-APIs in API Gateway.

REST-API-Integrationen für das Zurückgeben der erforderlichen CORS-Header konfigurieren

Konfiguriere die Lambda-Funktion im Backend oder den HTTP-Proxy-Server so, dass die erforderlichen CORS-Header in der Antwort gesendet werden. Zulässige Domains müssen als Liste im Header-Wert Access-Control-Allow-Origin enthalten sein.

Für Proxy-Integrationen kannst du in API Gateway keine Integrationsantwort einrichten, um die vom Backend der API zurückgegebenen Antwortparameter zu ändern. Bei einer Proxy-Integration leitet API Gateway die Backend-Antwort direkt an den Client weiter. Du musst die Lambda-Funktion oder HTTP-Integration so konfigurieren, dass die erforderlichen CORS-Header zurückgegeben werden.

Wenn du eine Nicht-Proxy-Integration verwendest, musst du manuell eine Integrationsantwort in API Gateway einrichten, um die erforderlichen CORS-Header zurückzugeben. Verwende die API-Gateway-Konsole, um CORS zu konfigurieren. Die Konsole fügt der konfigurierten Ressource automatisch die erforderlichen CORS-Header hinzu.

Weitere Informationen findest du unter Wie behebe ich CORS-Fehler über meine API-Gateway-API?

Lambda-Proxy-Integrationen mit binären Nutzdaten

Binäre Nutzdaten sind alle, die keine Text-Nutzdaten sind. Binäre Nutzdaten können beispielsweise JPEG-Dateien, GZIP-Dateien oder andere Dateien sein. Dies schließt generische Binärdaten ein, z. B. aus einer PDF-Anwendung, einem JPEG-Bild oder einer ZIP-Anwendung.

Um binäre Nutzdaten für Lambda-Proxy-Integrationen zu verarbeiten, musst du die Antwort der Funktion Base64-kodieren und die binaryMediaTypes für die API konfigurieren. Um binäre Nutzdaten für Nicht-Proxy-Integrationen zu verarbeiten, musst du die Medientypen zur binaryMediaType-Liste der RestApi-Ressource hinzufügen.

Weitere Informationen findest du unter Binäre Medientypen für REST-APIs in API Gateway.

Ähnliche Informationen

Behandeln von Standard-Lambda-Fehlern in API Gateway

Behandeln von benutzerdefinierten Lambda-Fehlern in API Gateway