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.
# Überwachung, Debbugging und Fehlerbehebung bei Lambda-Funktionen
AWS Lambda lässt sich in andere AWS-Services integrieren, die Ihnen helfen, Ihre Lambda-Funktionen zu überwachen und Fehler an ihnen zu beheben. Lambda überwacht automatisch Lambda-Funktionen in Ihrem Namen und meldet Metriken über Amazon CloudWatch. Damit Sie Ihren Code während der Ausführung überwachen können, verfolgt Lambda automatisch die Anzahl der Anfragen, die Dauer des Aufrufs pro Anfrage und die Anzahl der Anfragen, die zu einem Fehler führen.
Sie können andere AWS-Services verwenden, um Probleme mit Ihren Lambda-Funktionen zu beheben. In diesem Abschnitt wird beschrieben, wie Sie diese AWS-Services verwenden, um Ihre Lambda-Funktionen und -Anwendungen zu überwachen, zu verfolgen, zu debuggen und zu beheben. Einzelheiten zur Funktionsprotokollierung und zu Fehlern in jeder Laufzeit finden Sie in den einzelnen Laufzeitabschnitten.
**Topics**
+ [Preisgestaltung](#monitoring-console-metrics-pricing)
+ [Verwendung von CloudWatch-Metriken mit Lambda](monitoring-metrics.md)
+ [Arbeiten mit Lambda-Funktionsprotokollen](monitoring-logs.md)
+ [Protokollieren von AWS Lambda API-Aufrufen mit AWS CloudTrail](logging-using-cloudtrail.md)
+ [Visualisieren Sie Lambda-Funktionsaufrufe mit AWS X-Ray](services-xray.md)
+ [Überwachen Sie die Funktionsleistung mit Amazon CloudWatch Lambda Insights](monitoring-insights.md)
+ [Überwachen von Lambda-Anwendungen](applications-console-monitoring.md)
+ [Überwachen der Anwendungsleistung mit Amazon CloudWatch Application Signals](monitoring-application-signals.md)
+ [Remote-Debugging von Lambda-Funktionen mit Visual Studio Code](debugging.md)
## Preisgestaltung
CloudWatch verfügt über unbeschränktes kostenloses Kontingent. Über den Schwellenwert für das kostenlose Kontingent hinaus berechnet CloudWatch Gebühren für Metriken, Dashboards, Alarme, Protokolle und Erkenntnisse. Weitere Informationen hierzu finden Sie unter [Amazon CloudWatch – Preise](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
# Verwendung von CloudWatch-Metriken mit Lambda
Wenn Ihre AWS Lambda-Funktion die Verarbeitung eines Ereignisses beendet hat, sendet Lambda automatisch Metriken über den Aufruf an Amazon CloudWatch. Sie müssen Ihrer Ausführungsrolle keine zusätzlichen Berechtigungen erteilen, um Funktionsmetriken zu erhalten, und für diese Metriken fallen keine zusätzlichen Gebühren an.
Es gibt viele Arten von Metriken, die mit Lambda-Funktionen verknüpft sind. Dazu gehören Aufrufmetriken, Leistungsmetriken, Gleichzeitigkeitsmetriken, Metriken für asynchrone Aufrufe und Metriken für die Zuordnung von Ereignisquellen. Weitere Informationen finden Sie unter [Arten von Metriken für Lambda-Funktionen](monitoring-metrics-types.md).
In der CloudWatch-Konsole können Sie [diese Metriken anzeigen](monitoring-metrics-view.md) und daraus Diagramme und Dashboards erstellen. Sie können auch Alarme so einstellen, dass sie auf Änderungen bei Auslastung, Leistung oder Fehlerraten reagieren. Lambda sendet Metrikdaten an CloudWatch in Intervallen von 1 Minute. Für einen direkteren Einblick in Ihre Lambda-Funktion können Sie [hochauflösende benutzerdefinierte Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) erstellen. Für benutzerdefinierte Metriken und CloudWatch-Alarme fallen Gebühren an. Weitere Informationen hierzu finden Sie unter [Amazon CloudWatch – Preise](https://aws.amazon.com/cloudwatch/pricing/).
# Anzeigen von Metriken für Lambda-Funktionen
Verwenden Sie die CloudWatch-Konsole, um Metriken für Ihre Lambda-Funktionen anzuzeigen. In der Konsole können Sie Funktionsmetriken nach Funktionsname, Alias, Version oder UUID der Zuordnung von Ereignisquellen filtern und sortieren.
**So zeigen Sie Metriken in der CloudWatch-Konsole an**
1. Öffnen Sie die Seite [Metrics](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (Metriken) (`AWS/Lambda`-Namespace) in der CloudWatch-Konsole.
1. Wählen Sie auf der Registerkarte **Durchsuchen** unter **Metriken** eine der folgenden Dimensionen aus:
+ **Nach Funktionsname** (`FunctionName`) – Zeigen Sie Aggregatmetriken für alle Versionen und Aliase einer Funktion anzeigen.
+ **Nach Ressource** (`Resource`) – Zeigen Sie Metriken für eine Version oder den Alias einer Funktion an.
+ **Nach ausgeführter Version** (`ExecutedVersion`) – Zeigen Sie Metriken für eine Kombination aus Alias und Version an. Verwenden Sie die Dimension `ExecutedVersion`, um Fehlerraten für zwei Versionen einer Funktion zu vergleichen, die beide Ziele eines [gewichteten Alias](configuration-aliases.md) sind.
+ **Nach Zuordnung von Ereignisquellen UUID** (`EventSourceMappingUUID`) — Metriken für eine Zuordnung von Ereignisquellen anzeigen.
+ **Über alle Funktionen** (keine) – Zeigen Sie aggregierte Metriken für alle Funktionen in der aktuellen AWS-Region an.
1. Wählen Sie eine Metrik. Die Metrik sollte automatisch im visuellen Diagramm sowie auf der Registerkarte **Graphische Metriken** angezeigt werden.
Standardmäßig verwenden Diagramme die `Sum`-Statistik für alle Metriken. Um eine andere Statistik auszuwählen und das Diagramm anzupassen, verwenden Sie die Optionen auf der Registerkarte **Graphed metrics (Graphierte Metriken)**.
**Anmerkung**
Der Zeitstempel einer Metrik gibt an, wann die Funktion aufgerufen wurde. Abhängig von der Dauer des Aufrufs kann es einige Minuten dauern, bis die Metrik ausgegeben wird. Wenn Ihre Funktion beispielsweise ein Timeout von 10 Minuten aufweist, suchen Sie dann über 10 Minuten in der Vergangenheit hinaus nach genauen Metriken.
Weitere Informationen über CloudWatch finden Sie im [Amazon-CloudWatch-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
# Arten von Metriken für Lambda-Funktionen
In diesem Abschnitt werden die Typen von Lambda-Metriken beschrieben, die in der CloudWatch Konsole verfügbar sind.
**Topics**
+ [Aufrufmetriken](#invocation-metrics)
+ [Bereitstellungsmetriken](#deployment-metrics)
+ [Leistungsmetriken](#performance-metrics)
+ [Gleichzeitigkeitsmetriken](#concurrency-metrics)
+ [Metriken asynchroner Aufrufe](#async-invocation-metrics)
+ [Metriken zur Zuordnung von Ereignisquellen](#event-source-mapping-metrics)
## Aufrufmetriken
Aufrufmetriken sind binäre Indikatoren für das Ergebnis eines Lambda-Funktionsaufrufs. Betrachten Sie diese Metriken mit der Statistik `Sum`. Wenn die Funktion beispielsweise einen Fehler zurückgibt, sendet Lambda die `Errors`-Metrik mit dem Wert 1. Um die Anzahl der Funktionsfehler zu erhalten, die jede Minute aufgetreten sind, lassen Sie sich die `Sum` der `Errors`-Metrik mit einem Zeitraum von 1 Minute anzeigen.
+ `Invocations` – Die Häufigkeit, mit der Ihr Funktionscode aufgerufen wird, einschließlich erfolgreicher Aufrufe und Aufrufe, die zu einem Funktionsfehler führen. Aufrufe werden nicht aufgezeichnet, wenn die Aufrufanforderung gedrosselt wird oder anderweitig zu einem Aufruffehler führt. Der Wert von `Invocations` entspricht der Anzahl der fakturierten Anforderungen.
+ `Errors` – Die Anzahl der Aufrufe, die zu einem Funktionsfehler führen. Funktionsfehler schließen Ausnahmen ein, die Ihr Code ausgibt, und Ausnahmen, die die Lambda-Laufzeit ausgibt. Die Laufzeit gibt Fehler für Probleme wie Timeouts und Konfigurationsfehler zurück. Um die Fehlerquote zu berechnen, teilen Sie den Wert von `Errors` durch den Wert von `Invocations`. Beachten Sie, dass der Zeitstempel für eine Fehlermetrik widerspiegelt, wann die Funktion aufgerufen wurde, und nicht, wann der Fehler aufgetreten ist.
+ `DeadLetterErrors` – Bei [asynchronen Aufrufen](invocation-async.md) die Häufigkeit, mit der Lambda versucht, ein Ereignis an eine Warteschlange für unzustellbare Nachrichten zu senden, was jedoch fehlschlägt. Zustellungsfehler können aufgrund von falsch eingestellten Ressourcen oder Größenbeschränkungen auftreten.
+ `DestinationDeliveryFailures` – Bei asynchronen Aufrufen und unterstützten [Zuordnung von Ereignisquellen](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) die Häufigkeit, mit der Lambda versucht, ein Ereignis an ein [Ziel](invocation-async-retain-records.md#invocation-async-destinations) zu senden, dies jedoch fehlschlägt. Für die Zuordnung von Ereignisquellen unterstützt Lambda Ziele für Streamquellen (DynamoDB und Kinesis). Zustellungsfehler können aufgrund von Berechtigungsfehlern, falsch konfigurierten Ressourcen oder Größenbeschränkungen auftreten. Fehler können auch dann passieren, wenn Ihre Konfiguration einen nicht unterstützten Zieltyp enthält, z. B. eine Amazon-SQS-FIFO-Warteschlange oder ein Amazon-SNS-FIFO-Thema.
+ `Throttles` – Die Anzahl der Aufruf-Anforderungen, die gedrosselt werden. Wenn alle Funktions-Instances Anforderungen verarbeiten und keine Nebenläufigkeit zum Hochskalieren verfügbar ist, lehnt Lambda zusätzliche Anforderungen mit einem `TooManyRequestsException`-Fehler ab. Gedrosselte Anforderungen und andere Aufruffehler zählen nicht als `Invocations` oder `Errors`.
**Anmerkung**
Mit [Lambda Managed Instances](lambda-managed-instances.md) bietet Lambda detaillierte Drosselungsmetriken, die die spezifische Einschränkung identifizieren, die die Drosselung verursacht hat. Wenn in der Ausführungsumgebung eine Drosselung auftritt, wird genau eine der folgenden Untermetriken mit dem Wert 1 ausgegeben, während die restlichen drei mit dem Wert 0 ausgegeben werden. Die `Throttles` Metrik wird immer zusammen mit diesen Untermetriken ausgegeben.
`CPUThrottles`— Aufrufe wurden aufgrund von CPU-Erschöpfung in der Ausführungsumgebung gedrosselt.
`MemoryThrottles`— Aufrufe wurden aufgrund von Speichererschöpfung in der Ausführungsumgebung gedrosselt.
`DiskThrottles`— Aufrufe wurden aufgrund von Festplattenauslastung in der Ausführungsumgebung gedrosselt.
`ConcurrencyThrottles`— Aufrufe werden gedrosselt, wenn das Parallelitätslimit der Ausführungsumgebung erreicht ist.
+ `OversizedRecordCount`: Bei Amazon-DocumentDB-Ereignisquellen die Anzahl von Ereignissen mit einer Größe von mehr als 6 MB, die Ihre Funktion aus Ihrem Change-Stream empfängt. Lambda verwirft die Nachricht und gibt diese Metrik aus.
+ `ProvisionedConcurrencyInvocations` – Gibt an, wie oft Ihr Funktionscode für [bereitgestellte Gleichzeitigkeit](provisioned-concurrency.md) aufgerufen wird.
+ `ProvisionedConcurrencySpilloverInvocations` – Gibt an, wie oft Ihr Funktionscode für Standard-Gleichzeitigkeit aufgerufen wird, wenn die gesamte bereitgestellte Gleichzeitigkeit verwendet wird.
+ `RecursiveInvocationsDropped` – Gibt an, wie oft Lambda den Aufruf Ihrer Funktion beendet hat, weil festgestellt wurde, dass Ihre Funktion Teil einer unendlichen rekursiven Schleife ist. Die rekursive Schleifenerkennung überwacht, wie oft eine Funktion als Teil einer Kette von Anfragen aufgerufen wird, indem Metadaten nachverfolgt werden, die von supported hinzugefügt wurden. AWS SDKs Standardmäßig lässt Lambda den nächsten Aufruf aus, wenn Ihre Funktion als Teil einer Kette von Anforderungen etwa 16 Mal aufgerufen wird. Wenn Sie die rekursive Schleifenerkennung deaktivieren, wird diese Metrik nicht ausgegeben. Weitere Informationen über dieses Feature finden Sie unter [Verwenden Sie die rekursive Lambda-Schleifenerkennung, um Endlosschleifen zu verhindern](invocation-recursion.md).
## Bereitstellungsmetriken
Bereitstellungsmetriken stellen Informationen über Ereignisse bei der Bereitstellung von Lambda-Funktionen und zugehörige Validierungsprozesse bereit.
+ `SignatureValidationErrors` – Gibt an, wie oft bei der Bereitstellung eines Codepakets Fehler bei der Signaturvalidierung aufgetreten sind, obwohl die Codesignatur-Konfigurationsrichtlinie auf `Warn` festgelegt ist. Diese Metrik wird ausgegeben, wenn die Prüfung auf Ablauf, Diskrepanz oder Widerruf scheitert, die Bereitstellung jedoch aufgrund der `Warn`-Richtlinieneinstellung weiterhin zulässig ist. Weitere Informationen zur Codesignatur finden Sie unter [Verwendung von Codesignatur zur Überprüfung der Codeintegrität mit Lambda](configuration-codesigning.md).
## Leistungsmetriken
Performance-Metriken stellen Performance-Details zu einem einzelnen Funktionsaufruf bereit. Die Metrik `Duration` gibt beispielsweise die Zeit in Millisekunden an, die Ihre Funktion auf die Verarbeitung eines Ereignisses aufwendet. Um einen Eindruck davon zu erhalten, wie schnell Ihre Funktion Ereignisse verarbeitet, können Sie sich diese Metriken mit der Statistik `Average` oder `Max` anzeigen lassen.
+ `Duration` – Die Zeit, die Ihr Funktionscode auf die Verarbeitung eines Ereignisses aufwendet. Die fakturierte Dauer für einen Aufruf ist der Wert von `Duration`, aufgerundet auf die nächste Millisekunde. `Duration` beinhaltet nicht die Kaltstartzeit.
+ `PostRuntimeExtensionsDuration` – Die kumulative Zeit, die die Laufzeit nach Abschluss des Funktionscodes mit Erweiterungen verbringt.
+ `IteratorAge` – Bei DynamoDB-, Kinesis- und Amazon-DocumentDB-Ereignisquellen das Alter des letzten Datensatzes im Ereignis in Millisekunden. Diese Matrik misst die Zeit zwischen dem Zeitpunkt, zu dem ein Stream den Datensatz empfängt, und dem Zeitpunkt, zu dem die Zuordnung von Ereignisquellen das Ereignis an die Funktion sendet.
+ `OffsetLag` – Bei selbstverwalteten Apache-Kafka- und Amazon Managed Streaming für Apache Kafka (Amazon MSK)-Ereignisquellen, die Versatzdifferenz zwischen dem letzten Datensatz, der in ein Thema geschrieben wurde, und dem letzten Datensatz, den die Konsumentengruppe Ihrer Funktion verarbeitet hat. Ein Kafka-Thema kann zwar mehrere Partitionen haben, diese Metrik misst die Offset-Verzögerung jedoch auf Themenebene.
`Duration` unterstützt auch Perzentilstatistiken (`p`). Verwenden Sie Perzentile, um Ausreißerwerte auszuschließen, die `Average`s- und `Maximum`-Statistiken verzerren. Die `p95`-Statistik zeigt beispielsweise die maximale Dauer von 95 % der Aufrufe, ohne die langsamsten 5 %. Weitere Informationen finden Sie unter [Perzentile](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles) im * CloudWatch Amazon-Benutzerhandbuch*.
## Gleichzeitigkeitsmetriken
Lambda meldet Gleichzeitigkeitsmetriken als aggregierte Anzahl der Instances, die Ereignisse in einer Funktion, Version, Alias oder AWS-Region verarbeiten. Zeigen Sie diese Metriken mit der Statistik `Max` an, um zu sehen, wie nah Sie an den [Grenzwerten für Gleichzeitigkeit](lambda-concurrency.md#concurrency-quotas) sind.
+ `ConcurrentExecutions` – Die Anzahl der Funktionsinstances, die Ereignisse verarbeiten. Wenn diese Zahl das [Kontingent für gleichzeitige Ausführungen](gettingstarted-limits.md#compute-and-storage) für die Region oder das [Limit reservierter Gleichzeitigkeit](configuration-concurrency.md) für die Funktion erreicht, drosselt Lambda weitere Aufrufanforderungen.
+ `ProvisionedConcurrentExecutions` – Die Anzahl der Funktions-Instances, die Ereignisse für [bereitgestellte Gleichzeitigkeit](provisioned-concurrency.md) verarbeiten. Für jeden Aufruf eines Alias oder einer Version mit Provisioned Concurrency gibt Lambda die aktuelle Anzahl aus. Wenn Ihre Funktion inaktiv ist oder keine Anforderungen empfängt, gibt Lambda diese Metrik nicht aus.
+ `ProvisionedConcurrencyUtilization` – Für eine Version oder einen Alias der Wert von `ProvisionedConcurrentExecutions` geteilt durch die Gesamtmenge der konfigurierten Gleichzeitigkeit. Wenn Sie beispielsweise für Ihre Funktion eine bereitgestellte Gleichzeitigkeit von 10 konfigurieren und Ihr `ProvisionedConcurrentExecutions` 7 ist, dann ist Ihr `ProvisionedConcurrencyUtilization` 0,7.
Wenn Ihre Funktion inaktiv ist oder keine Anforderungen empfängt, gibt Lambda diese Metrik nicht aus, da sie auf `ProvisionedConcurrentExecutions` basiert. Beachten Sie dies, wenn Sie es `ProvisionedConcurrencyUtilization` als Grundlage für Alarme verwenden. CloudWatch
+ `UnreservedConcurrentExecutions` – Für eine Region die Anzahl der Ereignisse, die Funktionen ohne reservierte Nebenläufigkeit verarbeiten.
+ `ClaimedAccountConcurrency` – Mit Bezug auf eine Region die Menge an Gleichzeitigkeit, die für On-Demand-Aufrufe nicht verfügbar ist. `ClaimedAccountConcurrency` entspricht `UnreservedConcurrentExecutions` plus dem Betrag der zugewiesenen Gleichzeitigkeit (d. h. der gesamten reservierten Gleichzeitigkeit plus der gesamten bereitgestellten Gleichzeitigkeit). Weitere Informationen finden Sie unter [Die Metrik `ClaimedAccountConcurrency`](monitoring-concurrency.md#claimed-account-concurrency).
## Metriken asynchroner Aufrufe
Metriken asynchroner Aufrufe liefern Details zu asynchronen Aufrufen aus Ereignisquellen und direkten Aufrufen. Sie können Schwellenwerte und Alarme festlegen, um Sie über bestimmte Änderungen zu informieren. Zum Beispiel, wenn die Anzahl der Ereignisse, die für die Verarbeitung in die Warteschlange gestellt werden, ungewollt ansteigt (`AsyncEventsReceived`). Oder wenn ein Ereignis lange auf seine Verarbeitung gewartet hat (`AsyncEventAge`).
+ `AsyncEventsReceived` – Die Anzahl der Ereignisse, die Lambda erfolgreich zur Verarbeitung in die Warteschlange stellt. Diese Metrik bietet einen Einblick in die Anzahl der Ereignisse, die eine Lambda-Funktion empfängt. Überwachen Sie diese Metrik und stellen Sie Alarme für Schwellenwerte ein, um nach Problemen zu suchen. Zum Beispiel, um eine unerwünschte Anzahl von Ereignissen zu erkennen, die an Lambda gesendet werden, und um schnell Probleme zu diagnostizieren, die auf falsche Auslöser- oder Funktionskonfigurationen zurückzuführen sind. Diskrepanzen zwischen `AsyncEventsReceived` und `Invocations` können auf eine unterschiedliche Verarbeitung, verworfene Ereignisse oder einen möglichen Rückstand in der Warteschlange hinweisen.
+ `AsyncEventAge` – Die Zeit zwischen dem erfolgreichen Einstellen des Ereignisses in die Warteschlange durch Lambda und dem Aufruf der Funktion. Der Wert dieser Metrik steigt, wenn Ereignisse aufgrund von Aufruffehlern oder Drosselung erneut versucht werden. Überwachen Sie diese Metrik und legen Sie Alarme für Schwellenwerte für verschiedene Statistiken fest, wenn sich eine Warteschlange immer länger wird. Um einen Anstieg dieser Metrik zu beheben, sehen Sie sich die `Errors`-Metrik an, um Funktionsfehler zu identifizieren, und die `Throttles`-Metrik, um Gleichzeitigkeitsprobleme zu identifizieren.
+ `AsyncEventsDropped` – Die Anzahl der Ereignisse, die verworfen werden, ohne die Funktion erfolgreich auszuführen. Wenn Sie eine Warteschlange für unzustellbare Nachrichten oder ein `OnFailure`-Ziel konfigurieren, werden Ereignisse dorthin gesendet, bevor sie gelöscht werden. Ereignisse werden aus verschiedenen Gründen verworfen. Beispielsweise können Ereignisse das maximale Ereignisalter überschreiten oder die maximale Anzahl von Wiederholungsversuchen ausschöpfen, oder die reservierte Gleichzeitigkeit ist möglicherweise auf 0 gesetzt. Um herauszufinden, warum Ereignisse verworfen werden, sehen Sie sich die `Errors`-Metrik an, um Funktionsfehler zu identifizieren, und die `Throttles`-Metrik, um Gleichzeitigkeitsprobleme zu identifizieren.
## Metriken zur Zuordnung von Ereignisquellen
Metriken zur Zuordnung von Ereignisquellen bieten Einblicke in das Verarbeitungsverhalten Ihrer Zuordnung von Ereignisquellen.
Derzeit sind Metriken zur Zuordnung von Ereignisquellen für Amazon SQS-, Kinesis-, DynamoDB-, Amazon MSK- und selbstverwaltete Apache Kafka-Ereignisquellen verfügbar.
Für die Zuordnung von Ereignisquellen mit Metrikkonfiguration können Sie jetzt auch alle ESM-bezogenen Metriken auf der Registerkarte **Monitor** auf der Seite Konsole **Lambda** > **Zusätzliche Ressourcen** > **Ereignisquellenzuordnungen** überprüfen.
**So aktivieren Sie Metriken oder eine Zuordnung von Ereignisquellen (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion, für die Sie Metriken aktivieren möchten.
1. Wählen Sie **Konfiguration** und anschließend **Auslöser** aus.
1. Wählen Sie die Zuordnung von Ereignisquellen, für die Sie Metriken aktivieren möchten und wählen Sie dann **Bearbeiten**.
1. **Wählen Sie unter **Konfiguration für die Zuordnung von Ereignisquellen** die Option **Metriken aktivieren** oder wählen Sie eine Option aus der Dropdownliste Metriken aus.**
1. Wählen Sie **Speichern**.
Alternativ können Sie Metriken für Ihre Ereignisquellenzuordnung programmgesteuert aktivieren, indem Sie das [ EventSourceMappingMetricsConfig](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html)Objekt in Ihrem. [EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) Der folgende [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI-Befehl aktiviert beispielsweise Metriken für eine Ereignisquellenzuordnung:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
Es gibt 3 Metrikgruppen:`EventCount`, `ErrorCount` und`KafkaMetrics`, und jede Gruppe hat mehrere Metriken. Nicht jede Metrik ist für jede Ereignisquelle verfügbar. In der folgenden Tabelle sind die unterstützten Metriken für jeden Typ von Ereignisquelle zusammengefasst.
Sie müssen sich für die Metrikgruppe anmelden, um metrikbezogene Metriken zu erhalten. Legen Sie beispielsweise EventCount in der Metrikkonfiguration Folgendes fest: (`PolledEventCount`,,`FilteredOutEventCount`,, `InvokedEventCount` `FailedInvokeEventCount``DroppedEventCount`, `OnFailureDestinationDeliveredEventCount` und). `DeletedEventCount`
| Metrik zur Zuordnung von Ereignisquellen | Metrikgruppe | Amazon SQS | Kinesis- und DynamoDB-Streams | Amazon MSK und selbstverwalteter Apache Kafka |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | Ja | Ja | Ja |
| `FilteredOutEventCount` | `EventCount` | Ja | Ja | Ja |
| `InvokedEventCount` | `EventCount` | Ja | Ja | Ja |
| `FailedInvokeEventCount` | `EventCount` | Ja | Ja | Ja |
| `DroppedEventCount` | `EventCount` | Nein | Ja | Ja |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | Nein | Ja | Ja |
| `DeletedEventCount` | `EventCount` | Ja | Nein | Nein |
| `CommittedEventCount` | `EventCount` | Nein | Nein | Ja |
| `PollingErrorCount` | `ErrorCount` | Nein | Nein | Ja |
| `InvokeErrorCount` | `ErrorCount` | Nein | Nein | Ja |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | Nein | Nein | Ja |
| `SchemaRegistryErrorCount` | `ErrorCount` | Nein | Nein | Ja |
| `CommitErrorCount` | `ErrorCount` | Nein | Nein | Ja |
| `MaxOffsetLag` | `KafkaMetrics` | Nein | Nein | Ja |
| `SumOffsetLag` | `KafkaMetrics` | Nein | Nein | Ja |
Wenn sich Ihre Zuordnung von Ereignisquellen im [Bereitstellungsmodus](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) befindet, stellt Lambda außerdem die folgende Metrik bereit:
+ `ProvisionedPollers` – Bei Zuordnungen von Ereignisquellen im Bereitstellungsmodus die Anzahl der aktiv laufenden Ereignis-Poller. Sehen Sie sich diese Metrik mithilfe der Mathematik an. `MAX`
+ (Nur Amazon MSK und selbstverwaltete Apache Kafka-Ereignisquellen) `EventPollerUnit` — Für Ereignisquellenzuordnungen im Bereitstellungsmodus die Anzahl der Event-Poller-Einheiten, die aktiv ausgeführt werden. Sehen Sie sich diese Metrik mithilfe der Mathematik an. `SUM`
+ (Amazon MSK und selbstverwaltete Apache Kafka-Ereignisquellen) `EventPollerThroughputInBytes` — Für Ereignisquellenzuordnungen im Bereitstellungsmodus die gesamte Datensatzgröße der von der Ereignisquelle abgefragten Event-Poller. Es kann Ihnen den aktuellen Abfragedurchsatz mitteilen. Sehen Sie sich diese Metrik mithilfe der `SUM` Mathematik an.
Hier finden Sie weitere Informationen zu den einzelnen Metriken:
+ `PolledEventCount` – Die Anzahl der Ereignisse, die Lambda erfolgreich aus der Ereignisquelle liest. Wenn Lambda nach Ereignissen abfragt, aber eine leere Umfrage erhält (keine neuen Datensätze), gibt Lambda einen Wert von 0 für diese Metrik aus. Verwenden Sie diese Metrik, um zu ermitteln, ob Ihre Zuordnung von Ereignisquellen korrekt nach neuen Ereignissen fragt.
+ `FilteredOutEventCount` – Bei der Zuordnung von Ereignisquellen mit einem [Filterkriterium](invocation-eventfiltering.md) die Anzahl der Ereignisse, die nach diesen Filterkriterien herausgefiltert wurden. Verwenden Sie diese Metrik, um festzustellen, ob Ihre Zuordnung von Ereignisquellen Ereignisse ordnungsgemäß herausfiltert. Für Ereignisse, die den Filterkriterien entsprechen, gibt Lambda eine 0-Metrik aus.
+ `InvokedEventCount` – Die Anzahl der Ereignisse, die Ihre Lambda-Funktion aufgerufen haben. Verwenden Sie diese Metrik, um zu überprüfen, ob Ereignisse Ihre Funktion ordnungsgemäß aufrufen. Wenn ein Ereignis zu einem Funktionsfehler oder einer Drosselung führt, kann `InvokedEventCount` aufgrund automatischer Wiederholungsversuche mehrfach für dasselbe abgefragte Ereignis zählen.
**Warnung**
Zuordnung von Lambda-Ereignisquellen verarbeiten jedes Ereignis mindestens einmal und es kann zu einer doppelten Verarbeitung von Datensätzen kommen. Aus diesem Grund können Ereignisse in Metriken, die Ereigniszählungen beinhalten, mehrfach gezählt werden.
+ `FailedInvokeEventCount` – Die Anzahl der Ereignisse, mit denen Lambda versucht hat, Ihre Funktion aufzurufen, was jedoch fehlgeschlagen ist. Aufrufe können aus Gründen wie Netzwerkkonfigurationsproblemen, falschen Berechtigungen oder einer gelöschten Lambda-Funktion, Version oder einem Alias fehlschlagen. Wenn für Ihre Zuordnung von Ereignisquellen [partielle Batch-Antworten](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) aktiviert sind, enthält `FailedInvokeEventCount` jedes Ereignis mit einem nicht leeren `BatchItemFailures` in der Antwort.
**Anmerkung**
Der Zeitstempel für die `FailedInvokeEventCount`-Metrik steht für das Ende des Funktionsaufrufs. Dieses Verhalten unterscheidet sich von anderen Lambda-Aufruffehlermetriken, die zu Beginn des Funktionsaufrufs mit einem Zeitstempel versehen werden.
+ `DroppedEventCount` – Die Anzahl der Ereignisse, die Lambda aufgrund von Ablauf oder wiederholter Erschöpfung ausgab. Genauer gesagt ist dies die Anzahl der Datensätze, die die von Ihnen konfigurierten Werte für `MaximumRecordAgeInSeconds` oder `MaximumRetryAttempts` überschreiten. Wichtig ist, dass dies nicht die Anzahl der Datensätze beinhaltet, die aufgrund einer Überschreitung der Aufbewahrungseinstellungen Ihrer Ereignisquelle ablaufen. Verworfene Ereignisse schließen auch Ereignisse aus, die Sie bei einem [Ausfall an ein Ziel](invocation-async-retain-records.md) senden. Verwenden Sie diese Metrik, um einen zunehmenden Rückstand an Ereignissen zu erkennen.
+ `OnFailureDestinationDeliveredEventCount` – Bei Zuordnungen von Ereignisquellen mit konfiguriertem [Ausfallziel](invocation-async-retain-records.md), die Anzahl der Ereignisse, die an dieses Ziel gesendet wurden. Verwenden Sie diese Metrik, um Funktionsfehler im Zusammenhang mit Aufrufen von dieser Ereignisquelle zu überwachen. Wenn die Lieferung an das Ziel fehlschlägt, verarbeitet Lambda die Metriken wie folgt:
+ Lambda gibt die `OnFailureDestinationDeliveredEventCount`-Metrik nicht aus.
+ Für die `DestinationDeliveryFailures`-Metrik gibt Lambda eine 1 aus.
+ Für die `DroppedEventCount`-Metrik gibt Lambda eine Zahl aus, die der Anzahl der Ereignisse entspricht, bei denen die Übermittlung fehlgeschlagen ist.
+ `DeletedEventCount` – Die Anzahl der Ereignisse, die Lambda nach der Verarbeitung erfolgreich löscht. Wenn Lambda versucht, ein Ereignis zu löschen, dies jedoch fehlschlägt, gibt Lambda eine 0-Metrik aus. Verwenden Sie diese Metrik, um sicherzustellen, dass erfolgreich verarbeitete Ereignisse aus Ihrer Ereignisquelle gelöscht werden.
+ `CommittedEventCount`— Die Anzahl der Ereignisse, die Lambda nach der Verarbeitung erfolgreich festgeschrieben hat. Es handelt sich um eine Summe der Deltas des letzten und des aktuellen Offsets, das von jeder Partition in der Kafka-Ereignisquellenzuordnung vorgenommen wurde.
+ `PollingErrorCount`— Die Anzahl der Fehler, bei denen Lambda Anfragen von der Ereignisquelle nicht abfragen konnte. Lambda gibt diese Metrikdaten nur aus, wenn ein Fehler aufgetreten ist.
+ `InvokeErrorCount`— Die Anzahl der Fehler, bei denen Lambda Ihre Funktion nicht aufrufen konnte. Beachten Sie, dass es sich bei dem Aufruf um Datensätze im Batch handelt. Die Nummer steht auf Batch-Ebene, nicht auf Datensatzzählebene. Lambda gibt diese Metrikdaten nur aus, wenn ein Fehler aufgetreten ist.
+ `SchemaRegistryErrorCount`— Die Anzahl der Fehler, bei denen Lambda das Schema nicht abrufen oder mit dem Schema deserialisieren konnte. Lambda gibt diese Metrikdaten nur aus, wenn ein Fehler aufgetreten ist.
+ `CommitErrorCount`— Die Anzahl der Fehler, die Lambda nicht an den Kafka-Cluster übertragen konnte. Lambda gibt diese Metrikdaten nur aus, wenn ein Fehler aufgetreten ist.
+ `MaxOffsetLag`— Die maximale Anzahl von Offset-Lags (Unterschied zwischen den letzten Offsets und den bestätigten Offsets) für alle Partitionen in der Ereignisquellenzuordnung.
+ `SumOffsetLag`— Die Summe der Offset-Lags auf allen Partitionen in der Ereignisquellenzuordnung.
Wenn Ihre Zuordnung von Ereignisquellen deaktiviert ist, erhalten Sie keine Metriken zur Zuordnung von Ereignisquellen. Möglicherweise werden Ihnen auch fehlende Metriken angezeigt, wenn CloudWatch die Verfügbarkeit von Lambda beeinträchtigt ist.
# Arbeiten mit Lambda-Funktionsprotokollen
Überwacht Lambda-Funktionen AWS Lambda automatisch in Ihrem Namen, um Ihnen bei der Behebung von Fehlern zu helfen. Sie können Protokolle für Lambda-Funktionen mithilfe der Lambda-Konsole, der CloudWatch Konsole, der AWS Command Line Interface (AWS CLI) und der API anzeigen. CloudWatch Sie können Lambda auch so konfigurieren, dass Protokolle an Amazon S3 und Firehose gesendet werden.
Solange die [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion über die erforderlichen Berechtigungen verfügt, erfasst Lambda Protokolle für alle Anfragen, die von Ihrer Funktion bearbeitet werden, und sendet sie an Amazon CloudWatch Logs, das Standardziel. Sie können die Lambda-Konsole auch verwenden, um Amazon S3 oder Firehose als Protokollierungsziele zu konfigurieren.
+ **CloudWatch Logs** ist das Standard-Logging-Ziel für Lambda-Funktionen. CloudWatch Logs bietet Funktionen zur Anzeige und Analyse von Protokollen in Echtzeit und unterstützt die Erstellung von Metriken und Alarmen auf der Grundlage Ihrer Protokolldaten.
+ **Amazon S3** ist wirtschaftlich für die langfristige Speicherung, und Services wie Athena können zur Analyse von Protokollen verwendet werden. Die Latenz ist in der Regel höher.
+ **Firehose** bietet verwaltetes Streaming von Protokollen an verschiedene Ziele. Wenn Sie Protokolle an andere AWS Dienste (z. B. OpenSearch Service oder Redshift Data API) oder Plattformen von Drittanbietern (wie Datadog, New Relic oder Splunk) senden müssen, vereinfacht Firehose diesen Prozess durch die Bereitstellung vorgefertigter Integrationen. Sie können auch an benutzerdefinierte HTTP-Endpunkte streamen, ohne zusätzliche Infrastruktur einrichten zu müssen.
## Auswahl eines Serviceziels für das Senden von Protokollen
Berücksichtigen Sie bei der Auswahl eines Serviceziels für Funktionsprotokolle die folgenden wichtigen Faktoren:
+ **Das Kostenmanagement ist je nach Service unterschiedlich.** Amazon S3 bietet in der Regel die wirtschaftlichste Option für die Langzeitspeicherung, während CloudWatch Logs es Ihnen ermöglicht, Protokolle einzusehen, zu verarbeiten und Benachrichtigungen in Echtzeit einzurichten. Die Kosten für Firehose umfassen sowohl den Streamingservice als auch die Kosten für die von Ihnen konfigurierten Streamingziele.
+ **Die Analysefunktionen unterscheiden sich je nach Service.** CloudWatch Logs zeichnet sich durch eine hervorragende Echtzeitüberwachung aus und lässt sich nativ in andere CloudWatch Funktionen wie Logs Insights und Live Tail integrieren. Amazon S3 funktioniert gut mit Analysetools wie Athena und kann in verschiedene Services integriert werden, erfordert jedoch möglicherweise zusätzliche Einstellungen. Firehose vereinfacht das direkte Streaming zu bestimmten AWS Diensten (wie OpenSearch Service und Redshift Data API) und unterstützten Plattformen von Drittanbietern (wie Datadog und Splunk), indem vorgefertigte Integrationen bereitgestellt werden, wodurch der Konfigurationsaufwand potenziell reduziert wird.
+ **Einrichtung und Benutzerfreundlichkeit variieren je nach Service.** CloudWatch Logs ist das standardmäßige Protokollziel. Es funktioniert sofort ohne zusätzliche Konfiguration und ermöglicht die einfache Anzeige und Analyse von Protokollen über die CloudWatch Konsole. Wenn Sie Protokolle an Amazon S3 senden möchten, müssen Sie zunächst einige Einstellungen in der Lambda-Konsole vornehmen und Bucket-Berechtigungen konfigurieren. Wenn Sie Protokolle benötigen, die direkt an Dienste wie OpenSearch Service oder Analyseplattformen von Drittanbietern gesendet werden, kann Firehose diesen Prozess vereinfachen.
## Konfigurieren von Protokollzielen
AWS Lambda unterstützt mehrere Ziele für Ihre Funktionsprotokolle. In diesem Leitfaden werden die verfügbaren Protokollziele erläutert und Ihnen bei der Auswahl der für Ihre Anforderungen geeigneten Option geholfen. Unabhängig vom gewählten Ziel bietet Lambda Optionen zur Steuerung des Protokollformats, der Filterung und der Zustellung.
Lambda unterstützt sowohl JSON- als auch Klartextformate für die Protokolle Ihrer Funktion. Strukturierte JSON-Protokolle bieten eine verbesserte Suchbarkeit und ermöglichen eine automatisierte Analyse, während Klartextprotokolle einfach zu handhaben sind und potenziell geringere Speicherkosten verursachen. Sie können steuern, welche Protokolle Lambda an das von Ihnen gewählte Ziel sendet, indem Sie Protokollebenen für System- und Anwendungsprotokolle konfigurieren. Die Filterung hilft Ihnen, die Speicherkosten zu verwalten, und erleichtert das Auffinden relevanter Protokolleinträge beim Debuggen.
Ausführliche Anweisungen zur Einrichtung für jedes Ziel finden Sie in den folgenden Abschnitten:
+ [Senden von Lambda-Funktionsprotokollen an CloudWatch Logs](monitoring-cloudwatchlogs.md)
+ [Senden von Lambda-Funktionsprotokollen an Firehose](logging-with-firehose.md)
+ [Senden von Lambda-Funktionsprotokollen an Amazon S3](logging-with-s3.md)
## Konfigurieren erweiterter Protokollierungsoptionen für Lambda-Funktionen
Um Ihnen mehr Kontrolle über die Erfassung, Verarbeitung und Nutzung Ihrer Funktionsprotokolle zu geben, bietet Lambda die folgenden Optionen zur Protokollierungskonfiguration:
+ **Protokollformat** – Wählen Sie zwischen Klartext und einem strukturierten JSON-Format für die Protokolle Ihrer Funktion aus.
+ **Protokollebene** — Wählen Sie für strukturierte JSON-Logs die Detailebene der Logs aus, an die Lambda sendet CloudWatch`FATAL`, z. B.`ERROR`,`WARN`,`INFO`,`DEBUG`, und`TRACE`.
+ **Protokollgruppe** — wählen Sie die CloudWatch Protokollgruppe aus, an die Ihre Funktion Logs sendet.
Weitere Informationen zur Konfiguration erweiterter Protokollierungssteuerungen finden Sie in den folgenden Abschnitten:
+ [Konfiguration der JSON- und Klartext-Protokollformate](monitoring-cloudwatchlogs-logformat.md)
+ [Filterung auf Protokollebene](monitoring-cloudwatchlogs-log-level.md)
+ [Konfiguration von CloudWatch Protokollgruppen](monitoring-cloudwatchlogs-loggroups.md)
# Konfiguration der JSON- und Klartext-Protokollformate
Das Erfassen Ihrer Protokollausgaben als JSON-Schlüssel-Wert-Paare erleichtert das Suchen und Filtern beim Debuggen Ihrer Funktionen. Mit Protokollen im JSON-Format können Sie Ihren Protokollen auch Tags und Kontextinformationen hinzufügen. Das kann Ihnen bei der automatisierten Analyse großer Mengen von Protokolldaten helfen. Sofern Ihr Entwicklungsworkflow nicht auf vorhandenen Tools basiert, die Lambda-Protokolle im Klartext verarbeiten, empfehlen wir Ihnen, JSON als Protokollformat auszuwählen.
**Von Lambda verwaltete Instances**
Lambda Managed Instances unterstützen nur das JSON-Protokollformat. Wenn Sie eine Funktion für verwaltete Instanzen erstellen, konfiguriert Lambda das Protokollformat automatisch auf JSON, und Sie können es nicht in Klartext ändern. Weitere Informationen zu Managed Instances finden Sie unter. [Von Lambda verwaltete Instances](lambda-managed-instances.md)
Für alle von Lambda verwalteten Laufzeiten können Sie wählen, ob die Systemprotokolle Ihrer Funktion im unstrukturierten Klartext- oder CloudWatch JSON-Format an Logs gesendet werden. Systemprotokolle sind die von Lambda generierten Protokolle und werden manchmal auch als Plattformereignisprotokolle bezeichnet.
Wenn Sie für [unterstützte Laufzeiten](#monitoring-cloudwatchlogs-logformat-supported) eine der unterstützten integrierten Protokollierungsmethoden verwenden, kann Lambda auch die Anwendungsprotokolle Ihrer Funktion (die Protokolle, die Ihr Funktionscode generiert) im strukturierten JSON-Format ausgeben. Wenn Sie das Protokollformat Ihrer Funktion für diese Laufzeiten konfigurieren, gilt die von Ihnen ausgewählte Konfiguration sowohl für System- als auch für Anwendungsprotokolle.
Wenn Ihre Funktion für unterstützte Laufzeiten eine unterstützte Protokollierungsbibliothek oder -methode verwendet, müssen Sie keine Änderungen an Ihrem vorhandenen Code vornehmen, damit Lambda Protokolle in strukturiertem JSON erfasst.
**Anmerkung**
Durch die Verwendung der JSON-Protokollformatierung werden zusätzliche Metadaten hinzugefügt und Protokollmeldungen als JSON-Objekte kodiert, die eine Reihe von Schlüssel-Wert-Paaren enthalten. Aus diesem Grund kann die Größe der Protokollmeldungen Ihrer Funktion zunehmen.
## Unterstützte Laufzeiten und Protokollierungsmethoden
Lambda unterstützt derzeit die Option, strukturierte JSON-Anwendungsprotokolle für folgende Laufzeiten auszugeben.
| Sprache | Unterstützte Versionen |
| --- | --- |
| Java | Alle Java-Laufzeiten außer Java 8 auf Amazon Linux 1 |
| .NET | .NET 8 und höher |
| Node.js | Node.js 16 und höher |
| Python | Python 3.8 oder höher |
| Rust | – |
Damit Lambda die Anwendungsprotokolle Ihrer Funktion CloudWatch im strukturierten JSON-Format senden kann, muss Ihre Funktion die folgenden integrierten Protokollierungstools zur Ausgabe von Protokollen verwenden:
+ **Java**: Der `LambdaLogger` Logger oder Log4j2. Weitere Informationen finden Sie unter [Java-Lambda-Funktionen protokollieren und überwachen](java-logging.md).
+ **.NET**: Die `ILambdaLogger` Instanz auf dem Kontextobjekt. Weitere Informationen finden Sie unter [C\$1-Lambda-Funktionen protokollieren und überwachen](csharp-logging.md).
+ **Node.js** — Die Konsolenmethoden `console.trace``console.debug`,`console.log`,`console.info`,`console.error`, und`console.warn`. Weitere Informationen finden Sie unter [Node.js-Lambda-Funktionen protokollieren und überwachen](nodejs-logging.md).
+ **Python**: Die `logging` Standard-Python-Bibliothek. Weitere Informationen finden Sie unter [Python-Lambda-Funktionen protokollieren und überwachen](python-logging.md).
+ **Rust**: Die `tracing` Kiste. Weitere Informationen finden Sie unter [Rust-Lambda-Funktionen protokollieren und überwachen](rust-logging.md).
Für andere verwaltete Lambda-Laufzeiten unterstützt Lambda derzeit nur nativ die Erfassung von Systemprotokollen im strukturierten JSON-Format. Sie können jedoch weiterhin Anwendungsprotokolle zu jeder Laufzeit im strukturierten JSON-Format erfassen, indem Sie Protokollierungstools wie Powertools für AWS Lambda die Ausgabe von Protokollausgaben im JSON-Format verwenden.
## Standardprotokollformate
Derzeit ist das Standard-Protokollformat für alle Lambda-Laufzeiten das Klartextformat. Für Lambda Managed Instances ist das Protokollformat immer JSON und kann nicht geändert werden.
Wenn Sie bereits Logging-Bibliotheken wie Powertools für AWS Lambda die Generierung Ihrer Funktionsprotokolle im strukturierten JSON-Format verwenden, müssen Sie Ihren Code nicht ändern, wenn Sie die JSON-Protokollformatierung auswählen. Lambda codiert Protokolle, die bereits JSON-codiert sind, nicht doppelt, sodass die Anwendungsprotokolle Ihrer Funktion weiterhin wie zuvor erfasst werden.
## JSON-Format für Systemprotokolle
Wenn Sie das Protokollformat Ihrer Funktion als JSON konfigurieren, wird jedes Systemprotokollelement (Plattformereignis) als JSON-Objekt erfasst, das Schlüssel-Wert-Paare mit den folgenden Schlüsseln enthält:
+ `"time"` – die Uhrzeit, zu der die Protokollmeldung generiert wurde
+ `"type"` – die Art des Ereignisses, das protokolliert wird
+ `"record"` – der Inhalt der Protokollausgabe
Das Format des `"record"`-Werts hängt von der Art des protokollierten Ereignisses ab. Weitere Informationen finden Sie unter [Telemetrie-API `Event`-Objekttypen](telemetry-schema-reference.md#telemetry-api-events). Weitere Hinweise zu den Protokollebenen, die Systemprotokollereignissen zugewiesen sind, finden Sie unter [Zuordnung von Ereignissen auf Systemprotokollebene](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping).
Zum Vergleich zeigen die folgenden beiden Beispiele dieselbe Protokollausgabe sowohl im Klartext- als auch im strukturierten JSON-Format. Beachten Sie, dass Systemprotokollereignisse in den meisten Fällen mehr Informationen enthalten, wenn sie im JSON-Format ausgegeben werden, als wenn sie im Klartext ausgegeben werden.
**Example Klartext:**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example strukturiertes JSON:**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**Anmerkung**
Die [Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die Telemetrie-API](telemetry-api.md) gibt immer Plattformereignisse wie `START` und `REPORT` im JSON-Format aus. Die Konfiguration des Formats der Systemprotokolle, an die Lambda sendet, CloudWatch hat keinen Einfluss auf das Verhalten der Lambda-Telemetrie-API.
## JSON-Format für Anwendungsprotokolle
Wenn Sie das Protokollformat Ihrer Funktion als JSON konfigurieren, werden Anwendungsprotokollausgaben, die mit unterstützten Protokollierungsbibliotheken und -methoden geschrieben wurden, als JSON-Objekt erfasst, das Schlüssel-Wert-Paare mit folgenden Schlüsseln enthält.
+ `"timestamp"` – die Uhrzeit, zu der die Protokollmeldung generiert wurde
+ `"level"` – die der Meldung zugewiesene Protokollebene
+ `"message"` – der Inhalt der Protokollmeldung
+ `"requestId"` (Python, .NET und Node.js) oder `"AWSrequestId"` (Java) – die eindeutige Anforderungs-ID für den Funktionsaufruf
Abhängig von der Laufzeit und der Protokollierungsmethode, die Ihre Funktion verwendet, kann dieses JSON-Objekt auch zusätzliche Schlüsselpaare enthalten. Wenn Sie Node.js verwenden und Ihre Funktion beispielsweise `console`-Methoden nutzt, um Fehlerobjekte mit mehreren Argumenten zu protokollieren, enthält das JSON-Objekt zusätzliche Schlüssel-Wert-Paare mit den Schlüsseln `errorMessage`, `errorType` und `stackTrace`. Weitere Informationen zu JSON-formatierten Protokollen in verschiedenen Lambda-Laufzeiten finden Sie unter [Python-Lambda-Funktionen protokollieren und überwachen](python-logging.md), [Node.js-Lambda-Funktionen protokollieren und überwachen](nodejs-logging.md) und [Java-Lambda-Funktionen protokollieren und überwachen](java-logging.md).
**Anmerkung**
Der Schlüssel, den Lambda für den Zeitstempelwert verwendet, unterscheidet sich für Systemprotokolle und für Anwendungsprotokolle. Bei Systemprotokollen verwendet Lambda den Schlüssel `"time"`, um die Konsistenz mit der Telemetrie-API aufrechtzuerhalten. Bei Anwendungsprotokollen folgt Lambda den Konventionen der unterstützten Laufzeiten und verwendet `"timestamp"`.
Zum Vergleich zeigen die folgenden beiden Beispiele dieselbe Protokollausgabe sowohl im Klartext- als auch im strukturierten JSON-Format.
**Example Klartext:**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example strukturiertes JSON:**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## Festlegen des Protokollformats Ihrer Funktion
Um das Protokollformat für Ihre Funktion zu konfigurieren, können Sie die Lambda-Konsole oder die AWS Command Line Interface (AWS CLI) verwenden. Sie können das Protokollformat einer Funktion auch mithilfe der API-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, der [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)Ressource AWS Serverless Application Model (AWS SAM) und der CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)Ressource konfigurieren.
Das Ändern des Protokollformats Ihrer Funktion hat keine Auswirkungen auf bestehende Protokolle, die in CloudWatch Logs gespeichert sind. Nur neue Protokolle verwenden das aktualisierte Format.
Wenn Sie das Protokollformat Ihrer Funktion in JSON ändern und keine Protokollebene festlegen, setzt Lambda die Anwendungsprotokollebene und die Systemprotokollebene Ihrer Funktion automatisch auf INFO. Das bedeutet, dass Lambda nur Protokollausgaben der Stufe INFO und niedriger an CloudWatch Logs sendet. Weitere Informationen zur Filterung auf Anwendungs- und Systemprotokollebene finden Sie unter [Filterung auf Protokollebene](monitoring-cloudwatchlogs-log-level.md)
**Anmerkung**
Wenn das Protokollformat Ihrer Funktion auf Klartext gesetzt ist, ist die Standardeinstellung auf Protokollebene für Python-Laufzeiten WARN. Das bedeutet, dass Lambda nur Protokollausgaben der Stufe WARN und niedriger an CloudWatch Logs sendet. Wenn Sie das Protokollformat Ihrer Funktion in JSON ändern, ändert sich dieses Standardverhalten. Weitere Informationen zur Protokollierung in Python finden Sie unter [Python-Lambda-Funktionen protokollieren und überwachen](python-logging.md).
Bei Funktionen von Node.js, die EMF-Logs (Embedded Metric Format) ausgeben, kann die Änderung des Protokollformats Ihrer Funktion in JSON dazu führen, dass Ihre Metriken nicht erkannt CloudWatch werden können.
**Wichtig**
Wenn Ihre Funktion Powertools for AWS Lambda (TypeScript) oder die Open-Source-EMF-Clientbibliotheken zur Ausgabe von EMF-Protokollen verwendet, aktualisieren Sie Ihre [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) - und [EMF-Bibliotheken](https://www.npmjs.com/package/aws-embedded-metrics) auf die neuesten Versionen, um sicherzustellen, dass Ihre Protokolle weiterhin korrekt analysiert CloudWatch werden können. Wenn Sie zum JSON-Protokollformat wechseln, empfehlen wir Ihnen zudem, Tests durchzuführen, um die Kompatibilität mit den eingebetteten Metriken Ihrer Funktion sicherzustellen. Weitere Hinweise zu den Funktionen von node.js, die EMF-Protokolle ausgeben, finden Sie unter [Verwenden von Clientbibliotheken im Embedded Metric Format (EMF) mit strukturierten JSON-Protokollen](nodejs-logging.md#nodejs-logging-advanced-emf).
**So konfigurieren Sie das Protokollformat einer Funktion (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Auswählen einer Funktion
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 unter **Protokollinhalt** für **Protokollformat** entweder **Text** oder **JSON** aus.
1. Wählen Sie **Speichern**.
**So ändern Sie das Protokollformat einer vorhandenen 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 das Protokollformat einer vorhandenen Funktion zu ändern. Legen Sie die `LogFormat`-Option in `LoggingConfig` entweder auf `JSON` oder `Text` fest.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**So legen Sie das Protokollformat fest, wenn Sie eine Funktion erstellen (AWS CLI)**
+ Verwenden Sie die Option `--logging-config` im Befehl [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html), um das Protokollformat zu konfigurieren, wenn Sie eine neue Funktion erstellen. Legen Sie `LogFormat` auf `JSON` oder `Text` fest. Der folgende Beispielbefehl erstellt eine Node.js-Funktion, die Protokolle in strukturiertem JSON ausgibt.
Wenn Sie beim Erstellen einer Funktion kein Protokollformat angeben, verwendet Lambda das Standardprotokollformat für die von Ihnen ausgewählte Laufzeitversion. Informationen zu den Standard-Protokollierungsformaten finden Sie unter [Standardprotokollformate](#monitoring-cloudwatchlogs-format-default).
```
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 LogFormat=JSON
```
# Filterung auf Protokollebene
Lambda kann die Protokolle Ihrer Funktion filtern, sodass nur Protokolle mit einer bestimmten Detailebene oder niedriger an CloudWatch Logs gesendet werden. Sie können die Filterung auf Protokollebene separat für die Systemprotokolle Ihrer Funktion (die von Lambda generierten Protokolle) und Anwendungsprotokolle (die von Ihrem Funktionscode generierten Protokolle) konfigurieren.
Für [Unterstützte Laufzeiten und Protokollierungsmethoden](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported) müssen Sie keine Änderungen an Ihrem Funktionscode vornehmen, damit Lambda die Anwendungsprotokolle Ihrer Funktion filtert.
Für alle anderen Laufzeiten und Protokollierungsmethoden muss Ihr Funktionscode Protokollereignisse in `stdout` oder `stderr` als JSON-formatierte Objekte ausgeben, die ein Schlüssel-Wert-Paar mit dem Schlüssel `"level"` enthalten. Lambda interpretiert beispielsweise die folgende Ausgabe an `stdout` als ein Protokoll auf Ebene DEBUG.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
Wenn das Feld für den `"level"`-Wert ungültig ist oder fehlt, weist Lambda der Protokollausgabe die Ebene INFO zu. Damit Lambda das Zeitstempelfeld verwenden kann, müssen Sie die Zeit im gültigen [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)-Zeitstempelformat angeben. Wenn Sie keinen gültigen Zeitstempel angeben, weist Lambda dem Protokoll die Ebene INFO zu und fügt einen Zeitstempel für Sie hinzu.
Halten Sie sich bei der Benennung des Zeitstempelschlüssels an die Benennungskonventionen der Laufzeit, die Sie verwenden. Lambda unterstützt die meisten gängigen Namenskonventionen, die von den verwalteten Laufzeiten verwendet werden.
**Anmerkung**
Um die Filterung auf Protokollebene verwenden zu können, muss Ihre Funktion für die Verwendung des JSON-Protokollformats konfiguriert sein. Derzeit ist das Standard-Protokollformat für alle verwalteten Lambda-Laufzeiten das Klartextformat. Informationen zur Konfiguration des JASON-Protokollformats Ihrer Funktion finden Sie unter [Festlegen des Protokollformats Ihrer Funktion](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format).
Bei Anwendungsprotokollen (den durch Ihren Funktionscode generierten Protokollen) können Sie zwischen den folgenden Protokollebenen wählen.
| Protokollebene | Standardnutzung |
| --- | --- |
| TRACE (am detailliertesten) | Die detailliertesten Informationen, die verwendet werden, um den Ausführungspfad Ihres Codes nachzuverfolgen |
| DEBUG | Detaillierte Informationen für das System-Debugging |
| INFO | Meldungen, die den normalen Betrieb Ihrer Funktion erfassen |
| WARN | Meldungen über mögliche Fehler, die zu unerwartetem Verhalten führen können, wenn sie nicht behoben werden |
| ERROR | Meldungen über Probleme, die verhindern, dass der Code wie erwartet funktioniert |
| FATAL (am wenigsten Details) | Meldungen über schwerwiegende Fehler, die dazu führen, dass die Anwendung nicht mehr funktioniert |
Wenn Sie eine Protokollebene auswählen, sendet Lambda Protokolle auf dieser Ebene und niedriger an CloudWatch Logs. Wenn Sie beispielsweise die Anwendungsprotokollebene einer Funktion auf WARN setzen, sendet Lambda keine Protokollausgaben auf den Protokollebenen INFO und DEBUG. Die Standardebene des Anwendungsprotokolls für die Protokollfilterung ist INFO.
Wenn Lambda die Anwendungsprotokolle Ihrer Funktion filtert, wird Protokollmeldungen ohne Ebene die Protokollebene INFO zugewiesen.
Für Systemprotokolle (die vom Lambda-Service generierten Protokolle) können Sie zwischen den folgenden Protokollebenen wählen.
| Protokollebene | Usage |
| --- | --- |
| DEBUG (am detailliertesten) | Detaillierte Informationen für das System-Debugging |
| INFO | Meldungen, die den normalen Betrieb Ihrer Funktion erfassen |
| WARN (am wenigsten Details) | Meldungen über mögliche Fehler, die zu unerwartetem Verhalten führen können, wenn sie nicht behoben werden |
Wenn Sie eine Protokollebene auswählen, sendet Lambda Protokolle auf dieser Ebene und niedriger. Wenn Sie beispielsweise die Protokollebene einer Funktion auf INFO setzen, sendet Lambda keine Protokollausgaben auf der Protokollebene DEBUG.
Standardmäßig setzt Lambda die Protokollebene des Systems auf INFO. Mit dieser Einstellung sendet `"start"` und `"report"` protokolliert Lambda automatisch Nachrichten an CloudWatch. Um mehr oder weniger detaillierte Systemprotokolle zu erhalten, ändern Sie die Protokollebene in DEBUG oder WARN. Eine Liste der Protokollebenen, denen Lambda verschiedene Systemprotokollereignisse zuordnet, finden Sie unter [Zuordnung von Ereignissen auf Systemprotokollebene](#monitoring-cloudwatchlogs-log-level-mapping).
## Konfigurieren der Filterung auf Protokollebene
Um die Filterung auf Anwendungs- und Systemprotokollebene für Ihre Funktion zu konfigurieren, können Sie die Lambda-Konsole oder die AWS Command Line Interface () verwenden.AWS CLI Sie können die Protokollebene einer Funktion auch mithilfe der API-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, der [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)Ressource AWS Serverless Application Model (AWS SAM) und der CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)Ressource konfigurieren.
Beachten Sie, dass, wenn Sie die Protokollebene Ihrer Funktion in Ihrem Code festlegen, diese Einstellung Vorrang vor allen anderen von Ihnen konfigurierten Einstellungen auf Protokollebene hat. Wenn Sie beispielsweise die Python-Methode `logging` `setLevel()` verwenden, um die Protokollierungsebene Ihrer Funktion auf INFO zu setzen, hat diese Einstellung Vorrang vor der Einstellung WARN, die Sie mit der Lambda-Konsole konfigurieren.
**So konfigurieren Sie die Anwendungs- oder Systemprotokollebene (Konsole) einer vorhandenen Funktion**
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. Stellen Sie sicher, dass unter **Protokollinhalt** für **Protokollformat** **JSON** ausgewählt ist.
1. Wählen Sie mit den Optionsfeldern die gewünschte **Anwendungsprotokollebene** und die gewünschte **Systemprotokollebene** für Ihre Funktion aus.
1. Wählen Sie **Speichern**.
**So konfigurieren Sie die Anwendungs- oder Systemprotokollebene einer vorhandenen 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 Anwendungs- oder Systemprotokollebene einer vorhandenen Funktion zu ändern. Verwenden Sie `--logging-config`, um `SystemLogLevel` auf einen der Werte `DEBUG`, `INFO` oder `WARN` zu setzen. Legen Sie `ApplicationLogLevel` auf `DEBUG`, `INFO`, `WARN`, `ERROR` oder `FATAL` fest.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**So konfigurieren Sie die Filterung auf Protokollebene beim Erstellen einer Funktion**
+ Um die Filterung der Protokollebene zu konfigurieren, wenn Sie eine neue Funktion erstellen, verwenden Sie `--logging-config`, um die Tasten `SystemLogLevel` und `ApplicationLogLevel` im Befehl [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) zu setzen. Legen Sie `SystemLogLevel` auf `DEBUG`, `INFO` oder `WARN` fest. Legen Sie `ApplicationLogLevel` auf `DEBUG`, `INFO`, `WARN`, `ERROR` oder `FATAL` fest.
```
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 LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## Zuordnung von Ereignissen auf Systemprotokollebene
Für von Lambda generierte Protokollereignisse auf Systemebene ist in der folgenden Tabelle die Protokollebene definiert, die jedem Ereignis zugewiesen ist. Weitere Informationen zu den in der Tabelle aufgeführten Ereignissen finden Sie unter [Referenz zum `Event`-Schema der Lambda-Telemetrie-API](telemetry-schema-reference.md)
| Ereignisname | Bedingung | Zugewiesene Protokollebene |
| --- | --- | --- |
| initStart | „runtimeVersion“ ist festgelegt | INFO |
| initStart | „runtimeVersion“ ist nicht festgelegt | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | INFO |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | „runtimeVersion“ ist festgelegt | INFO |
| restoreStart | „runtimeVersion“ ist nicht festgelegt | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | INFO |
| restoreReport | status\$1=success | WARN |
| start | - | INFO |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| report | status=success | INFO |
| report | status\$1=success | WARN |
| extension | state=success | INFO |
| extension | state\$1=success | WARN |
| logSubscription | - | INFO |
| telemetrySubscription | - | INFO |
| logsDropped | - | WARN |
**Anmerkung**
Die [Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die Telemetrie-API](telemetry-api.md) gibt immer den vollständigen Satz von Plattformereignissen aus. Die Konfiguration der Ebene der Systemprotokolle, an die Lambda sendet, CloudWatch hat keinen Einfluss auf das Verhalten der Lambda-Telemetrie-API.
## Filterung auf Anwendungsprotokollebene mit benutzerdefinierten Laufzeiten
Wenn Sie die Filterung auf Anwendungsprotokollebene für Ihre Funktion konfigurieren, legt Lambda hinter den Kulissen die Anwendungsprotokollebene in der Laufzeit mithilfe der Umgebungsvariable `AWS_LAMBDA_LOG_LEVEL` fest. Lambda legt auch das Protokollformat Ihrer Funktion mithilfe der Umgebungsvariable `AWS_LAMBDA_LOG_FORMAT` fest. Sie können diese Variablen verwenden, um erweiterte Lambda-Protokollierungsoptionen in eine [benutzerdefinierte Laufzeit](runtimes-custom.md) zu integrieren.
Um Protokollierungseinstellungen für eine Funktion konfigurieren zu können, die eine benutzerdefinierte Laufzeit mit der Lambda-Konsole und Lambda verwendet AWS CLI APIs, konfigurieren Sie Ihre benutzerdefinierte Laufzeit so, dass sie den Wert dieser Umgebungsvariablen überprüft. Anschließend können Sie die Logger Ihrer Laufzeit gemäß dem von Ihnen ausgewählten Protokollformat und den von Ihnen ausgewählten Protokollebenen konfigurieren.
# 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)
# Senden von Lambda-Funktionsprotokollen an Firehose
Die Lambda-Konsole bietet jetzt die Möglichkeit, Funktionsprotokolle an Firehose zu senden. Dies ermöglicht das Echtzeit-Streaming Ihrer Protokolle an verschiedene von Firehose unterstützte Ziele, einschließlich Analysetools von Drittanbietern und benutzerdefinierten Endpunkten.
**Anmerkung**
Sie können Lambda-Funktionsprotokolle so konfigurieren, dass sie über die Lambda-Konsole, AWS CLI, AWS CloudFormation und alle AWS-SDKs an Firehose gesendet werden.
## Preisgestaltung
Informationen zu Preisen finden Sie unter [Amazon CloudWatch – Preise](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Erforderliche Berechtigungen für das Firehose-Protokollziel
Wenn Sie die Lambda-Konsole verwenden, um Firehose als Protokollziel Ihrer Funktion zu konfigurieren, benötigen Sie Folgendes:
1. Die [erforderlichen IAM-Berechtigungen](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) für die Verwendung von CloudWatch Logs mit Lambda.
1. Sie müssen [Abonnementfilter mit Firehose einrichten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). Dieser Filter definiert, welche Protokollereignisse für Ihren Firehose-Stream bereitgestellt werden.
## Senden von Lambda-Funktionsprotokollen an Firehose
In der Lambda-Konsole können Sie Funktionsprotokolle direkt an Firehose senden, nachdem Sie eine neue Funktion erstellt haben. Führen Sie dazu diese Schritte aus:
1. Melden Sie sich bei der AWS-Managementkonsole an, und öffnen Sie die Lambda-Konsole.
1. Wählen Sie den Namen Ihrer Funktion.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Wählen Sie die Registerkarte **Überwachungs- und Betriebs-Tools** aus.
1. Wählen Sie im Abschnitt „Protokollierungskonfiguration“ die Option **Bearbeiten** aus.
1. Wählen Sie im Abschnitt „Protokollinhalt“ ein Protokollformat aus.
1. Führen Sie im Abschnitt „Protokollziel“ die folgenden Schritte aus:
1. Wählen Sie einen Zielservice aus.
1. Wählen Sie **Neue Protokollgruppe erstellen** oder **Vorhandene Protokollgruppe** aus.
**Anmerkung**
Wenn Sie eine vorhandene Protokollgruppe für ein Firehose-Ziel auswählen, stellen Sie sicher, dass es sich bei der ausgewählten Protokollgruppe um einen `Delivery`-Protokollgruppentyp handelt.
1. Wählen Sie einen Firehose-Stream aus.
1. Die Protokollgruppe für CloudWatch `Delivery` wird angezeigt.
1. Wählen Sie **Speichern**.
**Anmerkung**
Wenn die in der Konsole angegebene IAM-Rolle nicht über die erforderlichen Berechtigungen verfügt, schlägt die Einrichtung des Ziels fehl. Um dieses Problem zu beheben, finden Sie unter „Erforderliche Berechtigungen für das Firehose-Protokollziel“ die erforderlichen Berechtigungen.
## Kontenübergreifende Protokollierung
Sie können Lambda so konfigurieren, dass Protokolle in einem anderen AWS-Konto an den Firehose-Bereitstellungsstream gesendet werden. Dies erfordert die Einrichtung eines Ziels und die Konfiguration der entsprechenden Berechtigungen in beiden Konten.
Detaillierte Anweisungen zur Einrichtung der kontoübergreifenden Protokollierung, einschließlich der erforderlichen IAM-Rollen und -Richtlinien, finden Sie unter [Einrichten eines neuen kontoübergreifenden Abonnements](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) in der CloudWatch-Logs-Dokumentation.
# Senden von Lambda-Funktionsprotokollen an Amazon S3
Sie können Ihre Lambda-Funktion so konfigurieren, dass Protokolle mithilfe der Lambda-Konsole direkt an Amazon S3 gesendet werden. Dieses Feature bietet eine kostengünstige Lösung für die langfristige Speicherung von Protokollen und ermöglicht leistungsstarke Analyseoptionen mithilfe von Services wie Athena.
**Anmerkung**
Sie können Lambda-Funktionsprotokolle so konfigurieren, dass sie über die Lambda-Konsole, AWS CLI, AWS CloudFormation und alle AWS-SDKs an Amazon S3 gesendet werden.
## Preisgestaltung
Informationen zu Preisen finden Sie unter [Amazon CloudWatch – Preise](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Erforderliche Berechtigungen für das Amazon-S3-Protokollziel
Wenn Sie die Lambda-Konsole verwenden, um Amazon S3 als Protokollziel Ihrer Funktion zu konfigurieren, benötigen Sie Folgendes:
1. Die [erforderlichen IAM-Berechtigungen](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) für die Verwendung von CloudWatch Logs mit Lambda.
1. Zu … [Einrichten eines CloudWatch-Logs-Abonnementfilters, um Lambda-Funktionsprotokolle an Amazon S3 zu senden](#using-cwl-subscription-filter-lambda-s3). Dieser Filter definiert, welche Protokollereignisse für Ihren Amazon-S3-Bucket bereitgestellt werden.
## Einrichten eines CloudWatch-Logs-Abonnementfilters, um Lambda-Funktionsprotokolle an Amazon S3 zu senden
Um Protokolle von CloudWatch Logs an Amazon S3 zu senden, müssen Sie einen Abonnementfilter erstellen. Dieser Filter definiert, welche Protokollereignisse für Ihren Amazon-S3-Bucket bereitgestellt werden. Ihr Amazon-S3-Bucket muss sich in derselben Region befinden wie Ihre Protokollgruppe.
### So erstellen Sie einen Abonnementfilter für Amazon S3
1. Erstellen Sie einen Amazon-Simple-Storage-Service-(Amazon S3)-Bucket. Wir empfehlen, dass Sie einen Bucket verwenden, der speziell für CloudWatch Logs erstellt wurde. Wenn Sie jedoch einen vorhandenen Bucket verwenden möchten, gehen Sie direkt zu Schritt 2.
Führen Sie den folgenden Befehl aus, und ersetzen Sie die Platzhalter-Region mit der Region, die Sie verwenden möchten:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**Anmerkung**
`amzn-s3-demo-bucket2` ist ein Beispiel für den Namen eines Amazon-S3-Buckets. Er ist *reserviert*. Damit dieses Verfahren funktioniert, müssen Sie ihn durch den eindeutigen Namen Ihres Amazon-S3-Buckets ersetzen.
Das Folgende ist Ausgabebeispiel:
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Berechtigung erteilt, Daten an Ihren Amazon-S3-Bucket zu senden. Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel vom Typ „aws:SourceArn“, um das Confused-Deputy-Problem zu vermeiden. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html).
1. Verwenden Sie einen Text-Editor zum Erstellen einer Vertrauensrichtlinie in einer Datei `~/TrustPolicyForCWL.json` wie folgt:
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Verwenden Sie den Befehl create-role, um die IAM-Rolle zu erstellen und die Datei mit der Vertrauensrichtlinie anzugeben. Notieren Sie den zurückgegebenen Wert Role.Arn, da Sie ihn in einem späteren Schritt benötigen:
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs an Ihrem Konto durchführen darf. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Berechtigungsrichtlinie in einer Datei `~/PermissionsForCWL.json`:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
Verknüpfen Sie die Berechtigungsrichtlinie mit dem folgenden Befehl `put-role-policy` mit der Rolle:
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. Erstellen Sie eine `Delivery`-Protokollgruppe oder verwenden Sie eine vorhandene `Delivery`-Protokollgruppe.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter` zum Einrichten des Ziels
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Senden von Lambda-Funktionsprotokollen an Amazon S3
In der Lambda-Konsole können Sie Funktionsprotokolle direkt an Amazon S3 senden, nachdem Sie eine neue Funktion erstellt haben. Führen Sie dazu diese Schritte aus:
1. Melden Sie sich bei der AWS-Managementkonsole an, und öffnen Sie die Lambda-Konsole.
1. Wählen Sie den Namen Ihrer Funktion.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Wählen Sie die Registerkarte **Überwachungs- und Betriebstools** aus.
1. Wählen Sie im Abschnitt „Protokollierungskonfiguration“ die Option **Bearbeiten** aus.
1. Wählen Sie im Abschnitt „Protokollinhalt“ ein Protokollformat aus.
1. Führen Sie im Abschnitt „Protokollziel“ die folgenden Schritte aus:
1. Wählen Sie einen Zielservice aus.
1. Wählen Sie **Neue Protokollgruppe erstellen** oder **Vorhandene Protokollgruppe** aus.
**Anmerkung**
Wenn Sie eine vorhandene Protokollgruppe für ein Amazon-S3-Ziel auswählen, stellen Sie sicher, dass es sich bei der ausgewählten Protokollgruppe um einen `Delivery`-Protokollgruppentyp handelt.
1. Wählen Sie einen Amazon-S3-Bucket als Zielort für Ihre Funktionsprotokolle.
1. Die Protokollgruppe für CloudWatch `Delivery` wird angezeigt.
1. Wählen Sie **Speichern**.
**Anmerkung**
Wenn die in der Konsole angegebene IAM-Rolle nicht über die erforderlichen Berechtigungen verfügt, schlägt die Einrichtung des Ziels fehl. Informationen zur Behebung dieses Problems finden Sie unter [Erforderliche Berechtigungen für das Amazon-S3-Protokollziel](#logging-s3-permissions).
## Kontoübergreifende Protokollierung
Sie können Lambda so konfigurieren, dass Protokolle in einem anderen AWS-Konto an ein Amazon-S3-Bucket gesendet werden. Dies erfordert die Einrichtung eines Ziels und die Konfiguration der entsprechenden Berechtigungen in beiden Konten.
Detaillierte Anweisungen zur Einrichtung der kontoübergreifenden Protokollierung, einschließlich der erforderlichen IAM-Rollen und -Richtlinien, finden Sie unter [Einrichten eines neuen kontoübergreifenden Abonnements](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) in der CloudWatch-Logs-Dokumentation.
# Protokollieren von AWS Lambda API-Aufrufen mit AWS CloudTrail
AWS Lambda ist in einen Dienst integriert [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), der eine Aufzeichnung der von einem Benutzer, einer Rolle oder einem ausgeführten Aktionen bereitstellt AWS-Service. CloudTrail erfasst API-Aufrufe für Lambda als Ereignisse. Zu den erfassten Aufrufen gehören Aufrufe über die Lambda-Konsole und Codeaufrufe der Lambda-API-Operationen. Anhand der von gesammelten Informationen können Sie die Anfrage CloudTrail, die an Lambda gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, wann sie gestellt wurde, und weitere Details ermitteln.
Jeder Ereignis- oder Protokolleintrag enthält Informationen zu dem Benutzer, der die Anforderung generiert hat. Die Identitätsinformationen unterstützen Sie bei der Ermittlung der folgenden Punkte:
+ Ob die Anforderung mit Anmeldeinformationen des Root-Benutzers oder des Benutzers gestellt wurde.
+ Die Anforderung wurde im Namen eines IAM-Identity-Center-Benutzers erstellt.
+ Gibt an, ob die Anforderung mit temporären Sicherheitsanmeldeinformationen für eine Rolle oder einen Verbundbenutzer gesendet wurde.
+ Ob die Anforderung aus einem anderen AWS-Service gesendet wurde.
CloudTrail ist in Ihrem aktiv AWS-Konto , wenn Sie das Konto erstellen, und Sie haben automatisch Zugriff auf den CloudTrail **Eventverlauf**. Der CloudTrail **Ereignisverlauf** bietet eine einsehbare, durchsuchbare, herunterladbare und unveränderliche Aufzeichnung der aufgezeichneten Verwaltungsereignisse der letzten 90 Tage in einem. AWS-Region Weitere Informationen finden Sie im *AWS CloudTrail Benutzerhandbuch* unter [Arbeiten mit dem CloudTrail Ereignisverlauf](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). Für die Anzeige des **Ereignisverlaufs CloudTrail** fallen keine Gebühren an.
Für eine fortlaufende Aufzeichnung der Ereignisse in AWS-Konto den letzten 90 Tagen erstellen Sie einen Trail- oder [CloudTrailLake-Event-Datenspeicher](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**CloudTrail Pfade**
Ein *Trail* ermöglicht CloudTrail die Übermittlung von Protokolldateien an einen Amazon S3 S3-Bucket. Alle mit dem erstellten Pfade AWS-Managementkonsole sind regionsübergreifend. Sie können mithilfe von AWS CLI einen Einzel-Region- oder einen Multi-Region-Trail erstellen. Es wird empfohlen, einen Trail mit mehreren Regionen zu erstellen, da Sie alle Aktivitäten AWS-Regionen in Ihrem Konto erfassen. Wenn Sie einen Einzel-Region-Trail erstellen, können Sie nur die Ereignisse anzeigen, die im AWS-Region des Trails protokolliert wurden. Weitere Informationen zu Trails finden Sie unter [Erstellen eines Trails für Ihr AWS-Konto](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) und [Erstellen eines Trails für eine Organisation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) im *AWS CloudTrail -Benutzerhandbuch*.
Sie können eine Kopie Ihrer laufenden Verwaltungsereignisse kostenlos an Ihren Amazon S3 S3-Bucket senden, CloudTrail indem Sie einen Trail erstellen. Es fallen jedoch Amazon S3 S3-Speichergebühren an. Weitere Informationen zur CloudTrail Preisgestaltung finden Sie unter [AWS CloudTrail Preise](https://aws.amazon.com/cloudtrail/pricing/). Informationen zu Amazon-S3-Preisen finden Sie unter [Amazon S3 – Preise](https://aws.amazon.com/s3/pricing/).
**CloudTrail Datenspeicher für Ereignisse in Lake**
CloudTrail Mit *Lake* können Sie SQL-basierte Abfragen für Ihre Ereignisse ausführen. CloudTrail [Lake konvertiert bestehende Ereignisse im zeilenbasierten JSON-Format in das Apache ORC-Format.](https://orc.apache.org/) ORC ist ein spaltenförmiges Speicherformat, das für den schnellen Abruf von Daten optimiert ist. Die Ereignisse werden in *Ereignisdatenspeichern* zusammengefasst, bei denen es sich um unveränderliche Sammlungen von Ereignissen handelt, die auf Kriterien basieren, die Sie mit Hilfe von [erweiterten Ereignisselektoren](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors) auswählen. Die Selektoren, die Sie auf einen Ereignisdatenspeicher anwenden, steuern, welche Ereignisse bestehen bleiben und für Sie zur Abfrage verfügbar sind. *Weitere Informationen zu CloudTrail Lake finden Sie unter [Arbeiten mit AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) im AWS CloudTrail Benutzerhandbuch.*
CloudTrail Für das Speichern und Abfragen von Ereignisdaten in Lake fallen Kosten an. Beim Erstellen eines Ereignisdatenspeichers wählen Sie die [Preisoption](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) aus, die für den Ereignisdatenspeicher genutzt werden soll. Die Preisoption bestimmt die Kosten für die Erfassung und Speicherung von Ereignissen sowie die standardmäßige und maximale Aufbewahrungsdauer für den Ereignisdatenspeicher. Weitere Informationen zur Preisgestaltung finden Sie unter CloudTrail [AWS CloudTrail Preisgestaltung](https://aws.amazon.com/cloudtrail/pricing/).
## Lambda-Datenereignisse in CloudTrail
[Datenereignisse](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) liefern Informationen über die Ressourcenoperationen, die auf oder in einer Ressource ausgeführt werden (z. B. Lesen oder Schreiben in ein Amazon-S3-Objekt). Sie werden auch als Vorgänge auf Datenebene bezeichnet. Datenereignisse sind oft Aktivitäten mit hohem Volume. Standardmäßig werden die meisten Datenereignisse CloudTrail nicht protokolliert, und der CloudTrail **Ereignisverlauf** zeichnet sie nicht auf.
Ein CloudTrail Datenereignis, das standardmäßig für unterstützte Dienste protokolliert wird, ist`LambdaESMDisabled`. Weitere Informationen zur Verwendung dieses Ereignisses zur Behebung von Problemen mit Lambda-Zuordnungen von Ereignisquellen finden Sie unter [Wird CloudTrail zur Fehlerbehebung bei deaktivierten Lambda-Ereignisquellen verwendet](#cloudtrail-ESM-troubleshooting).
Für Datenereignisse werden zusätzliche Gebühren fällig. Weitere Informationen zur CloudTrail Preisgestaltung finden Sie unter [AWS CloudTrail Preisgestaltung](https://aws.amazon.com/cloudtrail/pricing/).
Sie können Datenereignisse für den `AWS::Lambda::Function` Ressourcentyp mithilfe der CloudTrail Konsole oder CloudTrail API-Operationen protokollieren. AWS CLI Weitere Informationen zum Protokollieren von Datenereignissen finden Sie unter [Protokollieren von Datenereignissen mit dem AWS-Managementkonsole](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) und [Protokollieren von Datenereignissen mit dem AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) im *AWS CloudTrail -Benutzerhandbuch*.
In der folgenden Tabelle ist der Lambda-Ressourcentyp aufgeführt, für die Sie Datenereignisse protokollieren können. In der Spalte **Datenereignistyp (Konsole)** wird der Wert angezeigt, den Sie in der Liste **Datenereignistyp** auf der CloudTrail Konsole auswählen können. In der **Wertspalte resources.type wird** der `resources.type` Wert angezeigt, den Sie bei der Konfiguration erweiterter Event-Selektoren mithilfe von oder angeben würden. AWS CLI CloudTrail APIs In der CloudTrail Spalte ** APIs Protokollierte Daten werden** die API-Aufrufe angezeigt, die CloudTrail für den Ressourcentyp protokolliert wurden.
| Typ des Datenereignisses (Konsole) | resources.type-Wert | Daten, die APIs protokolliert wurden CloudTrail |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
Sie können erweiterte Event-Selektoren so konfigurieren, dass sie nach den Feldern `eventName`, `readOnly` und `resources.ARN` filtern, sodass nur die Ereignisse protokolliert werden, die für Sie wichtig sind. Das folgende Beispiel ist die JSON-Ansicht einer Datenereigniskonfiguration, die nur Ereignisse für eine bestimmte Funktion protokolliert. Weitere Informationen zu diesen Kontingenten finden Sie unter [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) in der*AWS CloudTrail -API-Referenz*.
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## Lambda-Management-Ereignisse in CloudTrail
[Verwaltungsereignisse](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) enthalten Informationen zu Verwaltungsvorgängen, die an Ressourcen in Ihrem AWS-Konto ausgeführt werden. Sie werden auch als Vorgänge auf Steuerebene bezeichnet. In der Standardeinstellung werden Verwaltungsereignisse CloudTrail protokolliert.
Lambda unterstützt die Protokollierung der folgenden Aktionen als Verwaltungsereignisse in CloudTrail Protokolldateien.
**Anmerkung**
In der CloudTrail Protokolldatei `eventName` können sie Datums- und Versionsinformationen enthalten, sie beziehen sich jedoch immer noch auf dieselbe öffentliche API-Aktion. Zum Beispiel erscheint die Aktion `GetFunction` als `GetFunction20150331v2`. Der folgende Liste gibt an, wann sich der Ereignisname vom API-Aktionsnamen unterscheidet.
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)(Name des Ereignisses:`AddPermission20150331v2`)
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)(Name des Ereignisses:`CreateAlias20150331`)
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)(Name des Ereignisses:`CreateEventSourceMapping20150331`)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)(Name des Ereignisses:`CreateFunction20150331`)
(Die `Environment`- und `ZipFile`-Parameter fließen nicht in die CloudTrail -Protokolle für `CreateFunction` mit ein.)
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)(Name des Ereignisses:`DeleteAlias20150331`)
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)(Name des Ereignisses:`DeleteEventSourceMapping20150331`)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)(Name des Ereignisses:`DeleteFunction20150331`)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)(Name des Ereignisses:`DeleteFunctionConcurrency20171031`)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)(Name des Ereignisses:`GetAlias20150331`)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html)(Name des Ereignisses:`PublishLayerVersion20181031`)
(Der `ZipFile` Parameter wird in den CloudTrail Protokollen für weggelassen`PublishLayerVersion`.)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)(Name des Ereignisses:`PublishVersion20150331`)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)(Name des Ereignisses:`PutFunctionConcurrency20171031`)
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html)(Name des Ereignisses:`RemovePermission20150331v2`)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)(Name des Ereignisses:`TagResource20170331v2`)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)(Name des Ereignisses:`UntagResource20170331v2`)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)(Name des Ereignisses:`UpdateAlias20150331`)
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)(Name des Ereignisses:`UpdateEventSourceMapping20150331`)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)(Name des Ereignisses:`UpdateFunctionCode20150331v2`)
(Der `ZipFile` Parameter wird in den CloudTrail Protokollen für weggelassen`UpdateFunctionCode`.)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)(Name des Ereignisses:`UpdateFunctionConfiguration20150331v2`)
(Der `Environment` Parameter wird in den CloudTrail Protokollen für weggelassen`UpdateFunctionConfiguration`.)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## Wird CloudTrail zur Fehlerbehebung bei deaktivierten Lambda-Ereignisquellen verwendet
Wenn Sie den Status einer Ereignisquellenzuordnung mithilfe der [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API-Aktion ändern, wird der API-Aufruf als Verwaltungsereignis protokolliert. CloudTrail Zuordnungen von Ereignisquellen können aufgrund von Fehlern auch direkt in den `Disabled`-Status übergehen.
Für die folgenden Dienste veröffentlicht Lambda das `LambdaESMDisabled` Datenereignis, CloudTrail wenn Ihre Ereignisquelle in den Status Deaktiviert übergeht:
+ Amazon-Simple-Queue-Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
Lambda unterstützt dieses Ereignis nicht für andere Ereignisquellen-Zuordnungstypen.
Um Benachrichtigungen zu erhalten, wenn Ereignisquellenzuordnungen für unterstützte Dienste in den `Disabled` Status wechseln, richten Sie in Amazon einen Alarm ein, der das `LambdaESMDisabled` CloudTrail Ereignis CloudWatch verwendet. Weitere Informationen zum Einrichten eines CloudWatch Alarms finden Sie unter [ CloudWatch Alarme für CloudTrail Ereignisse erstellen: Beispiele](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html).
Die `serviceEventDetails`-Entität in der `LambdaESMDisabled`-Ereignismeldung enthält einen der folgenden Fehlercodes.
**`RESOURCE_NOT_FOUND`**
Die in der Anforderung angegebene Ressource ist nicht vorhanden.
**`FUNCTION_NOT_FOUND`**
Die an die Ereignisquelle angefügte Funktion ist nicht vorhanden.
**`REGION_NAME_NOT_VALID`**
Ein Regionsname, der der Ereignisquelle oder -funktion zur Verfügung gestellt wird, ist ungültig.
**`AUTHORIZATION_ERROR`**
Es wurden keine Berechtigungen festgelegt oder sie wurden falsch konfiguriert.
**`FUNCTION_IN_FAILED_STATE`**
Der Funktionscode wird nicht kompiliert, hat eine nicht wiederherstellbare Ausnahme festgestellt oder eine fehlerhafte Bereitstellung ist aufgetreten.
## Beispiele für Lambda-Ereignisse
Ein Ereignis stellt eine einzelne Anfrage aus einer beliebigen Quelle dar und enthält Informationen über den angeforderten API-Vorgang, Datum und Uhrzeit des Vorgangs, Anforderungsparameter usw. CloudTrail Protokolldateien sind kein geordneter Stack-Trace der öffentlichen API-Aufrufe, sodass Ereignisse nicht in einer bestimmten Reihenfolge angezeigt werden.
Das folgende Beispiel zeigt CloudTrail Protokolleinträge für die `DeleteFunction` Aktionen `GetFunction` und.
**Anmerkung**
Die `eventName` kann Datums- und Versionsinformationen enthalten, wie z. B. die `"GetFunction20150331"`, aber sie bezieht sich immer noch auf dieselbe öffentliche API.
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
Informationen zu CloudTrail Datensatzinhalten finden Sie im *AWS CloudTrail Benutzerhandbuch* unter [CloudTrailDatensatzinhalte](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html).
# Visualisieren Sie Lambda-Funktionsaufrufe mit AWS X-Ray
Sie können AWS X-Ray es verwenden, um die Komponenten Ihrer Anwendung zu visualisieren, Leistungsengpässe zu identifizieren und Anfragen zu beheben, die zu einem Fehler geführt haben. Ihre Lambda-Funktionen senden Ablaufverfolgungs-Daten an X-Ray und X-Ray verarbeitet die Daten, um eine Service-Map und durchsuchbare Ablaufverfolgungs-Zusammenfassungen zu generieren.
Lambda unterstützt zwei Nachverfolgungs-Modi für X-Ray: `Active` und `PassThrough`. Mit der `Active`-Nachverfolgung erstellt Lambda automatisch Nachverfolgungssegmente für Funktionsaufrufe und sendet diese an X-Ray. Der `PassThrough`-Modus hingegen leitet den Nachverfolgungskontext einfach an Downstream-Services weiter. Wenn Sie die `Active`-Nachverfolgung für Ihre Funktion aktiviert haben, sendet Lambda automatisch Nachverfolgungen für Stichprobenanfragen an X-Ray. Normalerweise entscheidet ein Upstream-Service, wie beispielsweise Amazon API Gateway oder eine auf Amazon EC2 gehostete Anwendung, die mit dem X-Ray-SDK instrumentiert ist, ob eingehende Anfragen protokolliert werden sollen, und fügt diese Entscheidung als Nachverfolgungs-Header hinzu. Lambda verwendet diesen Header, um zu entscheiden, ob Nachverfolgungen gesendet werden sollen oder nicht. Traces von Upstream-Nachrichtenproduzenten wie Amazon SQS werden automatisch mit Traces von nachgeschalteten Lambda-Funktionen verknüpft, sodass eine end-to-end Ansicht der gesamten Anwendung entsteht. Weitere Informationen finden Sie unter [Ablaufverfolgung ereignisgesteuerter Anwendungen](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html) im *AWS X-Ray -Entwicklerhandbuch*.
**Anmerkung**
X-Ray Tracing wird derzeit nicht für Lambda-Funktionen mit Amazon Managed Streaming für Apache Kafka (Amazon MSK), selbstverwaltetem Apache Kafka, Amazon MQ mit ActiveMQ und RabbitMQ oder Zuordnungen von Amazon-DocumentDB-Ereignisquellen unterstützt.
Gehen Sie folgendermaßen vor, um die aktive Nachverfolgung Ihrer Lambda-Funktion mit der Konsole umzuschalten:
**So aktivieren Sie die aktive Nachverfolgung**
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 **Configuration** (Konfiguration) und dann **Monitoring and operations tools** (Überwachungs- und Produktionstools).
1. Wählen Sie unter **Zusätzliche Überwachungstools** die Option **Bearbeiten** aus.
1. Wählen Sie unter **CloudWatch Anwendungssignale und AWS X-Ray** die Option **Enable** for **Lambda Service Traces** aus.
1. Wählen Sie **Speichern**.
Ihre Funktion benötigt die Berechtigung zum Hochladen von Trace-Daten zu X-Ray. Wenn Sie die aktive Nachverfolgung in der Lambda-Konsole aktivieren, fügt Lambda der [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion die erforderlichen Berechtigungen hinzu. Andernfalls fügen Sie die [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)Richtlinie der Ausführungsrolle hinzu.
X-Ray verfolgt nicht alle Anfragen an Ihre Anwendung nach. X-Ray wendet einen Sampling-Algorithmus an, um sicherzustellen, dass die Nachverfolgung effizient ist, und stellt dennoch ein repräsentatives Beispiel aller Anfragen bereit. Die Samplingrate beträgt 1 Anforderung pro Sekunde und 5 Prozent aller weiteren Anforderungen. Sie können die X-Ray-Samplingrate nicht für Ihre Funktionen konfigurieren.
## Grundlegendes zu X-Ray-Ablaufverfolgungen
In X-Ray, zeichnet eine *Ablaufverfolgung* Informationen zu einer Anforderung auf, die von einem oder mehreren *Services* verarbeitet wird. Lambda zeichnet 2 Segmente pro Trace auf, wodurch zwei Knoten im Dienstgraphen entstehen. In der folgenden Abbildung werden diese beiden Knoten hervorgehoben:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/xray-servicemap-function.png)
Der erste Knoten auf der linken Seite stellt den Lambda-Service dar, der die Aufrufanforderung empfängt. Der zweite Knoten stellt Ihre spezifische Lambda-Funktion dar.
Das für den Lambda-Dienst `AWS::Lambda` aufgezeichnete Segment umfasst alle Schritte, die zur Vorbereitung der Lambda-Ausführungsumgebung erforderlich sind. Dazu gehören das Scheduling der MicroVM, das Erstellen oder Aufheben des Einfrierens einer Ausführungsumgebung mit den von Ihnen konfigurierten Ressourcen sowie das Herunterladen Ihres Funktionscodes und aller Schichten.
Das `AWS::Lambda::Function`-Segment bezieht sich auf die Arbeit, die von der Funktion geleistet wird.
**Anmerkung**
AWS implementiert derzeit Änderungen am Lambda-Service. Aufgrund dieser Änderungen können geringfügige Unterschiede in Struktur und Inhalt der Systemprotokollmeldungen und Trace-Segmente auftreten, die von verschiedenen Lambda-Funktionen in Ihrem AWS-Konto.
Diese Änderung betrifft die Teilsegmente des Funktionssegments. In den folgenden Abschnitten werden sowohl das alte als auch das neue Format für diese Teilsegmente beschrieben.
Diese Änderungen werden in den kommenden Wochen umgesetzt, und alle Funktionen AWS-Regionen außer China und den GovCloud Regionen werden auf die Verwendung der Protokollnachrichten und Trace-Segmente im neuen Format umgestellt.
**AWS X-Ray Lambda-Segmentstruktur im alten Stil**
Die herkömmliche X-Ray-Struktur für das `AWS::Lambda`-Segment sieht wie folgt aus:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
In diesem Format hat das Funktionssegment Untersegmente für `Initialization`, `Invocation` und `Overhead`. Nur für [Lambda SnapStart](snapstart.md) gibt es auch ein Teilsegment `Restore` (in dieser Abbildung nicht dargestellt).
Das `Initialization`-Teilsegment stellt die Init-Phase des Lebenszyklus der Lambda-Ausführungsumgebung dar. In dieser Phase initialisiert Lambda Erweiterungen, initialisiert die Laufzeit und führt den Initialisierungscode der Funktion aus.
Das `Invocation`-Teilsegment stellt die Aufrufphase dar, in welcher der Lambda-Funktionshandler aufgerufen wird. Dies beginnt mit der Laufzeit- und Erweiterungsregistrierung und endet, wenn die Laufzeit bereit ist, die Antwort zu senden.
[( SnapStart Nur Lambda) Das `Restore` Untersegment zeigt die Zeit, die Lambda benötigt, um einen Snapshot wiederherzustellen, die Laufzeit zu laden und alle Runtime-Hooks nach der Wiederherstellung auszuführen.](snapstart-runtime-hooks.md) Der Prozess der Wiederherstellung von Snapshots kann Zeit beinhalten, die für Aktivitäten außerhalb der MicroVM aufgewendet wird. Diese Zeit wird im `Restore`-Untersegment erfasst. Die Zeit, die Sie außerhalb der microVM für die Wiederherstellung eines Snapshots aufwenden, wird Ihnen nicht in Rechnung gestellt.
Das `Overhead`-Teilsegment stellt die Phase dar, die zwischen dem Zeitpunkt, zu dem die Laufzeit die Antwort sendet, und dem Signal für den nächsten Aufruf auftritt. Während dieser Zeit beendet die Laufzeit alle Aufgaben im Zusammenhang mit einem Aufruf und bereitet sich auf das Einfrieren der Sandbox vor.
**Wichtig**
Sie können das X-Ray-SDK verwenden, um das `Invocation`-Teilsegment mit zusätzlichen Teilsegmenten für nachgeschaltete Aufrufe, Anmerkungen und Metadaten zu erweitern. Sie können nicht direkt auf das Funktionssegment zugreifen oder Arbeiten außerhalb des Handler-Aufruffunktionsbereichs aufzeichnen.
Weitere Informationen zu den Phasen der Lambda-Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
Das folgende Diagramm zeigt ein Beispiel für einen Trace mit der alten X-Ray-Struktur.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Beachten Sie die beiden Segmente im Beispiel. Beide heißen **my-function**, aber einer hat einen Ursprung von `AWS::Lambda` und der andere hat einen Ursprung von `AWS::Lambda::Function`. Wenn das `AWS::Lambda`-Segment einen Fehler anzeigt, hatte der Lambda-Service ein Problem. Wenn das `AWS::Lambda::Function`-Segment einen Fehler anzeigt, ist bei Ihrer Funktion ein Problem aufgetreten.
**Anmerkung**
Gelegentlich bemerken Sie in Ihren X-Ray-Ablaufverfolgungen eine große Lücke zwischen den Phasen der Funktionsinitialisierung und des Funktionsaufrufs. Bei Funktionen, die [bereitgestellte Gleichzeitigkeit](provisioned-concurrency.md) verwenden, liegt dass daran, dass Lambda Ihre Funktions-Instances lange vor dem Aufruf initialisiert. Für Funktionen, die [unreservierte (On-demand) Gleichzeitigkeit](lambda-concurrency.md) verwenden, kann Lambda eine Funktions-Instance proaktiv initialisieren, auch wenn kein Aufruf erfolgt. Visuell werden diese beiden Fälle als Zeitlücke zwischen der Initialisierungs- und der Aufrufphase angezeigt.
**AWS X-Ray Lambda-Segmentstruktur im neuen Stil**
Die neue X-Ray-Struktur für das `AWS::Lambda`-Segment sieht wie folgt aus:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
In diesem neuen Format stellt das Teilsegment `Init` wie bisher die Init-Phase des Lebenszyklus der Lambda-Ausführungsumgebung dar.
Im neuen Format gibt es kein Aufrufsegment. Stattdessen werden Kundenuntersegmente direkt an das `AWS::Lambda::Function`-Segment angehängt. Dieses Segment enthält die folgenden Metriken als Anmerkungen:
+ `aws.responseLatency` – die Zeit, die benötigt wurde, bis die Funktion ausgeführt wurde
+ `aws.responseDuration` – die Zeit, die benötigt wurde, um die Antwort an den Kunden zu übermitteln
+ `aws.runtimeOverhead` – die zusätzliche Zeit, die die Laufzeit bis zum Abschluss benötigt hat
+ `aws.extensionOverhead` – die zusätzliche Zeit, die die Erweiterungen zum Abschluss benötigt hat
Das folgende Diagramm zeigt ein Beispiel für einen Trace mit der neuen X-Ray-Struktur.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
Beachten Sie die beiden Segmente im Beispiel. Beide heißen **my-function**, aber einer hat einen Ursprung von `AWS::Lambda` und der andere hat einen Ursprung von `AWS::Lambda::Function`. Wenn das `AWS::Lambda`-Segment einen Fehler anzeigt, hatte der Lambda-Service ein Problem. Wenn das `AWS::Lambda::Function`-Segment einen Fehler anzeigt, ist bei Ihrer Funktion ein Problem aufgetreten.
In den folgenden Themen finden Sie eine sprachspezifische Einführung in die Ablaufverfolgung in Lambda:
+ [Instrumentierung von Node.js Code in AWS Lambda](nodejs-tracing.md)
+ [Instrumentierung von Python-Code in AWS Lambda](python-tracing.md)
+ [Instrumentierung von Ruby-Code in AWS Lambda](ruby-tracing.md)
+ [Instrumentierung von Java-Code in AWS Lambda](java-tracing.md)
+ [Go-Code instrumentieren in AWS Lambda](golang-tracing.md)
+ [Instrumentierung von C\$1-Code in AWS Lambda](csharp-tracing.md)
Eine vollständige Liste der Services, welche die aktive Instrumentierung unterstützen, finden Sie unter [Unterstützte AWS-Services](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges) im AWS X-Ray -Entwicklerhandbuch.
## Standardmäßiges Nachverfolgungsverhalten in Lambda
Wenn die `Active`-Nachverfolgung nicht aktiviert ist, verwendet Lambda standardmäßig den `PassThrough`-Nachverfolgungsmodus.
Im `PassThrough`-Modus leitet Lambda den X-Ray-Nachverfolgungs-Header an Downstream-Services weiter, sendet aber nicht automatisch Nachverfolgungen. Dies gilt auch dann, wenn der Nachverfolgungs-Header eine Entscheidung zum Sampling der Anfrage enthält. Wenn der Upstream-Service keinen X-Ray-Nachverfolgungs-Header bereitstellt, generiert Lambda einen Header und trifft die Entscheidung, kein Sampling durchzuführen. Sie können jedoch Ihre eigenen Nachverfolgungen senden, indem Sie Nachverfolgungsbibliotheken aus Ihrem Funktionscode aufrufen.
**Anmerkung**
Bisher sendete Lambda automatisch Nachverfolgungen, wenn Upstream-Services wie Amazon API Gateway einen Nachverfolgungs-Header hinzufügten. Da Lambda Nachverfolgungen nicht automatisch sendet, gibt Ihnen Lambda die Kontrolle, die für Sie wichtigen Funktionen nachzuverfolgen. Wenn Ihre Lösung von diesem passiven Nachverfolgungsverhalten abhängt, wechseln Sie zur `Active`-Nachverfolgung.
## Berechtigungen für die Ausführungsrolle
Lambda benötigt die folgenden Berechtigungen, um Ablaufverfolgungsdaten an X-Ray zu senden. Fügen Sie sie der [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion hinzu.
+ [röntgen: PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [röntgen: PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
Diese Berechtigungen sind in der [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)verwalteten Richtlinie enthalten.
## Aktivieren der `Active`-Nachverfolgung mit der Lambda-API
Verwenden Sie die folgenden API-Operationen, um die Ablaufverfolgungskonfiguration mit dem AWS SDK AWS CLI oder zu verwalten:
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
**Der folgende AWS CLI Beispielbefehl aktiviert die aktive Ablaufverfolgung für eine Funktion namens my-function.**
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Der Ablaufverfolgungsmodus ist Teil der versionsspezifischen Konfiguration, wenn Sie eine Version Ihrer Funktion veröffentlichen. Sie können den Ablaufverfolgungsmodus für eine veröffentlichte Version nicht ändern.
## Aktivieren der Ablaufverfolgung mit `Active` CloudFormation
Verwenden Sie die Eigenschaft, um die Ablaufverfolgung `AWS::Lambda::Function` für eine Ressource in einer CloudFormation Vorlage zu aktivieren. `TracingConfig`
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Ablaufverfolgungskonfiguration**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Verwenden Sie für eine `AWS::Serverless::Function` Ressource AWS Serverless Application Model (AWS SAM) die `Tracing` Eigenschaft.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Ablaufverfolgungskonfiguration**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Überwachen Sie die Funktionsleistung mit Amazon CloudWatch Lambda Insights
Amazon CloudWatch Lambda Insights erfasst und aggregiert Lambda-Funktionslaufzeit-Leistungs-Metriken und Protokolle für Ihre Serverless-Anwendungen. Auf dieser Seite wird beschrieben, wie Sie Lambda Insights aktivieren und verwenden, um Probleme mit Ihren Lambda-Funktionen zu diagnostizieren.
**Topics**
+ [Wie Lambda Insights Serverless-Anwendungen überwacht](#monitoring-insights-how)
+ [Preisgestaltung](#monitoring-insights-pricing)
+ [Unterstützte Laufzeiten](#monitoring-insights-runtimes)
+ [Lambda Insights in der Lambda-Konsole aktivieren](#monitoring-insights-enabling-console)
+ [Programmgesteuertes Aktivieren von Lambda Insights](#monitoring-insights-enabling-programmatically)
+ [Verwenden des Lambda-Insights-Dashboards](#monitoring-insights-multifunction)
+ [Beispiel-Workflow zum Erkennen von Funktionsanomalien](#monitoring-insights-anomalies)
+ [Beispiel-Workflow mit Abfragen zur Fehlerbehebung einer Funktion](#monitoring-insights-queries)
+ [Als nächstes](#monitoring-console-next-up)
## Wie Lambda Insights Serverless-Anwendungen überwacht
CloudWatch Lambda Insights ist eine Überwachungs- und Fehlerbehebungslösung für Serverless-Anwendungen, die auf AWS Lambda ausgeführt werden. Die Lösung erfasst, aggregiert und fasst Metriken auf Systemebene zusammen, einschließlich CPU-Zeit, Arbeitsspeicher, Datenträger- und Netzwerknutzung. Sie erfasst, aggregiert und fasst Diagnoseinformationen wie Kaltstart und Lambda-Worker-Abschaltungen zusammen, um Probleme mit Ihren Lambda-Funktionen zu isolieren und schnell zu beheben.
Lambda Insights verwendet eine neue CloudWatch-Lambda-Insights-[Erweiterung](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html), die als [Lambda-Ebene](chapter-layers.md) angeboten wurde. Wenn Sie diese Erweiterung für eine Lambda-Funktion für eine unterstützte Laufzeit aktivieren, werden Metriken auf Systemebene erfasst und ein einzelnes Performance-Protokollereignis für jeden Aufruf dieser Lambda-Funktion ausgegeben. CloudWatch verwendet eingebettete Metrikformatierung, um Metriken aus den Protokollereignissen zu extrahieren. Weitere Informationen finden Sie unter [Verwendung von AWS Lambda-Erweiterungen](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html).
Die Lambda-Insights-Ebene erweitert die `CreateLogStream` und `PutLogEvents` für die `/aws/lambda-insights/`-Protokollgruppe.
## Preisgestaltung
Wenn Sie Lambda Insights für Ihre Lambda-Funktion aktivieren, meldet Lambda Insights 8 Metriken pro Funktion und jeder Funktionsaufruf sendet etwa 1 KB Protokolldaten an CloudWatch. Sie zahlen nur für die Metriken und Protokolle, die Lambda Insights für Ihre Funktion gemeldet haben. Es fallen keine Mindestgebühren oder Mindestnutzungsanforderungen an. Sie zahlen nicht für Lambda Insights, wenn die Funktion nicht aufgerufen wird. Ein Preisbeispiel finden Sie unter [Amazon-CloudWatch-Preise](https://aws.amazon.com/cloudwatch/pricing/).
## Unterstützte Laufzeiten
Sie können Lambda Insights mit jeder Laufzeitumgebung verwenden, die [Lambda-Erweiterungen](runtimes-extensions-api.md) unterstützen.
## Lambda Insights in der Lambda-Konsole aktivieren
Sie können die erweiterte Lambda-Insights-Überwachung neuer und vorhandener Lambda-Funktionen aktivieren. Wenn Sie Lambda Insights auf einer Funktion in der Lambda-Konsole für eine unterstützte Laufzeit aktivieren, fügt Lambda die Lambda-[Insights-Erweiterung](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) als Ebene Ihrer Funktion hinzu und überprüft die [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor)-Richtlinie oder versucht, diese der [Ausführungsrolle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) Ihrer Funktion zuzuweisen.
**Lambda Insights in der Lambda-Konsole aktivieren**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie Ihre Funktion.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Wählen Sie im linken Menü die Option **Überwachungs- und Betriebstools**.
1. Wählen Sie im Bereich **Zusätzliche Überwachungstools** die Option **Edit (Bearbeiten)**.
1. Aktivieren Sie unter **CloudWatch Lambda Insights** die **erweiterte Überwachung**.
1. Wählen Sie **Speichern**.
## Programmgesteuertes Aktivieren von Lambda Insights
Sie können Lambda Insights auch über die AWS Command Line Interface, (AWS CLI), AWS Serverless Application Model, (SAM)-CLI, das CloudFormation oder das AWS Cloud Development Kit (AWS CDK) aktivieren. Wenn Sie Lambda Insights programmgesteuert auf einer Funktion für eine unterstützte Laufzeit aktivieren, hängt CloudWatch die [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor)-Richtlinie an die [Ausführungsrolle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) Ihrer Funktion an.
Weitere Informationen finden Sie unter [Erste Schritte mit Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html) im *Amazon-CloudWatch-Benutzerhandbuch*.
## Verwenden des Lambda-Insights-Dashboards
Das Lambda-Insights-Dashboard hat zwei Ansichten in der CloudWatch-Konsole: die Multifunktionsübersicht und die Einzelfunktionsansicht. Die Multifunktionsübersicht aggregiert die Laufzeitmetriken für die Lambda-Funktionen im aktuellen AWS-Konto und in der Region. Die Einzelfunktionsansicht zeigt die verfügbaren Laufzeit-Metriken für eine einzelne Lambda-Funktion an.
Sie können die Multifunktionsübersicht des Lambda-Insights-Dashboards in der CloudWatch-Konsole verwenden, um übermäßig und nicht ausgelastete Lambda-Funktionen zu identifizieren. Sie können die Einzelfunktionsansicht des Lambda-Insights-Dashboards in der CloudWatch-Konsole verwenden, um Probleme bei einzelnen Anforderungen zu beheben.
**So zeigen Sie die Laufzeit-Metriken für alle Funktionen an:**
1. Öffnen Sie die Seite [Multifunktion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) in der CloudWatch-Konsole.
1. Wählen Sie aus den vordefinierten Zeitbereichen oder wählen Sie einen benutzerdefinierten Zeitbereich aus.
1. (Optional) Wählen Sie **Zu Dashboard hinzufügen**, um die Widgets zu Ihrem CloudWatch-Dashboard hinzuzufügen.
![\[Die Multifunktionsübersicht auf dem Lambda-Insights-Dashboard.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**So zeigen Sie die Laufzeit-Metriken einer einzelnen Funktion an:**
1. Öffnen Sie die [Einzelfunktion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions) in der CloudWatch-Konsole.
1. Wählen Sie aus den vordefinierten Zeitbereichen oder wählen Sie einen benutzerdefinierten Zeitbereich aus.
1. (Optional) Wählen Sie **Zu Dashboard hinzufügen**, um die Widgets zu Ihrem CloudWatch-Dashboard hinzuzufügen.
![\[Die Einzelfunktionsansicht auf dem Lambda-Insights-Dashboard.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
Weitere Informationen finden Sie unter [Erstellen und Arbeiten mit Widgets in CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html).
## Beispiel-Workflow zum Erkennen von Funktionsanomalien
Sie können die Multifunktionsübersicht auf dem Lambda-Insights-Dashboard verwenden, um Anomalien des Rechenspeichers mit Ihrer Funktion zu identifizieren und zu erkennen. Wenn beispielsweise die Multifunktionsübersicht anzeigt, dass eine Funktion eine große Menge Speicher verwendet, können Sie detaillierte Metriken zur Speicherauslastung im Bereich **Memory Usage (Speicherverwendung)** anzeigen. Sie können dann zum Metrik-Dashboard wechseln, um die Anomalieerkennung zu aktivieren oder einen Alarm zu erstellen.
**So aktivieren Sie die Anomalieerkennung für eine Funktion:**
1. Öffnen Sie die Seite [Multifunktion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) in der CloudWatch-Konsole.
1. Wählen Sie unter **Function summary (Funktionsübersicht)** den Namen Ihrer Funktion aus.
Die Einzelfunktionsansicht wird mit den Funktionslaufzeitmetriken geöffnet.
![\[Der Funktionsübersichtbereich im Lambda-Insights-Dashboard.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. Wählen Sie im Bereich **Memory Usage (Speicherverwendung)** die drei vertikalen Punkte aus, und wählen Sie dann **View in metrics (In Metriken anzeigen)**, um das **Metrics (Metriken)**-Dashboard zu öffnen.
![\[Das Menü im Bereich Speicherverwendung.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. Wählen Sie auf der Registerkarte **Graphed metrics (Metriken mit Diagrammen)** in der Spalte **Actions (Aktionen)** das erste Symbol aus, um die Anomalieerkennung für die Funktion zu aktivieren.
![\[Die Registerkarte Metriken mit Diagrammen im Bereich Speicherverwendung.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
Weitere Informationen finden Sie unter [Verwenden von CloudWatch-Anomalieerkennung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
## Beispiel-Workflow mit Abfragen zur Fehlerbehebung einer Funktion
Sie können die Einzelfunktionsansicht im Lambda-Insights-Dashboard verwenden, um die Ursache eines Spitzenwerts der Funktionsdauer zu ermitteln. Wenn beispielsweise die Multifunktionsübersicht eine starke Erhöhung der Funktionsdauer anzeigt, können Sie jede Funktion im Bereich **Duration (Dauer)** anhalten oder auswählen, um festzustellen, welche Funktion die Erhöhung verursacht. Sie können dann zur Einzelfunktionsansicht wechseln und die **Anwendungsprotokolle** überprüfen, um die Ursache zu ermitteln.
**So führen Sie Abfragen für eine Funktion aus:**
1. Öffnen Sie die Seite [Multifunktion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) in der CloudWatch-Konsole.
1. Wählen Sie im Bereich **Duration (Dauer)** Ihre Funktion aus, um die Dauer-Metriken zu filtern.
![\[Eine Funktion, die im Bereich Dauer ausgewählt wurde.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. Öffnen Sie die Seite [Einzelfunktionsansicht](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions).
1. Wählen Sie die Dropdown-Liste **Filter metrics by function name (Metriken nach Funktionsnamen filtern)** und wählen Sie dann Ihre Funktion aus.
1. Um die **neuesten 1000 Anwendungsprotokolle** anzuzeigen, wählen Sie die Registerkarte **Application logs (Anwendungsprotokolle)**.
1. Überprüfen Sie den **Zeitstempel** und die **Meldung** um die Aufrufanforderung zu identifizieren, für die Sie Fehler beheben möchten.
![\[Die neuesten 1000 Anwendungsprotokolle.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. Um die **letzten 1000 Aufrufe** anzuzeigen, wählen Sie die Registerkarte **Invocations (Aufrufe)**.
1. Wählen Sie den **Zeitstempel** oder die **Meldung** für die Aufrufanforderung aus, für die Sie Fehler beheben möchten.
![\[Auswahl einer kürzlich erfolgten Aufrufanforderung.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. Wählen Sie die Dropdown-Liste **View logs (Protokolle anzeigen)** und wählen Sie dann **View performance logs (Leistungsprotokolle anzeigen)** aus.
Im Dashboard **Logs Insights (Protokolleinblicke)** wird eine automatisch generierte Abfrage für Ihre Funktion geöffnet.
1. Wählen Sie **Run query (Abfrage ausführen)**, um eine **Logs (Protokolle)**-Meldung für die Aufrufanforderung zu generieren.
![\[Abfragen der ausgewählten Funktion im Logs-Insights-Dashboard.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/lambdainsights-query.png)
## Als nächstes
+ Informationen zum Erstellen eines CloudWatch Logs-Dashboards finden Sie unter [Erstellen eines Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) im *Amazon-CloudWatch-Benutzerhandbuch*.
+ Informationen zum Hinzufügen von Abfragen zu einem CloudWatch-Logs-Dashboard finden Sie unter [Abfrage zum Dashboard hinzufügen oder Abfrageergebnisse exportieren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) im *Amazon-CloudWatch-Benutzerhandbuch*.
# Überwachen von Lambda-Anwendungen
Der Abschnitt **Anwendungen** der Lambda-Konsole enthält eine Registerkarte **Überwachung**, auf der Sie ein Amazon CloudWatch-Dashboard mit aggregierten Metriken für die Ressourcen in Ihrer Anwendung anzeigen können.
**So überwachen Sie eine Lambda-Anwendung**
1. Öffnen Sie die Seite [Anwendungen](https://console.aws.amazon.com/lambda/home#/applications) der Lambda-Konsole.
1. Wählen Sie **Monitoring**.
1. Um weitere Details zu den Metriken in einem beliebigen Diagramm anzuzeigen, wählen Sie im Dropdown-Menü **Ansicht in Metriken**.
![\[Ein Überwachungs-Widget.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/applications-monitoring-widget.png)
Das Diagramm erscheint in einer neuen Registerkarte, wobei die relevanten Metriken unterhalb des Diagramms aufgelistet sind. Sie können Ihre Ansicht dieses Diagramms anpassen, indem Sie die angezeigten Metriken und Ressourcen, die Statistik, den Zeitraum und andere Faktoren ändern, um ein besseres Verständnis der aktuellen Situation zu erhalten.
Standardmäßig zeigt die Lambda-Konsole ein grundlegendes Dashboard an. Sie können diese Seite anpassen, indem Sie Ihrer Anwendungsvorlage ein oder mehrere Amazon-CloudWatch-Dashboards mit dem [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html)-Ressourcentyp hinzufügen. Wenn Ihre Vorlage ein oder mehrere Dashboards enthält, zeigt die Seite Ihre Dashboards anstelle des Standard-Dashboards an. Sie mit dem Dropdown-Menü oben rechts auf der Seite zwischen Dashboards wechseln. Das folgende Beispiel erstellt ein Dashboard mit einem einzigen Widget, das die Anzahl der Aufrufe einer Funktion mit dem Namen grafisch darstell `my-function`.
**Example Dashboard-Funktionsvorlage**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
Weitere Informationen zum Erstellen von CloudWatch-Dashboards und -Widgets finden Sie im Artikel zur [Dashboard-Textstruktur und -Syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) in der *Amazon-CloudWatch-API-Referenz*.
# Überwachen der Anwendungsleistung mit Amazon CloudWatch Application Signals
Amazon CloudWatch Application Signals ist eine Lösung zur Überwachung der Anwendungsleistung, mit der Entwickler und Betreiber den Zustand und die Leistung ihrer mit Lambda erstellten Serverless-Anwendungen überwachen können. Sie können Application Signals mit einem Klick von der Lambda-Konsole aus aktivieren und Sie müssen Ihrer Lambda-Funktion keinen Instrumentierungscode oder externe Abhängigkeiten hinzufügen. Nachdem Sie Application Signals aktiviert haben, können Sie alle gesammelten Metriken und Traces in der CloudWatch-Konsole anzeigen. Auf dieser Seite wird beschrieben, wie Sie Application-Signals-Telemetriedaten für Ihre Anwendungen aktivieren und anzeigen.
**Topics**
+ [So lässt sich Application Signals in Lambda integrieren](#monitoring-application-signals-how)
+ [Preisgestaltung](#monitoring-application-signals-pricing)
+ [Unterstützte Laufzeiten](#monitoring-application-signals-runtimes)
+ [Aktivieren von Application Signals in der Lambda-Konsole](#monitoring-application-signals-console)
+ [Verwenden des Application Signals-Dashboards](#monitoring-application-signals-dashboard)
## So lässt sich Application Signals in Lambda integrieren
Application Signals instrumentiert Ihre Lambda-Funktionen automatisch mithilfe erweiterter [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/)-Bibliotheken, die über eine [Lambda-Ebene](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) bereitgestellt werden. Application Signals liest die von der Ebene gesammelten Daten und generiert Dashboards mit wichtigen Leistungsmetriken für Ihre Anwendungen.
Sie können diese Ebene mit einem Klick anhängen, indem Sie [Application Signals](#monitoring-application-signals-console) in der Lambda-Konsole aktivieren. Wenn Sie Application Signals über die Konsole aktivieren, führt Lambda Folgendes in Ihrem Namen aus:
+ Aktualisiert die Ausführungsrolle Ihrer Funktion mit der `CloudWatchLambdaApplicationSignalsExecutionRolePolicy`. [ Diese Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html) bietet Schreibzugriff auf AWS X-Ray- und CloudWatch-Protokollgruppen, die für Application Signals verwendet werden.
+ Fügt Ihrer Funktion eine Ebene hinzu, die die Funktion automatisch so instrumentiert, dass sie Telemetriedaten wie Anfragen, Verfügbarkeit, Latenz, Fehler und Störungen erfasst. Um sicherzustellen, dass Application Signals ordnungsgemäß funktioniert, entfernen Sie jeglichen vorhandenen X-Ray-SDK-Instrumentierungscode aus Ihrer Funktion. Benutzerdefinierter X-Ray SDK-Instrumentierungscode kann die von der Ebene bereitgestellte Instrumentierung beeinträchtigen.
+ Fügt Ihrer Funktion die `AWS_LAMBDA_EXEC_WRAPPER`-Umgebungsvariable hinzu und setzt ihren Wert auf `/opt/otel-instrument`. Diese Umgebungsvariable ändert das Startverhalten Ihrer Funktion, um die Application Signals-Ebene zu nutzen. Sie ist für die richtige Instrumentierung erforderlich. Wenn diese Umgebungsvariable bereits existiert, stellen Sie sicher, dass sie auf den erforderlichen Wert gesetzt ist.
## Preisgestaltung
Die Verwendung von Application Signals für Ihre Lambda-Funktionen verursacht Kosten. Preisinformationen finden Sie unter [Amazon-CloudWatch-Preisinformationen](https://aws.amazon.com/cloudwatch/pricing/).
## Unterstützte Laufzeiten
Die Application Signal-Integration mit Lambda funktioniert mit den folgenden Laufzeiten:
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Aktivieren von Application Signals in der Lambda-Konsole
Sie können Application Signals für jede vorhandene Lambda-Funktion mit einer [unterstützten Laufzeit](#monitoring-application-signals-runtimes) aktivieren. In den folgenden Schritten wird beschrieben, wie Sie Application Signals mit einem Klick in der Lambda-Konsole aktivieren.
**So aktivieren Sie Application Signals 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 Ihre Funktion.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Wählen Sie im linken Menü die Option **Überwachungs- und Betriebstools**.
1. Wählen Sie im Bereich **Zusätzliche Überwachungstools** die Option **Edit (Bearbeiten)**.
1. Wählen Sie unter **CloudWatch Application Signals und AWS X-Ray** unter **Application Signals** die Option **Aktivieren** aus.
1. Wählen Sie **Speichern**.
Wenn Sie Application Signals zum ersten Mal für Ihre Funktion aktivieren, müssen Sie auch eine einmalige Serviceerkennung für Application Signals in der CloudWatch-Konsole einrichten. Nachdem Sie dieses einmalige Serviceerkennungs-Setup abgeschlossen haben, erkennt Application Signals automatisch alle zusätzlichen Lambda-Funktionen, für die Sie Application Signals aktivieren, in allen Regionen.
**Anmerkung**
Nachdem Sie Ihre aktualisierte Funktion aufgerufen haben, kann es bis zu 10 Minuten dauern, bis Servicedaten im Application-Signals-Dashboard in der CloudWatch-Konsole angezeigt werden.
## Verwenden des Application Signals-Dashboards
Nachdem Sie Application Signals für Ihre Funktion aktiviert haben, können Sie Ihre Anwendungsmetriken in der CloudWatch-Konsole visualisieren. Mit den folgenden Schritten können Sie das zugehörige Application-Signals-Dashboard schnell von der Lambda-Konsole aus aufrufen:
**So rufen Sie das Application Signals-Dashboard für Ihre Funktion auf**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie Ihre Funktion.
1. Wählen Sie den Tab **Überwachung**.
1. Wählen Sie die Schaltfläche **Anwendungssignale anzeigen**. Dies führt Sie direkt zur Anwendungssignalen-Übersicht für Ihren Dienst in der CloudWatch-Konsole.
Der folgende Screenshot zeigt beispielsweise Metriken für die Latenzzeit, die Anzahl der Anfragen, die Verfügbarkeit, die Fehlerrate und die Fehlerquote für eine Funktion in einem Zeitfenster von 10 Minuten.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Um das Beste aus Ihrer Integration mit Application Signals herauszuholen, können Sie Service Level Objectives (SLOs) für Ihre Anwendung erstellen. Sie können beispielsweise Latenz-SLOs erstellen, um sicherzustellen, dass Ihre Anwendung schnell auf Benutzeranfragen reagiert, und Verfügbarkeits-SLOs, um die Verfügbarkeit zu verfolgen. SLOs können Ihnen helfen, Leistungseinbußen oder Ausfälle zu erkennen, bevor sie sich auf Ihre Benutzer auswirken. Weitere Informationen finden Sie unter [Service Level Objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) im Amazon-CloudWatch-Benutzerhandbuch.
# Remote-Debugging von Lambda-Funktionen mit Visual Studio Code
Mit dem Remote-Debugging-Feature im [AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/) können Sie Ihre Lambda-Funktionen debuggen, die direkt in der AWS-Cloud ausgeführt werden. Dies ist nützlich, wenn Sie Probleme untersuchen, die lokal schwer zu reproduzieren sind oder nur anhand von Protokollen diagnostiziert werden können.
Mit Remote-Debugging können Sie:
+ Haltepunkte in Ihrem Lambda-Funktionscode setzen.
+ Die Codeausführung in Echtzeit durchlaufen.
+ Variablen und Status während der Laufzeit überprüfen.
+ Lambda-Funktionen debuggen, die in AWS bereitgestellt wurden, einschließlich solcher in VPCs oder mit bestimmten IAM-Berechtigungen.
## Unterstützte Laufzeiten
Remote-Debugging wird für die folgenden Laufzeiten unterstützt:
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**Anmerkung**
Remote-Debugging wird sowohl für x86\$164- als auch für arm64-Architekturen unterstützt.
## Sicherheit und Remote-Debugging
Das Remote-Debugging erfolgt innerhalb der bestehenden Lambda-Sicherheitsgrenzen. Benutzer können mithilfe der Berechtigung `UpdateFunctionConfiguration`, die bereits Zugriff auf Funktionsumgebungsvariablen und -konfigurationen ermöglicht, Ebenen an eine Funktion anhängen. Das Remote-Debugging geht nicht über diese bestehenden Berechtigungen hinaus. Stattdessen werden zusätzliche Sicherheitskontrollen durch sicheres Tunneling und automatische Sitzungsverwaltung hinzugefügt. Darüber hinaus ist das Remote-Debugging ein vollständig vom Kunden kontrolliertes Feature, das explizite Berechtigungen und Aktionen erfordert:
+ **Erstellung eines sicheren IoT-Tunnels**: Das AWS-Toolkit muss einen sicheren IoT-Tunnel erstellen, was nur mit der ausdrücklichen Berechtigung des Benutzers über `iot:OpenTunnel` möglich ist.
+ **Anhängen der Debugging-Ebene und Tokenverwaltung**: Der Debugging-Prozess gewährleistet die Sicherheit durch folgende Kontrollen:
+ Die Debugging-Ebene muss an die Lambda-Funktion angehängt werden, wofür die folgenden Berechtigungen erforderlich sind: `lambda:UpdateFunctionConfiguration` und `lambda:GetLayerVersion`.
+ Ein Sicherheitstoken (generiert über `iot:OpenTunnel`) muss vor jeder Debugging-Sitzung in der Funktionsumgebungsvariablen aktualisiert werden, was ebenfalls `lambda:UpdateFunctionConfiguration` erfordert.
+ Aus Sicherheitsgründen wird dieses Token automatisch rotiert und die Debug-Ebene wird am Ende jeder Debugging-Sitzung automatisch entfernt und kann nicht wiederverwendet werden.
**Anmerkung**
Remote-Debugging wird sowohl für x86\$164- als auch für arm64-Architekturen unterstützt.
## Voraussetzungen
Bevor Sie mit dem Remote-Debugging beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
1. Eine Lambda-Funktion, die für Ihr AWS-Konto bereitgestellt wurde.
1. AWS Toolkit for Visual Studio Code. Installationsanweisungen finden Sie unter [Einrichten des AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html).
1. Die Version des AWS-Toolkits, die Sie installiert haben, ist mindestens **3.69.0**.
1. AWS-Anmeldeinformationen, die in AWS Toolkit for Visual Studio Code konfiguriert sind. Weitere Informationen finden Sie unter [Authentifizierung und Zugriffskontrolle](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control).
## Remote-Debugging von Lambda-Funktionen
Führen Sie die folgenden Schritte aus, um eine Remote-Debugging-Sitzung zu starten:
1. Öffnen Sie den AWS Explorer in VS Code, indem Sie das AWS-Symbol in der linken Seitenleiste auswählen.
1. Erweitern Sie den Abschnitt „Lambda“, um Ihre Funktionen anzuzeigen.
1. Klicken Sie mit der rechten Maustaste auf die Funktion, die Sie debuggen möchten.
1. Wählen Sie im Kontextmenü die Option **Remote aufrufen** aus.
1. Aktivieren Sie im sich öffnenden Aufruffenster das Kontrollkästchen **Debugging aktivieren**.
1. Klicken Sie auf **Aufrufen**, um die Remote-Debugging-Sitzung zu starten.
**Anmerkung**
Lambda-Funktionen haben ein kombiniertes Limit von 250 MB für Funktionscode und alle angehängten Ebenen. Die Remote-Debugging-Ebene erhöht die Größe Ihrer Funktion um ca. 40 MB.
Eine Remote-Debugging-Sitzung endet, wenn Sie:
+ auf dem Bildschirm mit der Remoteaufruf-Konfiguration“ die Option **Debug-Setup entfernen** auswählen
+ in den Debugging-Steuerelementen von VS Code das Symbol „Trennen“ auswählen
+ die Handler-Datei im VS-Code-Editor auswählen.
**Anmerkung**
Die Debugging-Ebene wird automatisch entfernt, wenn nach Ihrem letzten Aufruf 60 Sekunden lang keine Aktivität stattfindet.
## Deaktivieren von Remote-Debugging
Es gibt drei Möglichkeiten, dieses Feature zu deaktivieren:
+ **Funktionsupdates verweigern**: `lambda:UpdateFunctionConfiguration` auf `deny` setzen
+ **IoT-Berechtigungen einschränken**: IoT-bezogene Berechtigungen verweigern
+ **Debug-Ebenen blockieren**: `lambda:GetLayerVersion` für die folgenden ARNs verweigern:
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**Anmerkung**
Durch Deaktivieren dieses Features wird verhindert, dass die Debugging-Ebene während der Aktualisierung der Funktionskonfiguration hinzugefügt wird.
## Zusätzliche Informationen
Weitere Informationen zur Verwendung von Lambda in VS Code finden Sie unter [Lokale Entwicklung von Lambda-Funktionen mit VS Code](foundation-iac-local-development.md).
Ausführliche Anweisungen zur Fehlerbehebung, zu erweiterten Anwendungsfällen und zur regionalen Verfügbarkeit finden Sie unter [Remote-Debuggen von Lambda-Funktionen](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) im AWS Toolkit for Visual Studio Code-Benutzerhandbuch.