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.

Webfunktionsprotokolle in Amazon CloudWatch Logs

AWS Lambda erfasst alles, was Ihre Anwendung in die Standardausgabe und den Standardfehler schreibt, und sendet es zusammen mit CloudWatch Systemprotokollen, die Lambda selbst generiert, an Amazon Logs. Die Ausgabe jeder console Methode, z. B., und console.log console.infoconsole.error, wird automatisch erfasst und anhand der applicationLogLevel Einstellung gefiltert. Node.js Protokollbibliotheken, die in die Standardausgabe oder Standardfehlerausgabe schreiben, werden ebenfalls erfasst. Sie benötigen weder einen Logging-Agent noch das Amazon CloudWatch Logs SDK.

Lambda schreibt die console Ausgabe als JSON-Protokollereignisse und fügt jedem Ereignis die region Felder requestIdendpointName, und hinzu. Ein Beispiel finden Sie unter Strukturierte Logs schreiben.

Lambda sammelt Protokolle in allen Bereichen, in AWS-Region denen Ihre Webfunktion ausgeführt wird, und zentralisiert sie dann in der Heimatregion der Funktion. Ein HomeRegion Endpunkt läuft nur in der Heimatregion. Ein MultiRegion PerRegion OR-Endpunkt wird auch in den anderen Regionen ausgeführt, die Sie angeben, sodass Lambda die Protokolle aus jeder dieser Regionen zentralisiert. Weitere Informationen finden Sie unter Endpunkttypen.

Protokollgruppen

Standardmäßig sendet Lambda die Protokolle Ihrer Webfunktion an eine Protokollgruppe, die nach der Funktion benannt ist:

/aws/lambda/web/function-name

Neben der zentralisierten Protokollgruppe verwendet Lambda eine zugehörige Protokollgruppe, um regionsinterne Protokolle zu speichern, bevor sie zentralisiert werden. Der Name des Companions ist der Name der zentralisierten Protokollgruppe.local, gefolgt von, sowohl für die Standard-Protokollgruppe als auch für eine benutzerdefinierte Protokollgruppe. Für die Standard-Protokollgruppe lautet der Begleiter:

/aws/lambda/web/function-name.local

Lambda schreibt Protokolle in die .local Protokollgruppe in jeder Region, in der Anfragen ausgeführt werden, einschließlich der Heimatregion, und zentralisiert sie dann in der Protokollgruppe ohne das Suffix in der Heimatregion. Jede .local Protokollgruppe enthält nur die Protokolle aus ihrer eigenen Region. Lambda entfernt nach der Zentralisierung keine Ereignisse aus der .local Protokollgruppe. Die Aufbewahrungseinstellung der Protokollgruppe bestimmt, wie lange sie verbleiben.

Die Protokollgruppen existieren erst, wenn Ihre Web-Funktion ihre erste Anfrage bearbeitet. Die zentralisierte Protokollgruppe in der Heimatregion wird möglicherweise nach der .local Protokollgruppe angezeigt. Informationen zum Zeitpunkt der Zentralisierung finden Sie unterLatenz bei der Zentralisierung.

Lambda erstellt die Standard-Protokollgruppe und jede .local Protokollgruppe mit den Standardeinstellungen von Amazon CloudWatch Logs, sodass ihre Ereignisse nie ablaufen, es sei denn, Sie legen eine Aufbewahrungsrichtlinie fest. Sie können ihre Aufbewahrungs-, Verschlüsselungs- und Ressourcenrichtlinien ändern, nachdem Lambda sie erstellt hat. Legen Sie diese in der .local Protokollgruppe in jeder Region fest, in der der Endpunkt ausgeführt wird, und in der zentralen Protokollgruppe in der Heimatregion.

Da die .local Protokollgruppe nicht auf die Zentralisierung wartet, ist sie nützlich, um ein Problem in einer bestimmten Region zu debuggen. Die zentralisierte Protokollgruppe enthält Protokolle aus allen Regionen. Erstellen Sie daher gemeinsame Abfragen, Abonnementfilter, Metrikfilter und Automatisierungen, die die gesamte Anwendung in der zentralen Protokollgruppe abdecken müssen. Informationen zum Verhalten der Telemetrie in den einzelnen Regionen finden Sie unter. Telemetrie in jeder Region

Verwenden einer benutzerdefinierten Protokollgruppe

Sie können die Protokolle Ihrer Webfunktion an eine Protokollgruppe senden, die Sie anstelle der Standardgruppe auswählen. Verwenden Sie eine benutzerdefinierte Protokollgruppe, wenn Sie Richtlinien für Aufbewahrung, Verschlüsselung oder Ressourcen einrichten möchten, bevor das erste Protokollereignis eintrifft. Mit einer benutzerdefinierten Protokollgruppe können Sie auch Protokolle verschiedener Funktionen gruppieren. Um diese Einstellungen von Anfang an anzuwenden, erstellen Sie die Protokollgruppe und die .local zugehörige Gruppe selbst, bevor Sie den Datenverkehr an die Revision weiterleiten. Wenn keine der Protokollgruppen existiert, erstellt Lambda sie bei der ersten Verwendung mit Standardeinstellungen, und Sie können ihre Einstellungen anschließend aktualisieren. Lambda kann eine Protokollgruppe nur erstellen, wenn die Ausführungsrolle über die Berechtigung zum Erstellen von Protokollgruppen verfügt. Die erforderlichen Berechtigungen finden Sie unter Rolle „Ausführung“.

Da die Protokollierungskonfiguration Teil der Revision ist, ist sie für diese Revision unveränderlich. Um die Protokollgruppe später zu ändern, erstellen Sie eine weitere Revision. Weitere Informationen finden Sie unter Revisionen von Webfunktionen verwalten.

Kontrollen für die Protokollierung

loggingConfigIn diesem Abschnitt werden das Ziel und der Mindestschweregrad von Protokollen gesteuert. Diese Einstellungen sind Teil der Revision.

Im folgenden Beispiel wird eine Revision erstellt, bei der die folgenden Anwendungsprotokolle gelöscht werdenWARN:

aws lambda-web create-web-function-revision \
    --function-name my-web-app \
    --build-config '{
      "codeConfig": {
        "s3Object": { "bucket": "my-bucket", "key": "my-app.zip" }
      },
      "runtimeConfig": { "runtime": "nodejs24.x" }
    }' \
    --service-config '{
      "executionRoleArn": "arn:aws:iam::111122223333:role/my-web-function-role",
      "telemetryConfig": {
        "loggingConfig": {
          "applicationLogLevel": "WARN",
          "systemLogLevel": "INFO"
        }
      }
    }'

Eine applicationLogLevel Erhöhung der Produktion reduziert sowohl das Protokollvolumen als auch die Kosten. Senken Sie den Wert vorübergehend auf DEBUG oder TRACE wenn Sie ein Problem untersuchen.

Systemprotokolle

Zusätzlich zur Ausgabe Ihrer Anwendung empfängt Ihre Protokollgruppe Systemprotokolle, die Lambda über den Lebenszyklus der Ausführungsumgebung generiert, z. B. die Initialisierung und das Herunterfahren der Umgebung. Wird verwendetsystemLogLevel, um zu kontrollieren, wie viel von diesem Lambda emittiert wird.

Systemprotokolle sind nützlich, um das Anwendungsverhalten mit Plattformereignissen zu korrelieren. Beispielsweise deutet ein Latenzanstieg, der auf einen Eintrag zur Umgebungsinitialisierung zurückzuführen ist, eher auf einen Kaltstart als auf Ihren Anwendungscode hin. Informationen zum Lebenszyklus, den diese Protokolle beschreiben, finden Sie unter. Lebenszyklus der Ausführungsumgebung

Webfunktionen geben die folgenden Systemereignisse aus. Stellen Sie systemLogLevel die niedrigste Stufe ein, die Sie benötigen. Stellen Sie es beispielsweise so einplatform.requestComplete, DEBUG dass nur Fehler und Warnungen WARN zu gelöschten Protokollen empfangen werden sollen.

Informationen zu den Feldern in den einzelnen Systemereignissen finden Sie unterSystemprotokoll-Ereignisschema für Lambda-Webfunktionen.

Der lambda-web-request-id Antwort-Header identifiziert die Anfrage, und der lambda-web-logstream Antwort-Header identifiziert den Log-Stream für die Umgebung, in der sie bearbeitet wurde. Verwenden Sie diese Werte, um eine Client-Antwort mit Anwendungs- und Systemprotokollen zu korrelieren. Weitere Informationen finden Sie unter Antwort-Header.

Um die Ereignisse aus dem identifizierten Protokollstream in der zentralen Protokollgruppe in der Heimatregion zu finden, filtern Sie nach dem Streamnamen als Präfix. Sie können den Stream auch anhand seines genauen Namens aus der .local Protokollgruppe in der Region lesen, die die Anfrage bearbeitet hat.

aws logs filter-log-events \
    --log-group-name /aws/lambda/web/my-web-app \
    --log-stream-name-prefix "LAMBDA_WEB_LOGSTREAM" \
    --region us-east-1

Um aktuelle Logs zu verfolgen, während ein Problem reproduziert wird, verwende:

aws logs tail /aws/lambda/web/my-web-app \
    --follow \
    --region us-east-1

Strukturierte Logs schreiben

Übergeben Sie ein Objekt an eine console Methode, sodass Lambda es als JSON-Objekt in das message Feld schreibt. Sie können dann einzelne Felder in Amazon CloudWatch Logs Insights abfragen, anstatt sie anhand von Teilzeichenfolgen abzugleichen. Übergeben Sie keine Zeichenfolge, mit JSON.stringify der Sie erstellt haben. Lambda schreibt eine Zeichenfolge als maskierten Zeichenkettenwert, sodass ihre Felder nicht abgefragt werden können.

function logRequest(req, statusCode, durationMs) {
  console.info({
    method: req.method,
    path: req.url,
    statusCode: statusCode,
    durationMs: durationMs
  });
}

Lambda schreibt ein Protokollereignis ähnlich dem folgenden:

{
  "timestamp": "2026-09-25T11:29:02.711Z",
  "level": "INFO",
  "message": {
    "method": "GET",
    "path": "/hello-world",
    "statusCode": 200,
    "durationMs": 100
  },
  "requestId": "US3NHLM77IRXDFLBADYHGIZZNM",
  "endpointName": "prod",
  "region": "us-east-1"
}

Sie können die Felder dann direkt abfragen. Die folgende Amazon CloudWatch Logs Insights-Abfrage gibt beispielsweise die 20 neuesten Anfragen zurück, die den Status 5xx zurückgegeben haben:

fields @timestamp, message.method, message.path, message.statusCode, message.durationMs
| filter message.statusCode >= 500
| sort @timestamp desc
| limit 20

Verwenden Sie das eingebettete Metrikformat, um benutzerdefinierte Metriken aus Ihren Protokollen zu veröffentlichen, anstatt sie nur abzufragen. Weitere Informationen finden Sie unter Veröffentlichen von benutzerdefinierten Metriken mit dem eingebetteten Metrikformat.

Verwenden von Amazon CloudWatch Logs-Funktionen mit Ihren Protokollen

Da Protokolle in der Heimatregion zentralisiert sind, können Sie die Standardfunktionen von Amazon CloudWatch Logs in dieser Region verwenden, darunter:

Wenden Sie Funktionen, die die gesamte Anwendung abdecken müssen, auf die zentrale Protokollgruppe in der Heimatregion an. Eine .local Protokollgruppe enthält nur die Protokolle aus ihrer eigenen Region. Weitere Informationen finden Sie unter Telemetrie in jeder Region.