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.
# AWS Lambda Debuggen aus der Ferne
Der AWS Toolkit for Visual Studio Code ermöglicht es Ihnen, Ihre AWS Lambda Funktionen, die in der Cloud ausgeführt werden, direkt in VS Code zu debuggen. Mit dem AWS Lambda Remote-Debugging können Sie laufende Funktionen überprüfen, Breakpoints setzen, Variablen untersuchen und das Debuggen Schritt für Schritt durchführen, ohne den bestehenden Entwicklungsablauf zu ändern.
In den folgenden Abschnitten wird beschrieben, wie Sie mit Lambda-Remote-Debugging in der arbeiten. AWS Toolkit for Visual Studio Code
## So funktioniert Lambda-Remote-Debugging
Das AWS Toolkit ermöglicht das Remote-Debugging, indem es Ihre Lambda-Funktionen vorübergehend mit einer zusätzlichen Lambda-Debugging-Schicht modifiziert und das Timeout-Limit für Lambda-Aufrufe auf 900 Sekunden verlängert. Mithilfe von Secure Tunneling wird eine sichere Verbindung zwischen Ihrem lokalen Debugger und der Lambda-Laufzeitumgebung hergestellt AWS IoT . Diese Verbindung ermöglicht es Ihnen, Ihre lokalen Code-Breakpoints zu verwenden, um die Funktion bei der Remoteausführung Schritt für Schritt zu durchlaufen. Nach Abschluss Ihrer Debugging-Sitzung werden alle temporären Änderungen automatisch auf ihre ursprünglichen Einstellungen zurückgesetzt.
## Erste Schritte
### Unterstützte Laufzeiten
Die folgenden Laufzeiten werden vom Lambda-Remote-Debugging unterstützt.
+ Python (Amazon Linux 2023)
+ Java
+ Typescript/JavaScript/Node.js (Amazon Linux 2023)
**Anmerkung**
Von Lambda verwaltete Instanzen und OCI-Image-Funktionstypen werden vom Lambda-Remote-Debugging nicht unterstützt.
### Voraussetzungen
Bevor Sie beginnen, müssen die folgenden Voraussetzungen erfüllt sein.
+ Sie müssen gültige AWS Anmeldeinformationen im AWS Toolkit konfiguriert haben. Weitere Informationen zur Installation des AWS Toolkits und zur Konfiguration Ihrer Anmeldeinformationen finden Sie im Thema [Erste Schritte](https://docs.aws.amazon.com//toolkit-for-vscode/latest/userguide/setting-up.html) in diesem Benutzerhandbuch.
+ Eine Lambda-Funktion wurde für Ihr AWS Konto bereitgestellt. Einzelheiten zur Bereitstellung einer Lambda-Funktion finden Sie im Thema [Erstellen Sie Ihre erste Lambda-Funktion](https://docs.aws.amazon.com//lambda/latest/dg/getting-started.html) im *AWS Lambda*Entwicklerhandbuch.
+ Sie benötigen die entsprechenden AWS Identity and Access Management (IAM-) Richtlinien und Berechtigungen, um Ihre Funktion debuggen zu können. Weitere Informationen zu Lambda-Berechtigungen finden Sie im AWS Lambda Thema [AWS verwaltete Richtlinien](https://docs.aws.amazon.com//lambda/latest/dg/security-iam-awsmanpol.html) im *AWS Lambda*Developer Guide. Im Folgenden finden Sie ein Beispiel für eine Richtlinie, die die Mindestberechtigungen für die Arbeit mit Lambda-Remote-Debugging im AWS Toolkit enthält.
**Anmerkung**
Das Remote-Debugging wird über Secure Tunneling aktiviert. AWS AWS IoT Dadurch kann Ihr lokaler Debugger eine sichere Verbindung zur Lambda-Laufzeitumgebung herstellen.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:ListFunctions",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetLayerVersion",
"lambda:UpdateFunctionConfiguration",
"lambda:InvokeFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"iot:OpenTunnel",
"iot:RotateTunnelAccessToken",
"iot:ListTunnels"
],
"Resource": "*"
}
]
}
```
## Zugreifen auf Lambda-Remote-Debugging
Es gibt zwei Hauptpfade für den Zugriff auf das Lambda-Remote-Debugging im AWS Toolkit: den AWS Explorer oder den Application Builder-Explorer. Vom AWS Explorer aus können Sie über Ihre Knoten auf das Lambda-Remote-Debugging zugreifen AWS Lambda . Über den Application Builder Explorer können Sie über Ihre lokalen AWS SAM Projekte auf das Lambda-Remote-Debugging zugreifen.
**Zugriff auf Lambda-Remote-Debugging vom Explorer aus AWS**
1. Öffnen Sie in VS Code die AWS Toolkit-Erweiterung.
1. Erweitern Sie im AWS Toolkit den AWS Explorer.
1. Erweitern Sie im Explorer den **Lambda-Knoten**.
1. Navigieren Sie zu der Funktion, die Sie debuggen möchten, und wählen Sie dann im Kontextmenü das Symbol **Invoke remote** aus, um den Konfigurationsbildschirm **Remote Invoke** zu öffnen.
**Zugriff auf Lambda-Remote-Debugging über den Application Builder Explorer.**
1. Öffnen Sie in VS Code die AWS Toolkit-Erweiterung.
1. Erweitern Sie im AWS Toolkit den Application Builder Explorer.
1. Erweitern Sie im Explorer das `AWS SAM` Projekt, das das Lambda-Projekt enthält, das Sie debuggen möchten.
1. Erweitern Sie die bereitgestellte `Lambda` Funktion, die Sie debuggen möchten.
1. Navigieren Sie zur Funkfernbedienung und wählen Sie dann im Kontextmenü das Symbol Aus der **Ferne aufrufen**, um den Konfigurationsbildschirm für **Fernzugriff** zu öffnen.
## Arbeiten mit Lambda-Remote-Debugging
In den folgenden Abschnitten wird beschrieben, wie Sie mit Lambda-Remote-Debugging in der arbeiten. AWS Toolkit for Visual Studio Code
**Anmerkung**
Lambda-Funktionen haben ein 5-Layer-Limit und ein kombiniertes Limit von 250 MB für Funktionscode und alle angehängten Schichten. Für die Ausführung von Lambda-Remote-Debugging ist mindestens eine freie Ebene erforderlich.
### Eine Debugging-Sitzung einrichten
Bevor Sie beginnen, konfigurieren Sie Ihre Debugging-Sitzung, indem Sie das folgende Verfahren ausführen.
1. Öffnen Sie das **Konfigurationsmenü Remote Invoke**, indem Sie die *im vorherigen Abschnitt beschriebenen Verfahren Accessing Lambda remote debugging from the AWS explorer* *oder Accessing Lambda remote debugging from the Application Builder explorer* abschließen.
1. Wählen Sie im **Konfigurationsmenü Remote Invoke** das Kontrollkästchen Remote **Debugging, um die Remote-Debugging-Eigenschaften** anzuzeigen.
1. Geben Sie den **lokalen Root-Pfad** zu Ihrer lokalen Handler-Datei an.
**Anmerkung**
Der lokale Root-Pfad ist der Speicherort Ihres Quellcodes, der der bereitgestellten Lambda-Funktion entspricht. Wenn Sie mit einer bereitgestellten Funktion im Application Builder Explorer arbeiten, wird Ihr lokaler Stammpfad automatisch erkannt.
Wenn Sie den Quellcode nicht lokal gespeichert haben, wählen Sie die Schaltfläche **Remotecode herunterladen**, um den Quellcode Ihrer Lambda-Funktion abzurufen. Dadurch wird Ihr `handler file` VS-Code-Editor geöffnet.
1. Geben Sie im Abschnitt **Payload** an, wo Ihre Testereignisdaten abgerufen werden.
### Breakpoints setzen und debuggen
Legen Sie Haltepunkte fest und beginnen Sie mit dem Debuggen, indem Sie das folgende Verfahren ausführen.
1. Klicken Sie `handler file` im VS Code-Editor auf den Seitenrand, um Haltepunkte an den Zeilennummern zu setzen, in denen Sie das Debuggen unterbrechen möchten.
1. **Wenn Sie mit den Breakpoints zufrieden sind, kehren Sie zum **Konfigurationsmenü Remote Invake zurück, um zu überprüfen, ob Ihre Einstellungen korrekt konfiguriert sind, und wählen Sie dann die Schaltfläche Remote Invoke**, um mit dem Debuggen zu beginnen.**
1. Das AWS Toolkit aktualisiert Ihre Lambda-Funktion mit Debugging-Funktionen, richtet einen sicheren Tunnel für die Debugging-Sitzung ein, ruft Ihre Funktion mit der angegebenen Payload auf und unterbricht dann den Prozess, wenn er einen Breakpoint erreicht.
1. ******Verwenden Sie bei einer Pause am Breakpoint den Bereich **AUSFÜHREN UND DEBUGGEN, um Ihre VARIABLEN, CALL STACK und** BREAKPOINTS anzuzeigen.******
### Ihre Funktion aktualisieren und testen
Gehen Sie wie folgt vor, um Ihren Code zu ändern und Änderungen mit einer schnellen Bereitstellung zu testen.
1. Wenn Ihre Debugging-Sitzung aktiv ist, nehmen Sie `handler file` im VS Code-Editor Änderungen an Ihrer vor.
1. Speichern Sie Ihre Änderungen (**Command\$1S on macOS**,**Ctrl\$1S on Windows**)
1. Wenn Sie dazu aufgefordert werden, bestätigen Sie, dass Sie mit der Implementierung Ihrer Änderungen fortfahren möchten. Das AWS Toolkit aktualisiert Ihre Lambda-Funktion mit dem geänderten Code.
1. Fahren Sie mit dem Debuggen und Testen Ihrer Änderungen fort, indem Sie neue Breakpoints setzen und erneut auf die Schaltfläche **Remote** Invoke klicken.
**Anmerkung**
Alternativ können Sie die Option **Debugger anhängen** in den VS Code-Debugging-Steuerelementen deaktivieren und die Schaltfläche **Fernaufruf wählen, um Ihre Funktion ohne Debuggen auszuführen**.
### Beenden einer Debugging-Sitzung
Jede der folgenden Optionen beendet Ihre Remote-Debugging-Sitzung und entfernt die Debug-Ebene aus Ihrem Projekt.
+ Wählen **Sie im Konfigurationsbildschirm für den **Remote-Aufruf** die Option Debug-Setup entfernen**.
+ Wählen Sie das Symbol zum **Trennen der Verbindung** aus den VS Code-Debugging-Steuerelementen.
+ Schließen von `handler file` im VS Code-Editor.
**Anmerkung**
Beachten Sie die folgenden Punkte:
Die Lambda-Debug-Schicht wird nach 60 Sekunden Inaktivität automatisch entfernt. Die Zählung beginnt, wenn Ihr letzter Aufruf abgeschlossen ist.
Wenn Sie während des Debugging-Vorgangs Codeänderungen an Ihren infrastructure-as-code (IaC) verwalteten (AWS SAM AWS CDK,, Terraform) Funktionen vorgenommen haben, speichern Sie diese in Ihrem lokalen Projekt und erwägen Sie, Ihr Quellcodeverwaltungs-Repository zu aktualisieren. Nicht gespeicherte Änderungen werden überschrieben, wenn Ihre IaC-Funktion erneut bereitgestellt wird.
Wenn Sie temporäre Änderungen nur zu Debugging-Zwecken vorgenommen haben, sollten Sie Ihre Funktion möglicherweise über Ihre Quellcodeverwaltung erneut bereitstellen, um sicherzustellen, dass sie mit Ihrem Produktionscode übereinstimmt.
### Debuggen von TypeScript Lambda-Funktionen mit Quellzuordnungen
In den folgenden Abschnitten wird beschrieben, wie Sie Ihre TypeScript Lambda-Funktionen mit Quellzuordnungen debuggen.
#### Voraussetzungen
Um Ihre TypeScript Lambda-Funktionen zu debuggen, müssen die folgenden Voraussetzungen erfüllt sein.
+ Sie TypeScript müssen mit aktivierter Quellzuordnungsoption kompiliert worden sein. Weitere Informationen finden Sie im Thema zur [JavaScript Quellzuordnungsunterstützung](https://code.visualstudio.com/docs/typescript/typescript-debugging#_javascript-source-map-support) in der VS Code-Dokumentation.
+ Inline-Quellzuordnungen werden nicht unterstützt. Sie müssen eine separate `.js.map` Datei verwenden, um die Quellzuordnung zu speichern.
#### Konfiguration
Gehen Sie wie folgt vor, um das Lambda-Remote-Debugging für TypeScript Lambda-Funktionen im AWS Toolkit zu konfigurieren.
1. Erweitern Sie im AWS Toolkit den Explorer. AWS
1. Erweitern Sie im Explorer den **Lambda-Knoten**.
1. Navigieren Sie zu der Funktion TypeScript, für die Sie konfigurieren möchten, und wählen Sie dann das Symbol „Aus der **Ferne aufrufen**“ aus dem Kontextmenü, um den Konfigurationsbildschirm für **Fernzugriff** zu öffnen.
1. Aktivieren Sie das Remote-Debugging, indem Sie das Kontrollkästchen **Remote-Debugging aktivieren**.
1. Konfigurieren Sie Ihren **lokalen Root-Pfad**, indem Sie auf das Verzeichnis verweisen, das Ihren enthält. `TypeScript handler file`
**Anmerkung**
`TypeScript handler file`Hier legen Sie Ihre Debugging-Haltepunkte fest.
1. Erweitern Sie **Remote Debug — Zusätzliche Konfigurationseinstellungen**.
1. Aktivieren Sie die Quellenzuordnung, indem Sie das Kontrollkästchen **Quellenzuordnung** aktivieren.
1. Setzen Sie das Feld **Out-Dateien** auf das lokale Verzeichnis Ihrer Lambda-Funktionskopie.
**Example**
Wenn `app.js` und drin `app.map` sind`.aws-sam/build/HelloWorldFunction`, legen Sie den Speicherort `/Users/user/project/aws-sam/build/HelloWorldFunction/*` für die **Out-Dateien fest**.
**Anmerkung**
Der **Out-Dateipfad** sollte ein absoluter Pfad sein.
Für AWS CDK Projekte AWS SAM und Projekte unterstützt das AWS Toolkit die automatische Erkennung von Quellzuordnungen. Wenn das Feld **Out-Dateien** für diese Projekte leer gelassen wird, versucht das Toolkit automatisch, den Speicherort der Quellmap zu ermitteln.
1. Wenn Sie mit den Einstellungen zufrieden sind, klicken Sie auf die Schaltfläche **Fernzugriff, um mit** dem Debuggen Ihrer Funktion zu beginnen. TypeScript
## Problembehebung und erweiterte Anwendungsfälle
Wenn Ihre Debug-Sitzung fehlschlägt, starten Sie den Fehlerbehebungsprozess, indem Sie diese Schritte ausführen.
1. Aktualisieren Sie das AWS Toolkit auf die neueste Version.
1. Aktualisieren Sie die Webansicht, indem Sie die Webansicht für die **Konfiguration des Remote-Aufrufs** schließen und erneut öffnen.
1. Starten Sie VS Code neu, indem Sie es vollständig schließen und erneut öffnen.
1. Öffnen Sie die VS Code-Befehlspalette und geben Sie den Befehl ein. Wählen Sie ihn aus**AWS: Reset Lambda Remote Debugging Snapshot**, wenn er in den Ergebnissen angezeigt wird, um Ihren Lambda-Remote-Debugging-Snapshot zurückzusetzen.
1. [Wenn Sie das Problem nicht beheben können, reichen Sie ein Problem an Issues ein.AWS Toolkit for Visual Studio Code GitHub](https://github.com/aws/aws-toolkit-vscode/issues)
### Anwendungsfall für Fortgeschrittene: Konfiguration der Codesignatur
Das Remote-Debugging erfordert das Anhängen einer Debug-Ebene an Ihre Lambda-Funktion. Wenn für Ihre Funktion die Codesignaturkonfiguration aktiviert und durchgesetzt wurde, kann das AWS Toolkit die Debug-Ebene nicht automatisch an Ihre Funktion anhängen.
Es gibt zwei Optionen, um das Problem mit der Konfiguration der Codesignatur zu lösen.
+ Entfernen Sie vorübergehend die Codesignatur.
+ Verwenden Sie eine signierte Debug-Ebene.
#### Codesignatur vorübergehend entfernen
Aktualisieren Sie die Codesignaturkonfiguration anhand einer Einstellung und aktivieren Sie sie dann wieder`UntrustedArtifactOnDeployment : Warn`, wenn der Debugging-Vorgang `Enforced` abgeschlossen ist.
*Weitere Informationen finden Sie in der [UpdateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_UpdateCodeSigningConfig.html)Referenz in der API-Referenz.AWS Lambda *
#### Verwenden einer signierten Debug-Ebene
1. Erweitern Sie im AWS Toolkit unter Lambda Remote Debugging den Abschnitt mit der zusätzlichen Konfiguration von **Remote Debug**.
1. Kopieren Sie im Abschnitt **Zusätzliche Konfiguration für Remote-Debug** Ihren Region-Layer-ARN aus dem Feld **Layer-Override**.
1. Verwenden Sie von der aus den folgenden Befehl AWS CLI, um die Layer-Version herunterzuladen`aws lambda get-layer-version-by-arn --arn layer-arn`, und ersetzen Sie *layer-arn* durch Ihren Layer-ARN. *Detaillierte Anweisungen zum Herunterladen der signierten Debug-Ebene finden Sie in der Referenz [get-layer-version-by-arn in der Befehlsreferenz](https://docs.aws.amazon.com/cli/latest/reference/lambda/get-layer-version-by-arn.html).AWS CLI *
1. Signieren Sie den Layer mit Ihrer Codesignatur-Konfiguration und veröffentlichen Sie ihn in Ihrem Konto. Anleitungen zum Signieren und Veröffentlichen finden Sie im Thema [Codesignatur für Ihre AWS SAM Anwendung einrichten](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/authoring-codesigning.html) im *AWS Serverless Application Model Entwicklerhandbuch*.
1. **Nachdem der Layer signiert und in Ihrem Konto veröffentlicht wurde, kehren Sie zum Abschnitt mit der **zusätzlichen Konfiguration für das Remote-Debuggen** von Lambda Remote Debugging zurück und geben Sie dann den neuen Layer-ARN in das Feld Layer-Override ein.** Wenn der Vorgang abgeschlossen ist, verwendet das Lambda-Remote-Debugging Ihre signierte Ebene anstelle der Standardebene.
### Erweiterter Anwendungsfall: Debugging-Funktionen mit SnapStart oder bereitgestellter Parallelität
Bei Lambda-Funktionen, die mit Parallelität konfiguriert SnapStart oder bereitgestellt wurden, dauert die Veröffentlichung einer neuen Version erheblich länger. Um Ihren Debugging-Workflow zu beschleunigen, können Sie Lambda Remote Debugging so konfigurieren, dass nur die `$LATEST` Version Ihrer Funktion aktualisiert wird, anstatt eine neue Version zu veröffentlichen.
1. Erweitern Sie auf dem Bildschirm mit der **Konfiguration von Remote Invoke** die zusätzlichen Konfigurationseinstellungen für **Remote-Debug**.
1. Deaktivieren Sie die Option Version **veröffentlichen**.
1. Das AWS Toolkit aktualisiert jetzt nur noch die `$LATEST` Version Ihrer Funktion und debuggt damit.
**Anmerkung**
Als Nebeneffekt des Debuggings mit der `$LATEST` Version sollten Sie anderen Datenverkehr vermeiden, der Ihre `$LATEST` Version aufrufen könnte, um eine ungestörte Debugging-Umgebung zu gewährleisten.
### Unterstützte -Regionen
Der folgende Fehler tritt auf, wenn eine Region das Remote-Debugging nicht unterstützt.
```
Region ${region} doesn't support remote debugging yet
```
Im Folgenden finden Sie eine Liste der unterstützten Regionen.
+ ap-east-1
+ ap-northeast-1
+ ap-northeast-2
+ ap-south-1
+ ap-southeast-1
+ ap-southeast-2
+ ca-central-1
+ eu-central-1
+ eu-north-1
+ eu-west-1
+ eu-west-2
+ eu-west-3
+ me-central-1
+ me-south-1
+ sa-east-1
+ us-east-1
+ us-east-2
+ us-west-1
+ us-west-2
### Lambda RequestEntityTooLargeException
Lambda-Funktionen haben ein 5-Layer-Limit und ein kombiniertes Limit von 250 MB für Funktionscode und alle angehängten Schichten. Die Remote-Debugging-Schicht ist ungefähr 40 MB groß, was dazu führen kann, dass Ihre Funktion diese Grenze überschreitet, wenn Sie über ein großes Funktionspaket oder mehrere Ebenen verfügen. Weitere Informationen finden Sie im RequestEntityTooLargeException Themenabschnitt [Lambda: InvalidParameterValueException oder](https://docs.aws.amazon.com//lambda/latest/dg/troubleshooting-deployment.html#troubleshooting-deployment-InvalidParameterValueException1) im *AWS Lambda Developer Guide*.
In der folgenden Liste werden Möglichkeiten zur Behebung und Korrektur dieses Fehlers beschrieben.
+ **Reduzieren Sie die Funktionsgröße**: Optimieren Sie Ihren Funktionscode und entfernen Sie unnötige Abhängigkeiten.
+ **Unbenutzte Ebenen entfernen**: Entfernen Sie beim Debuggen vorübergehend nicht benötigte Ebenen.
+ **Verwenden Sie externe Abhängigkeiten**: Verschieben Sie große Abhängigkeiten in externen Speicher wie Amazon S3 und laden Sie sie zur Laufzeit.
### Fehlerbehebung beim Java-Debugging
Um eine Java-Lambda-Funktion zu debuggen, muss dieselbe Java-Version lokal installiert sein, die der Laufzeitversion Ihrer Lambda-Funktion entspricht.
Wenn Sie beispielsweise eine Java 25-Funktion debuggen, müssen Sie Java 25 in Ihrer lokalen Umgebung installiert haben, in der das AWS Toolkit ausgeführt wird. Wenn Sie versuchen, eine Java 25-Funktion zu debuggen, während Java 21 oder eine frühere Version lokal installiert ist, kann das Remote-Debugging nicht an den von Ihnen festgelegten Breakpoints anhalten.
Stellen Sie sicher, dass Ihre lokale Java-Version mit der Laufzeitversion Ihrer Lambda-Funktion übereinstimmt, bevor Sie eine Debugging-Sitzung starten.
### Kontingent für sicheres IoT-Tunneling überschritten
Im Folgenden finden Sie ein Beispiel für den *Fehler „Tunnelkontingent überschritten*“, der auftritt, wenn Sie das Tageslimit für AWS IoT sichere Tunnelverbindungen beim Lambda-Remote-Debugging erreicht haben.
```
Error creating/reusing tunnel: LimitExceededException: Exceeded quota of Lambda debugging tunnels
```
AWS IoT Für Secure Tunneling-Verbindungen gelten die folgenden Kontingente:
+ Für sicheres IoT-Tunneling auf kostenloser Stufe sind 10 Verbindungen pro Tag vorgesehen.
+ Jeder Tunnel unterstützt eine VS Code-Instanz für bis zu 12 Stunden.
+ Das Kontingent gilt pro AWS Konto und Tag.
Wenn der AWS IoT Secure Tunneling-Fehler auftritt, warten Sie, bis das Kontingent täglich zurückgesetzt wird, oder wenden Sie sich an den AWS Support, um eine Erhöhung des Kontingentlimits zu beantragen. [Kontaktinformationen für den AWS Support finden Sie im Support-Kontaktportal.AWS](https://aws.amazon.com/contact-us/) *Ausführliche Informationen zu AWS IoT Secure Tunneling finden Sie unter dem Thema [AWS IoT Secure Tunneling](https://docs.aws.amazon.com/iot/latest/developerguide/secure-tunneling.html) im Developer Guide.AWS IoT *