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. # Senden von Lambda-Funktionsprotokollen an CloudWatch Logs Standardmäßig erfasst Lambda automatisch Protokolle für alle Funktionsaufrufe und sendet sie an CloudWatch Logs, sofern die Ausführungsrolle Ihrer Funktion über die notwendigen Berechtigungen verfügt. Diese Protokolle werden standardmäßig in einer Protokollgruppe mit dem Namen „/aws/lambda/*“* gespeichert. Um das Debugging zu verbessern, können Sie benutzerdefinierte Protokollierungsanweisungen in Ihren Code einfügen, die Lambda nahtlos in CloudWatch Logs integriert. Falls erforderlich, können Sie Ihre Funktion so konfigurieren, dass Protokolle an eine andere Gruppe gesendet werden. Sie können dazu die Lambda-Konsole, die AWS CLI oder die Lambda-API verwenden. Weitere Informationen hierzu finden Sie unter [Konfiguration von CloudWatch Protokollgruppen](monitoring-cloudwatchlogs-loggroups.md). Sie können Protokolle für Lambda-Funktionen mithilfe der Lambda-Konsole, der CloudWatch-Konsole, der AWS Command Line Interface (AWS CLI) oder der CloudWatch-API anzeigen. Weitere Informationen finden Sie unter [CloudWatch Logs für Lambda-Funktionen anzeigen](monitoring-cloudwatchlogs-view.md). **Anmerkung** Es kann 5 bis 10 Minuten dauern, bis Protokolle nach einem Funktionsaufruf angezeigt werden. ## Erforderliche IAM-Berechtigungen Ihre [Ausführungsrolle](lambda-intro-execution-role.md) benötigt die folgenden Berechtigungen, um Protokolle zu CloudWatch Logs hochzuladen: + `logs:CreateLogGroup` + `logs:CreateLogStream` + `logs:PutLogEvents` Weitere Informationen finden Sie unter [Verwendung von identitätsbasierten Richtlinien (IAM-Richtlinien) für CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html) im *Amazon CloudWatch User Guide*. Sie können diese CloudWatch-Logs-Berechtigungen mithilfe einer von Lambda bereitgestellten von `AWSLambdaBasicExecutionRole`AWS verwalteten Richtlinie hinzufügen. Führen Sie den folgenden Befehl aus, um diese Richtlinie zu Ihrer Rolle hinzuzufügen: ``` aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole ``` Weitere Informationen finden Sie unter [Arbeiten mit AWS verwalteten Richtlinien in der Ausführungsrolle](permissions-managed-policies.md). ## Preisgestaltung Für die Verwendung von Lambda-Protokollen fallen keine zusätzlichen Gebühren an; Es fallen jedoch die Standardgebühren für CloudWatch Logs an. Weitere Informationen hierzu finden Sie unter [Amazon CloudWatch – Preise.](https://aws.amazon.com/cloudwatch/pricing/) # Konfiguration von CloudWatch Protokollgruppen Standardmäßig wird CloudWatch automatisch eine Protokollgruppe erstellt, die nach Ihrer Funktion benannt ist, wenn sie `/aws/lambda/` zum ersten Mal aufgerufen wird. Um Ihre Funktion so zu konfigurieren, dass Protokolle an eine bestehende Protokollgruppe gesendet werden, oder um eine neue Protokollgruppe für Ihre Funktion zu erstellen, können Sie die Lambda-Konsole oder die AWS CLI verwenden. Sie können benutzerdefinierte Protokollgruppen auch mithilfe der Befehle [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)und [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Lambda API und der Ressource AWS Serverless Application Model (AWS SAM) [AWS: :Serverless: :Function]() konfigurieren. Sie können mehrere Lambda-Funktionen so konfigurieren, dass sie Protokolle an dieselbe CloudWatch Protokollgruppe senden. Beispielsweise könnten Sie eine einzelne Protokollgruppe verwenden, um Protokolle für alle Lambda-Funktionen zu speichern, aus denen eine bestimmte Anwendung besteht. Wenn Sie eine benutzerdefinierte Protokollgruppe für eine Lambda-Funktion verwenden, enthalten die von Lambda erstellten Protokollstreams den Funktionsnamen und die Funktionsversion. Dadurch wird sichergestellt, dass die Zuordnung zwischen Protokollmeldungen und Funktionen erhalten bleibt, auch wenn Sie dieselbe Protokollgruppe für mehrere Funktionen verwenden. Das Protokollstream-Benennungsformat für benutzerdefinierte Protokollgruppen folgt dieser Benennungskonvention: ``` YYYY/MM/DD/[][] ``` Beachten Sie, dass bei der Konfiguration einer benutzerdefinierten Protokollgruppe der Name, den Sie für Ihre Protokollgruppe auswählen, den [Benennungsregeln für CloudWatch Protokolle entsprechen](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) muss. Darüber hinaus dürfen benutzerdefinierte Protokollgruppennamen nicht mit der Zeichenfolge `aws/` beginnen. Wenn Sie eine benutzerdefinierte Protokollgruppe erstellen, die mit `aws/` beginnt, kann Lambda die Protokollgruppe nicht erstellen. Aus diesem Grund werden die Protokolle Ihrer Funktion nicht an gesendet CloudWatch. **So ändern Sie die Protokollgruppe einer Funktion (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie eine Funktion aus. 1. Wählen Sie auf der Konfigurationsseite der Funktion die Option **Überwachungs- und Betriebstools** aus. 1. Wählen Sie im Bereich **Protokollierungskonfiguration** die Option **Bearbeiten** aus. 1. Wählen **Sie im Bereich Protokollgruppe** für **CloudWatch Protokollgruppe** die Option **Benutzerdefiniert** aus. 1. Geben Sie unter **Benutzerdefinierte Protokollgruppe** den Namen der CloudWatch Protokollgruppe ein, an die Ihre Funktion Protokolle senden soll. Wenn Sie den Namen einer vorhandenen Protokollgruppe eingeben, verwendet Ihre Funktion diese Gruppe. Wenn keine Protokollgruppe mit dem von Ihnen eingegebenen Namen existiert, erstellt Lambda eine neue Protokollgruppe für Ihre Funktion mit diesem Namen. **So ändern Sie die Protokollgruppe einer Funktion (AWS CLI)** + Verwenden Sie den Befehl [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html), um die Protokollgruppe einer vorhandenen Funktion zu ändern. ``` aws lambda update-function-configuration \ --function-name myFunction \ --logging-config LogGroup=myLogGroup ``` **So geben Sie eine benutzerdefinierte Protokollgruppe an, wenn Sie eine Funktion erstellen (AWS CLI)** + Um eine benutzerdefinierte Protokollgruppe anzugeben, wenn Sie eine neue Lambda-Funktion mit dem erstellen AWS CLI, verwenden Sie die `--logging-config` Option. Mit dem folgenden Beispielbefehl wird eine Node.js-Lambda-Funktion erstellt, die Protokolle an eine Protokollgruppe mit dem Namen `myLogGroup` sendet. ``` aws lambda create-function \ --function-name myFunction \ --runtime nodejs24.x \ --handler index.handler \ --zip-file fileb://function.zip \ --role arn:aws:iam::123456789012:role/LambdaRole \ --logging-config LogGroup=myLogGroup ``` ## Berechtigungen für die Ausführungsrolle Damit Ihre Funktion Logs an CloudWatch Logs senden kann, muss sie über die [Logs: PutLogEvents -Berechtigung](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) verfügen. Wenn Sie die Protokollgruppe Ihrer Funktion mithilfe der Lambda-Konsole konfigurieren, fügt Lambda diese Berechtigung der Rolle unter folgenden Bedingungen hinzu: + Das Serviceziel ist auf CloudWatch Logs gesetzt + Die Ausführungsrolle Ihrer Funktion ist nicht berechtigt, Logs in Logs (das Standardziel) hochzuladen CloudWatch **Anmerkung** Lambda fügt keine Put-Berechtigungen für Amazon S3- oder Firehose-Protokollziele hinzu. Wenn Lambda diese Berechtigung hinzufügt, erteilt es der Funktion die Erlaubnis, Protokolle an jede CloudWatch Logs-Protokollgruppe zu senden. Um zu verhindern, dass Lambda die Ausführungsrolle der Funktion automatisch aktualisiert, damit Sie diese stattdessen manuell bearbeiten, erweitern Sie **Berechtigungen** und deaktivieren Sie **Erforderliche Berechtigungen hinzufügen**. Wenn Sie die Protokollgruppe Ihrer Funktion mithilfe von konfigurieren AWS CLI, fügt Lambda die `logs:PutLogEvents` Berechtigung nicht automatisch hinzu. Fügen Sie die Berechtigung zur Ausführungsrolle Ihrer Funktion hinzu, falls noch nicht geschehen. Diese Berechtigung ist in der [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor)verwalteten Richtlinie enthalten. ## CloudWatch Protokollierung für Lambda Managed Instances Bei der Verwendung von [Lambda Managed Instances](lambda-managed-instances.md) gibt es zusätzliche Überlegungen zum Senden von Protokollen an CloudWatch Logs: ### VPC-Netzwerkanforderungen Lambda Managed Instances werden auf kundeneigenen EC2 Instances innerhalb Ihrer VPC ausgeführt. Um CloudWatch Logs an Logs und Traces an X-Ray zu senden, müssen Sie sicherstellen, dass diese von Ihrer VPC aus routingfähig AWS APIs sind. Sie haben mehrere Möglichkeiten: + **AWS PrivateLink (empfohlen): Wird** verwendet [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html), um VPC-Endpunkte für CloudWatch Logs und X-Ray-Dienste zu erstellen. Dadurch können Ihre Instances privat auf diese Dienste zugreifen, ohne dass ein Internet-Gateway oder NAT-Gateway erforderlich ist. Weitere Informationen finden Sie unter [Verwenden von CloudWatch Protokollen mit VPC-Endpunkten der Schnittstelle](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html). + **NAT-Gateway**: Konfigurieren Sie ein NAT-Gateway, um ausgehenden Internetzugang von Ihren privaten Subnetzen aus zu ermöglichen. + **Internet Gateway**: Stellen Sie für öffentliche Subnetze sicher, dass für Ihre VPC ein Internet-Gateway konfiguriert ist. Wenn CloudWatch Logs oder X-Ray nicht von Ihrer VPC aus routingfähig APIs sind, werden Ihre Funktionsprotokolle und Traces nicht zugestellt. ### Gleichzeitige Aufrufe und Protokollzuweisung Ausführungsumgebungen für Lambda Managed Instances können mehrere Aufrufe gleichzeitig verarbeiten. Wenn mehrere Aufrufe gleichzeitig ausgeführt werden, werden ihre Protokolleinträge im selben Protokollstream verschachtelt. Um Protokolle von gleichzeitigen Aufrufen effektiv zu filtern und zu analysieren, sollten Sie sicherstellen, dass jeder Protokolleintrag die Anforderungs-ID enthält. AWS Wir empfehlen einen der folgenden Ansätze: + **Verwenden Sie standardmäßige Lambda-Laufzeitlogger (empfohlen)**: Die von Lambda Managed Runtimes bereitgestellten Standard-Logging-Bibliotheken enthalten automatisch die Anforderungs-ID in jedem Protokolleintrag. + **Implementieren Sie strukturierte JSON-Protokollierung**: Wenn Sie eine [benutzerdefinierte Laufzeit erstellen oder eine benutzerdefinierte](runtimes-custom.md) Protokollierung benötigen, implementieren Sie Protokolle im JSON-Format, die die Anforderungs-ID in jedem Eintrag enthalten. Lambda Managed Instances unterstützen nur das JSON-Protokollformat. Nehmen Sie das `requestId` Feld in Ihre JSON-Logs auf, um die Filterung nach Aufrufen zu ermöglichen: ``` { "timestamp": "2025-01-15T10:30:00.000Z", "level": "INFO", "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "message": "Processing request" } ``` Mit der Zuordnung der Anfrage-ID können Sie CloudWatch Log-Log-Log-Einträge für einen bestimmten Aufruf mithilfe von CloudWatch Logs Insights-Abfragen filtern. Beispiel: ``` fields @timestamp, @message | filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890" | sort @timestamp asc ``` Weitere Informationen zu den Protokollierungsanforderungen für Lambda Managed Instances finden Sie unter[Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances](lambda-managed-instances-execution-environment.md). # CloudWatch Logs für Lambda-Funktionen anzeigen Sie können CloudWatch Amazon-Protokolle für Ihre Lambda-Funktion mit der Lambda-Konsole, der CloudWatch Konsole oder der AWS Command Line Interface ()AWS CLI anzeigen. Folgen Sie den Anweisungen in den folgenden Abschnitten, um auf die Protokolle Ihrer Funktion zuzugreifen. ## Streamen Sie CloudWatch Funktionsprotokolle mit Logs Live Tail Amazon CloudWatch Logs Live Tail hilft Ihnen bei der schnellen Fehlerbehebung bei Ihren Funktionen, indem es eine Streaming-Liste mit neuen Protokollereignissen direkt in der Lambda-Konsole anzeigt. Sie können die von Ihren Lambda-Funktionen aufgenommenen Protokolle in Echtzeit anzeigen und filtern, sodass Sie Probleme schnell erkennen und beheben können. **Anmerkung** Bei Live Tail-Sitzungen fallen Kosten pro Minute an. Weitere Informationen zur Preisgestaltung finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/). ### Vergleich von Live Tail und --log-type Tail Es gibt mehrere Unterschiede zwischen CloudWatch Logs Live Tail und der Option [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) in der Lambda-API (`--log-type Tail`in der AWS CLI): + `--log-type Tail` gibt nur die ersten 4 KB der Aufruf-Logs zurück. Live Tail hat dieses Limit nicht gemeinsam und kann bis zu 500 Protokollereignisse pro Sekunde empfangen. + `--log-type Tail` erfasst und sendet die Protokolle zusammen mit der Antwort, was sich auf die Antwortlatenz der Funktion auswirken kann. Live Tail hat keinen Einfluss auf die Reaktionslatenz der Funktionen. + `--log-type Tail` unterstützt nur synchrone Aufrufe. Live Tail funktioniert sowohl für synchrone als auch für asynchrone Aufrufe. **Anmerkung** [Lambda Managed Instances](lambda-managed-instances.md) unterstützt `--log-type Tail` diese Option nicht. Verwenden Sie CloudWatch Logs Live Tail oder fragen Sie CloudWatch Logs direkt ab, um Logs für Funktionen von Managed Instances einzusehen. ### Berechtigungen Die folgenden Berechtigungen sind erforderlich, um CloudWatch Logs Live Tail-Sitzungen zu starten und zu beenden: + `logs:DescribeLogGroups` + `logs:StartLiveTail` + `logs:StopLiveTail` ### Starten einer Live-Tail-Sitzung in der Lambda-Konsole 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen einer Funktion aus. 1. Wählen Sie die Registerkarte **Test**. 1. Wählen Sie im Bereich **Testereignis** die Option **CloudWatch Logs Live Tail** aus. 1. Für **Protokollgruppen auswählen** ist standardmäßig die Protokollgruppe der Funktion ausgewählt. Sie können bis zu fünf Protokollgruppen gleichzeitig auswählen. 1. (Optional) Um nur Protokollereignisse anzuzeigen, die bestimmte Wörter oder andere Zeichenfolgen enthalten, geben Sie das Wort oder die Zeichenfolge in das Feld **Filtermuster hinzufügen** ein. Im Feld „Filter“ wird zwischen Groß- und Kleinschreibung unterschieden. Sie können mehrere Begriffe und Musteroperatoren in dieses Feld eingeben, einschließlich regulärer Ausdrücke (regex). Weitere Informationen zur Mustersyntax finden Sie unter [Filtermustersyntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html). im *Amazon CloudWatch Logs-Benutzerhandbuch*. 1. Wählen Sie **Starten**. Im Fenster werden nun übereinstimmende Protokollereignisse angezeigt. 1. Zum Beenden der Live-Tail-Sitzung wählen Sie **Stoppen**. **Anmerkung** Die Live-Tail-Sitzung wird automatisch nach 15 Minuten Inaktivität oder nach Ablauf der Zeit für die Lambda-Konsolensitzung beendet. ## Zugriff auf Funktionsprotokolle über die Konsole 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie eine Funktion aus. 1. Wählen Sie den Tab **Überwachung**. 1. Wählen Sie ** CloudWatch Protokolle anzeigen**, um die CloudWatch Konsole zu öffnen. 1. Scrollen Sie nach unten und wählen Sie den **Protokollstream** für die Funktionsaufrufen aus, die Sie sich ansehen möchten. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/log-stream.png) Jede Instance einer Lambda-Funktion hat einen eigenen Protokollstream. Wenn eine Funktion skaliert wird, hat jede gleichzeitige Instance ihren eigenen Protokollstream. Jedes Mal, wenn als Reaktion auf einen Aufruf eine neue Ausführungsumgebung erstellt wird, wird ein neuer Protokollstream generiert. Die Benennungskonvention für Protokollstreams lautet: ``` YYYY/MM/DD[Function version][Execution environment GUID] ``` Eine einzelne Ausführungsumgebung schreibt während ihrer Lebensdauer in denselben Protokollstream. Der Protokollstream enthält Nachrichten aus dieser Ausführungsumgebung sowie alle Ausgaben aus dem Code Ihrer Lambda-Funktion. Jede Nachricht wird mit einem Zeitstempel versehen, auch Ihre benutzerdefinierten Protokolle. Selbst wenn Ihre Funktion keine Ausgabe Ihres Codes protokolliert, werden pro Aufruf mindestens drei Protokollanweisungen generiert (START, END und REPORT): ![\[Überwachung der Beobachtbarkeit Abbildung 3\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-3.png) Aus diesen Protokollen geht Folgendes hervor: + **RequestId**— Dies ist eine eindeutige ID, die pro Anfrage generiert wird. Wenn die Lambda-Funktion eine Anfrage erneut versucht, ändert sich diese ID nicht und erscheint in den Protokollen für jeden weiteren Versuch. + **Start/Ende**: Diese setzen ein Lesezeichen für einen einzelnen Aufruf, sodass jede Protokollzeile zwischen diesen Aufrufen zu demselben Aufruf gehört. + **Dauer**: Die gesamte Aufrufzeit für die Handler-Funktion, ohne `INIT`-Code. + **Dauer der Abrechnung**: Wendet die Rundungslogik für Abrechnungszwecke an. + **Speichergröße**: Die der Funktion zugewiesene Speichermenge. + **Maximal genutzter Speicher**: Der maximale während des Aufrufs genutzte Speicher. + **Initialisierungsdauer**: Die Zeit, die benötigt wurde, um den `INIT`-Codeabschnitt außerhalb des Haupthandlers auszuführen. ## Zugriffs-Logs mit dem AWS CLI Das AWS CLI ist ein Open-Source-Tool, mit dem Sie mithilfe von Befehlen in Ihrer Befehlszeilen-Shell mit AWS Diensten interagieren können. Zur Durchführung der Schritte in diesem Abschnitt benötigen Sie [AWS CLI Version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Sie können die [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) verwenden, um Protokolle für einen Aufruf mit der `--log-type`-Befehlsoption abzurufen. Die Antwort enthält das Feld `LogResult`, das bis zu 4 KB base64-verschlüsselte Protokolle aus dem Aufruf enthält. **Example eine Log-ID abrufen** Das folgende Beispiel zeigt, wie eine *Protokoll-ID* aus dem `LogResult`-Feld für eine Funktion namens `my-function` abgerufen wird. ``` aws lambda invoke --function-name my-function out --log-type Tail ``` Die Ausgabe sollte folgendermaßen aussehen: ``` { "StatusCode": 200, "LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...", "ExecutedVersion": "$LATEST" } ``` **Example entschlüsseln der Protokolle** Verwenden Sie in derselben Eingabeaufforderung das `base64`-Dienstprogramm, um die Protokolle zu entschlüsseln. Das folgende Beispiel zeigt, wie Base64-codierte Logs für abgerufen werde `my-function`. ``` aws lambda invoke --function-name my-function out --log-type Tail \ --query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode ``` Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*. Die Ausgabe sollte folgendermaßen aussehen: ``` START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST "AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib", END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB ``` Das `base64`-Dienstprogramm ist unter Linux, macOS und [Ubuntu auf Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10)verfügbar. macOS-Benutzer müssen möglicherweise `base64 -D` verwenden. **Example get-logs.sh-Skript** Verwenden Sie in derselben Eingabeaufforderung das folgende Skript, um die letzten fünf Protokollereignisse herunterzuladen. Das Skript verwendet `sed` zum Entfernen von Anführungszeichen aus der Ausgabedatei und wechselt 15 Sekunden lang in den Ruhezustand, um Zeit einzuräumen, damit Protokolle verfügbar werden können. Die Ausgabe enthält die Antwort von Lambda und die `get-log-events`Ausgabe des Befehls. Kopieren Sie den Inhalt des folgenden Codebeispiels und speichern Sie es in Ihrem Lambda-Projektverzeichnis unter `get-logs.sh`. Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*. ``` #!/bin/bash aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out sed -i'' -e 's/"//g' out sleep 15 aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5 ``` **Example macOS und Linux (nur diese Systeme)** In derselben Eingabeaufforderung müssen macOS- und Linux-Benutzer möglicherweise den folgenden Befehl ausführen, um sicherzustellen, dass das Skript ausführbar ist. ``` chmod -R 755 get-logs.sh ``` **Example die letzten fünf Protokollereignisse abrufen** Führen Sie an derselben Eingabeaufforderung das folgende Skript aus, um die letzten fünf Protokollereignisse abzurufen. ``` ./get-logs.sh ``` Die Ausgabe sollte folgendermaßen aussehen: ``` { "StatusCode": 200, "ExecutedVersion": "$LATEST" } { "events": [ { "timestamp": 1559763003171, "message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n", "ingestionTime": 1559763003309 }, { "timestamp": 1559763003173, "message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003173, "message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003218, "message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003218, "message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n", "ingestionTime": 1559763018353 } ], "nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795", "nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080" } ``` ## Parsing von Protokollen und strukturierte Protokollierung Mit CloudWatch Logs Insights können Sie Protokolldaten mithilfe einer speziellen [Abfragesyntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) suchen und analysieren. Es führt Abfragen über mehrere Protokollgruppen durch und bietet eine leistungsstarke Filterung mithilfe von Mustervergleichen mit [Glob](https://en.wikipedia.org/wiki/Glob_(programming))- und [regulären Ausdrücken](https://en.wikipedia.org/wiki/Regular_expression). Sie können diese Funktionen nutzen, indem Sie strukturierte Protokollierung in Ihren Lambda-Funktionen implementieren. Strukturierte Protokollierung organisiert Ihre Protokolle in einem vordefinierten Format, wodurch die Abfrage vereinfacht wird. Die Verwendung von Protokollebenen ist ein wichtiger erster Schritt zur Erstellung filterfreundlicher Protokolle, die Informationsmeldungen von Warnungen oder Fehlern trennen. Betrachten Sie beispielsweise den folgenden Node.js-Code: ``` exports.handler = async (event) => { console.log("console.log - Application is fine") console.info("console.info - This is the same as console.log") console.warn("console.warn - Application provides a warning") console.error("console.error - An error occurred") } ``` Die resultierende CloudWatch Protokolldatei enthält ein separates Feld, das die Protokollebene angibt: ![\[Überwachung der Beobachtbarkeit Abbildung 10\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-10.png) Eine CloudWatch Logs Insights-Abfrage kann dann auf Protokollebene filtern. Um beispielsweise nur nach Fehlern zu suchen, können Sie die folgende Abfrage verwenden: ``` fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc ``` ### JSON-strukturierte Protokollierung JSON wird häufig verwendet, um Anwendungsprotokolle zu strukturieren. Im folgenden Beispiel wurden die Protokolle in JSON konvertiert, um drei unterschiedliche Werte auszugeben: ![\[Überwachung der Beobachtbarkeit Abbildung 11\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-11.png) Die CloudWatch Logs Insights-Funktion erkennt automatisch Werte in der JSON-Ausgabe und analysiert die Nachrichten als Felder, ohne dass ein benutzerdefinierter Glob oder ein regulärer Ausdruck erforderlich ist. Unter Verwendung der JSON-strukturierten Protokolle findet die folgende Abfrage Aufrufe, bei denen die hochgeladene Datei größer als 1 MB war, die Upload-Zeit mehr als 1 Sekunde betrug und der Aufruf kein Kaltstart war: ``` fields @message | filter @message like /INFO/ | filter uploadedBytes > 1000000 | filter uploadTimeMS > 1000 | filter invocation != 1 ``` Diese Abfrage könnte folgendes Ergebnis liefern: ![\[Überwachung der Beobachtbarkeit Abbildung 12\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-12.png) Die in JSON erkannten Felder werden automatisch im Menü *Erkannte Felder* auf der rechten Seite ausgefüllt. Den vom Lambda-Dienst ausgegebenen Standardfeldern ist ein „@“ vorangestellt und Sie können diese Felder auf die gleiche Weise abfragen. Lambda-Logs enthalten immer die Felder @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize. Wenn X-Ray für eine Funktion aktiviert ist, enthalten die Protokolle auch @ xrayTraceId und @xraySegmentId. Wenn eine AWS Ereignisquelle wie Amazon S3, Amazon SQS oder Amazon Ihre Funktion EventBridge aufruft, wird der Funktion das gesamte Ereignis als JSON-Objekteingabe zur Verfügung gestellt. Indem Sie dieses Ereignis in der ersten Zeile der Funktion protokollieren, können Sie anschließend mithilfe CloudWatch von Logs Insights jedes der verschachtelten Felder abfragen. ### Nützliche Insights-Abfragen Die folgende Tabelle zeigt Beispiele für Insights-Abfragen, die für die Überwachung von Lambda-Funktionen nützlich sein können. | Description | Beispiel für Abfragesyntax | | --- | --- | | Die letzten 100 Fehler | ``` fields Timestamp, LogLevel, Message \| filter LogLevel == "ERR" \| sort @timestamp desc \| limit 100 ``` | | Die 100 Aufrufe mit den höchsten Abrechnungen | ``` filter @type = "REPORT" \| fields @requestId, @billedDuration \| sort by @billedDuration desc \| limit 100 ``` | | Prozentualer Anteil der Kaltstarts an der Gesamtzahl der Aufrufe | ``` filter @type = "REPORT" \| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as coldStartPct, avg(@duration) by bin(5m) ``` | | Perzentilbericht zur Lambda-Dauer | ``` filter @type = "REPORT" \| stats avg(@billedDuration) as Average, percentile(@billedDuration, 99) as NinetyNinth, percentile(@billedDuration, 95) as NinetyFifth, percentile(@billedDuration, 90) as Ninetieth by bin(30m) ``` | | Perzentilbericht zur Lambda-Speichernutzung | ``` filter @type="REPORT" \| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed, min(@maxMemoryUsed/1024/1024) as min_MemoryUsed, max(@maxMemoryUsed/1024/1024) as max_MemoryUsed, percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95 ``` | | Aufrufe, die 100 % des zugewiesenen Speichers beanspruchen | ``` filter @type = "REPORT" and @maxMemoryUsed=@memorySize \| stats count_distinct(@requestId) by bin(30m) ``` | | Durchschnittlicher Speicherverbrauch bei Aufrufen | ``` avgMemoryUsedPERC, avg(@billedDuration) as avgDurationMS by bin(5m) ``` | | Visualisierung von Speicherstatistiken | ``` filter @type = "REPORT" \| stats max(@maxMemoryUsed / 1024 / 1024) as maxMemMB, avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB, min(@maxMemoryUsed / 1024 / 1024) as minMemMB, (avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct, avg(@billedDuration) as avgDurationMS by bin(30m) ``` | | Aufrufe, bei denen Lambda beendet wurde | ``` filter @message like /Process exited/ \| stats count() by bin(30m) ``` | | Aufrufe mit Zeitüberschreitung | ``` filter @message like /Task timed out/ \| stats count() by bin(30m) ``` | | Latenzbericht | ``` filter @type = "REPORT" \| stats avg(@duration), max(@duration), min(@duration) by bin(5m) ``` | | Übermäßig bereitgestellter Arbeitsspeicher | ``` filter @type = "REPORT" \| stats max(@memorySize / 1024 / 1024) as provisonedMemMB, min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB, avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB, max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB, provisonedMemMB - maxMemUsedMB as overProvisionedMB ``` | ## Protokollvisualisierung und Dashboards Für jede CloudWatch Logs Insights-Abfrage können Sie die Ergebnisse im Markdown- oder CSV-Format exportieren. In einigen Fällen kann es sinnvoller sein, [Visualisierungen aus Abfragen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html) zu erstellen, sofern mindestens eine Aggregationsfunktion vorhanden ist. Mit der `stats`-Funktion können Sie Aggregationen und Gruppierungen definieren. Das vorherige *logInsightsJSON*-Beispiel hat nach Upload-Größe und Upload-Zeit gefiltert und erste Aufrufe ausgeschlossen. Dies führte zu einer Datentabelle. Für die Überwachung eines Produktionssystems kann es sinnvoller sein, die minimalen, maximalen und durchschnittlichen Dateigrößen zu visualisieren, um Ausreißer zu erkennen. Wenden Sie dazu die Statistikfunktion mit den erforderlichen Aggregaten an und gruppieren Sie nach einem Zeitwert, z. B. jede Minute: Nehmen Sie beispielsweise die folgende Abfrage. Dies ist dieselbe Beispielabfrage wie im Abschnitt [JSON-strukturierte Protokollierung](#querying-logs-json), jedoch mit zusätzlichen Aggregationsfunktionen: ``` fields @message | filter @message like /INFO/ | filter uploadedBytes > 1000000 | filter uploadTimeMS > 1000 | filter invocation != 1 | stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m) ``` Wir haben diese Aggregate aufgenommen, da es möglicherweise hilfreicher ist, die minimalen, maximalen und durchschnittlichen Dateigrößen zu visualisieren, um Ausreißer zu finden. Sie können die Ergebnisse auf der Registerkarte **Visualisierung** einsehen: ![\[Überwachung der Beobachtbarkeit Abbildung 14\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-14.png) Nachdem Sie die Erstellung der Visualisierung abgeschlossen haben, können Sie das Diagramm optional zu einem CloudWatch Dashboard hinzufügen. Wählen Sie dazu oberhalb der Visualisierung die Option **Zum Dashboard hinzufügen** aus. Dadurch wird die Abfrage als Widget hinzugefügt und Sie können automatische Aktualisierungsintervalle auswählen, was die kontinuierliche Überwachung der Ergebnisse erleichtert: ![\[Überwachung der Beobachtbarkeit Abbildung 15\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-observability-figure-15.png)