Warum kann der Kinesis Data Streams-Trigger meine Lambda-Funktion nicht aufrufen?

Kurzbeschreibung

Lambda-Funktionsfehler werden häufig durch Folgendes verursacht:

• Unzureichende Berechtigungen in der Ausführungsrolle der Lambda-Funktion.
• Keine eingehenden Daten in den Kinesis-Datenstrom.
• Inaktive Ereignisquellenzuordnung, die durch die Neuerstellung eines Kinesis-Datenstroms, einer Lambda-Funktion oder einer Lambda-Ausführungsrolle verursacht wurde.
• Eine Lambda-Funktion, die die maximale Ausführungszeit überschreitet und dadurch einen Timeout-Fehler in der Lambda-Funktion verursacht.
• Lambda verstößt gegen seine Grenzen für gleichzeitige Ausführungen. Weitere Informationen darüber, wie Lambda seine Grenzwerte verletzt, finden Sie unter AWS Lambda-Grenzwerte.

Wenn ein Lambda-Funktionsfehler auftritt, wird Ihre Funktion nicht aufgerufen, und die Funktion verarbeitet auch keine Datensätze aus dem Stapel. Ein Fehler kann dazu führen, dass Lambda den Stapel von Datensätzen erneut versucht, bis die Verarbeitung erfolgreich ist oder der Stapel abläuft. Weitere Informationen zur Lambda-Funktion und zu Kinesis-Fehlern finden Sie unter Verwenden von AWS Lambda mit Amazon Kinesis.

Lösung

Fehlerbehebung bei Ihrer Lambda-Funktion

Gehen Sie wie folgt vor, um herauszufinden, warum Ihre Lambda-Funktion nicht aufgerufen wird:

1.    Überprüfen Sie die Metrik Aufrufe in Amazon CloudWatch, wobei die Statistik für die Lambda-Funktion auf Summe gesetzt ist. Mit der Metrik Aufrufe können Sie überprüfen, ob die Lambda-Funktion aufgerufen wurde.

2.    Überprüfen Sie die IteraTorage-Metrik, um zu sehen, wie alt der letzte Datensatz im Stapel war oder wann die Verarbeitung abgeschlossen wurde. Wenn Ihr Lambda-Consumer nicht aufrufen kann, erhöht sich das Iteratoralter Ihres Streams.

3.    Überprüfen Sie die CloudWatch-Logs der Lambda-Funktion. Diese sind benannt nach dem**... /aws/lambda/function\ _name-**Format. Suchen Sie nach entsprechenden Einträgen für den Funktionsfehler. Tritt der Fehler beispielsweise aufgrund der Ausführungsrollenberechtigungen von Lambda auf, ändern Sie die Rollenrichtlinie für AWS Identity and Access Management (IAM).

4.    Stellen Sie sicher, dass Ihre IAM-Ausführungsrolle über die richtigen Berechtigungen für den Zugriff auf CloudWatch verfügt:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

5.    (Optional) Wenn ein Berechtigungsfehler auftritt, aktualisieren Sie Ihre Lambda-Funktionsrichtlinie und gewähren Sie ihr Zugriff auf Kinesis Data Streams:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStream",
                "kinesis:DescribeStreamSummary",
                "kinesis:GetRecords",
                "kinesis:GetShardIterator",
                "kinesis:ListShards",
                "kinesis:ListStreams",
                "kinesis:SubscribeToShard",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Hinweis: Die AWSLambDakinesisExecutionRole-Richtlinie beinhaltet diese Berechtigungen.

Zusätzliche Problembehebung

• Wenn der Fehler mit einem Timeout der Lambda-Ausführungsfunktion zusammenhängt, erhöhen Sie den Timeout-Wert, um eine schnellere Verarbeitung zu ermöglichen.
• Wenn Ihr Kinesis-Datenstream mit dem AWS Key Management Service (AWS KMS) verschlüsselt ist, müssen der Verbraucher und der Produzent über den richtigen Zugriff verfügen. Der Kinesis-Datenstream muss auf die AWS KMS-Schlüssel zugreifen können, die für die Verschlüsselung und Entschlüsselung verwendet werden. Die Ausführungsrolle der Lambda-Funktion muss außerdem Lesezugriff auf den KMS-Schlüssel haben, um Daten aus dem Kinesis-Datenstream erfolgreich lesen zu können.
• Wenn der Fehler durch einen internen Lambda-Funktionsfehler verursacht wird, deutet dieser Fehler auf ein Problem mit der Stream-Verarbeitung hin. Um eine API-Drosselung auf der Steuerungsebene zu vermeiden, beschränken Sie jeden Stream auf 4 bis 5 Eventquellenzuordnungen.
• Wenn der Fehler durch einen internen Lambda-Funktionsfehler verursacht wird, deutet dieser Fehler auf ein Problem mit der Stream-Verarbeitung hin. Beschränken Sie jeden Stream auf 4 bis 5 Ereignisquellenzuordnungen, um zu viele Ereignisquellenzuordnungen mit demselben Datenstrom zu vermeiden. Zuordnungen mehrerer Ereignisquellen mit demselben Stream können zu einer Verletzung der Grenzwerte der Kinesis- und Amazon DynamoDB-Steuerungsebene führen.
• Wenn Sie einen Verbindungs-Timeout-Fehler erhalten, fügen Sie Protokollierungsanweisungen vor und nach den API-Aufrufen in Ihrem Code hinzu. Sie können dann die genaue Codezeile identifizieren, in der die Funktion zu versagen beginnt.
• Wenn Sie langsame oder ins Stocken geratene Shards feststellen, konfigurieren Sie die Eventquellenzuordnung so, dass es mit einer kleineren Batchgröße erneut versucht wird. Sie können auch die Anzahl der Wiederholungsversuche einschränken oder ältere Datensätze verwerfen.
• Wenn Sie in Ihren CloudWatch-Protokollen die Fehlermeldung „Speicher belegt“ sehen, erhöhen Sie den Speicher Ihrer Lambda-Funktion.
• Wenn Sie das maximale Timeout für Ihre Lambda-Funktion überschritten haben, ändern Sie die Client-Bibliothek und die Client-Timeouts. Verwenden Sie die Funktion context.getRemainingTimeInMillis, um die Timeout-Sitzung auf der Grundlage der verbleibenden Zeit im Lambda-Container zu ändern. Die Funktion context.getRemainingTimeInMillis gibt die verbleibende Zeit im Lambda-Container zurück, bevor ein Timeout eintritt.
• Wenn der Code der Lambda-Funktion Fehler enthält, kann es sein, dass Ihre Lambda-Funktion beim Versuch desselben Datensatzes hängen bleibt. Verwenden Sie einen Try-Catch-Block, um die ausgefallenen Daten abzufangen, und zeichnen Sie sie dann mithilfe einer Amazon SQS-Warteschlange oder eines Amazon SNS-Themas auf. Sie können der Amazon SQS-Warteschlange auch einen Lambda-Trigger mit der Verarbeitungslogik hinzufügen, um die fehlgeschlagenen Anfragen separat zu wiederholen.
• Richten Sie eine Amazon SQS-Dead-Letter-Queue (DLQ) ein, um die Lambda-Funktion manuell aufzurufen. Konfigurieren Sie die Eigenschaft DeadletterConfig, wenn Sie Ihre Lambda-Funktion erstellen oder aktualisieren. Sie können eine Amazon Simple Queue Service (Amazon SQS) -Warteschlange oder ein Amazon Simple Notification Service (Amazon SNS) -Thema als TargetARN für Ihre DLQ bereitstellen. Lambda schreibt dann das Ereignisobjekt und ruft die Lambda-Funktion auf dem angegebenen Endpunkt auf, nachdem die Standard-Wiederholungsrichtlinie ausgeschöpft ist.
• Verwenden Sie AWS Lambda mit AWS X-Ray, um Leistungsprobleme mit Lambda-Anwendungen zu erkennen, zu analysieren und zu optimieren. AWS X-Ray sammelt Metadaten aus dem Lambda-Service und generiert Diagramme, die Probleme darstellen, die sich auf die Leistung der Lambda-Anwendung auswirken. Wenn beispielsweise ein Anruf lange dauert, können Sie AWS X-Ray verwenden, um das Problem zu bestätigen.