Verarbeitung selbstverwalteter Apache Kafka-Nachrichten mit Lambda - AWS Lambda

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.

Verarbeitung selbstverwalteter Apache Kafka-Nachrichten mit Lambda

Anmerkung

Wenn Sie Daten an ein anderes Ziel als eine Lambda-Funktion senden oder die Daten vor dem Senden anreichern möchten, finden Sie weitere Informationen unter Amazon EventBridge Pipes.

Hinzufügen eines Kafka-Clusters als Ereignisquelle

Um eine Ereignisquellenzuordnung zu erstellen, fügen Sie Ihren Kafka-Cluster als einen Lambda-Funktions-Auslöser hinzu und verwenden Sie dabei die Lambda-Konsole, ein AWS -SDK oder die AWS Command Line Interface (AWS CLI).

In diesem Abschnitt wird beschrieben, wie Sie mit der Lambda-Konsole und AWS CLI ein Ereignisquellen-Zuweisung erstellen.

Voraussetzungen

  • Selbstverwaltetes Apache-Kafka-Cluster. Lambda unterstützt Apache Kafka Version 0.10.1.0 und höher.

  • Eine Ausführungsrolle mit der Berechtigung, auf die AWS Ressourcen zuzugreifen, die Ihr selbstverwalteter Kafka-Cluster verwendet.

Anpassbare Konsumentengruppen-ID

Wenn Sie Kafka als Ereignisquelle einrichten, können Sie eine Konsumentengruppen-ID angeben. Diese Konsumentengruppen-ID ist eine vorhandene Kennung für die Kafka-Konsumentengruppe, der Ihre Lambda-Funktion beitreten soll. Mit diesem Feature können Sie alle laufenden Kafka-Datensatzverarbeitungs-Setups nahtlos von anderen Verbrauchern auf Lambda migrieren.

Wenn Sie eine Konsumentengruppen-ID angeben und sie innerhalb dieser Konsumentengruppe weitere aktive Poller gibt, verteilt Kafka Nachrichten an alle Konsumenten. Mit anderen Worten, Lambda erhält nicht alle Nachrichten zum Thema Kafka. Wenn Sie möchten, dass Lambda alle Nachrichten im Thema verarbeitet, deaktivieren Sie alle anderen Poller in dieser Konsumentengruppe.

Wenn Sie außerdem eine Konsumentengruppen-ID angeben und Kafka eine gültige vorhandene Konsumentengruppe mit derselben ID findet, ignoriert Lambda die StartingPosition-Parameter für Ihre Ereignisquellen-Zuweisung. Stattdessen beginnt Lambda mit der Verarbeitung von Datensätzen gemäß dem zugesagten Versatz der Konsumentengruppe. Wenn Sie eine Konsumentengruppen-ID angeben und Kafka keine vorhandene Konsumentengruppe finden kann, konfiguriert Lambda Ihre Ereignisquelle mit der angegebenen StartingPosition.

Die Konsumentengruppen-ID, die Sie angeben, muss unter all Ihren Kafka-Ereignisquellen eindeutig sein. Nachdem Sie eine Kafka-Ereignisquellenzuordnung mit der angegebenen Konsumentengruppen-ID erstellt haben, können Sie diesen Wert nicht aktualisieren.

Hinzufügen eines selbstverwalteten Kafka-Clusters (Konsole)

Befolgen Sie diese Schritte, um Ihren selbstverwalteten Apache-Kafka-Cluster und ein Kafka-Thema als Auslöser für Ihre Lambda-Funktion hinzuzufügen.

So fügen Sie Ihrer Lambda-Funktion (Konsole) einen Apache-Kafka-Auslöser hinzu
  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie den Namen Ihrer Lambda-Funktion aus.

  3. Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).

  4. Führen Sie unter Auslöser-Konfiguration die folgenden Schritte aus:

    1. Wählen Sie den Apache-Kafka-Auslösertyp.

    2. Geben Sie für Bootstrap-Server die Host- und Portpaaradresse eines Kafka-Brokers in Ihrem Cluster ein und wählen Sie dann Hinzufügen. Wiederholen Sie den Vorgang für jeden Kafka-Broker im Cluster.

    3. Geben Sie für Themenname den Namen des Kafka-Themas ein, das zum Speichern von Datensätzen im Cluster verwendet wird.

    4. (Optional) Geben Sie für Batchgröße die maximale Anzahl von Datensätzen ein, die in einem einzelnen Batch empfangen werden sollen.

    5. Geben Sie für Batch window (Batch-Fenster) die maximale Zeit in Sekunden ein, die Lambda mit dem Sammeln von Datensätzen verbringt, bevor die Funktion aufgerufen wird.

    6. (Optional) Geben Sie für Konsumentengruppen-ID die ID einer Kafka-Konsumentengruppe ein, der Sie beitreten möchten.

    7. (Optional) Wählen Sie für Startposition die Option Neueste, um mit dem Lesen des Streams aus dem letzten Datensatz zu beginnen, Horizont trimmen, um mit dem frühesten verfügbaren Datensatz zu beginnen, oder Am Zeitstempel, um einen Zeitstempel anzugeben, ab dem mit dem Lesen begonnen werden soll.

    8. (Optional) Wählen Sie bei VPC die Amazon VPC für Ihren Kafka-Cluster aus. Wählen Sie dann VPC subnets (VPC-Subnetze) und VPC security groups (VPC-Sicherheitsgruppen) aus.

      Diese Einstellung ist erforderlich, wenn nur Benutzer innerhalb Ihrer VPC auf Ihre Broker zugreifen.

    9. (Optional) Wählen Sie bei Authentication (Authentifizierung) die Option Add (Hinzufügen) aus und gehen Sie dann folgendermaßen vor:

      1. Wählen Sie das Zugriffs- oder Authentifizierungsprotokoll der Kafka-Broker in Ihrem Cluster aus.

        • Wenn Ihr Kafka-Broker eine SASL/PLAIN-Authentifizierung verwendet, wählen Sie BASIC_AUTH.

        • Wenn Ihr Broker die SASL/SCRAM-Authentifizierung verwendet, wählen Sie eines der Protokolle aus. SASL_SCRAM

        • Falls Sie die mTLS-Authentifizierung konfigurieren, wählen Sie das Protokoll CLIENT_CERTIFICATE_TLS_AUTH aus.

      2. Wählen Sie für SASL/SCRAM- oder mTLS-Authentifizierung den Secrets-Manager-Geheimschlüssel aus, der die Anmeldeinformationen für Ihren Kafka-Cluster enthält.

    10. (Optional) Wählen Sie bei Encryption (Verschlüsselung) das Secrets-Manager-Secret aus, das das Root-CA-Zertifikat enthält, das Ihre Kafka-Broker zur TLS-Verschlüsselung verwenden, falls Ihre Kafka-Broker von einer privaten Zertifizierungsstelle signierte Zertifikate verwenden.

      Diese Einstellung gilt für die TLS-Verschlüsselung für und für die SASL/SCRAM or SASL/PLAIN mTLS-Authentifizierung.

    11. Um den Auslöser zu Testzwecken in einem deaktivierten Zustand zu erstellen (empfohlen), deaktivieren Sie Auslöser aktivieren. Um den Auslöser sofort zu aktivieren, wählen Sie Auslöser aktivieren.

  5. Wählen Sie hinzufügen aus, um den Auslöser zu erstellen.

Selbstverwaltetes Apache-Kafka-Cluster hinzufügen (AWS CLI)

Verwenden Sie die folgenden AWS CLI Beispielbefehle, um einen selbstverwalteten Apache Kafka-Trigger für Ihre Lambda-Funktion zu erstellen und anzuzeigen.

Verwenden von SASL/SCRAM

Wenn Kafka-Benutzer über das Internet auf Ihre Kafka-Broker zugreifen, geben Sie das Secrets-Manager-Secret an, das Sie für die SASL/SCRAM-Authentifizierung erstellt haben. Im folgenden Beispiel wird der create-event-source-mapping AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens my-kafka-function zuzuordnen. AWSKafkaTopic

aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Verwenden einer VPC

Wenn nur Kafka-Benutzer in Ihrer VPC auf Ihre Kafka-Broker zugreifen, müssen Sie Ihre VPC, Subnetze und VPC-Sicherheitsgruppe angeben. Im folgenden Beispiel wird der create-event-source-mapping AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens my-kafka-function zuzuordnen. AWSKafkaTopic

aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Den Status mit dem anzeigen AWS CLI

Im folgenden Beispiel wird der get-event-source-mapping AWS CLI Befehl verwendet, um den Status der von Ihnen erstellten Ereignisquellenzuordnung zu beschreiben.

aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7

Selbstverwalteter Apache-Kafka-Konfigurationsparameter

Alle Lambda-Ereignisquelltypen verwenden dieselben CreateEventSourceMappingUpdateEventSourceMappingAPI-Operationen. Allerdings gelten nur einige der Parameter für Apache Kafka.

Parameter Erforderlich Standard Hinweise

BatchSize

N

100

Höchstwert: 10 000.

DestinationConfig

N

N/A

Erfassen verworfener Batches für eine selbstverwaltete Apache Kafka-Ereignisquelle

Aktiviert

N

True

FilterCriteria

N

N/A

Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet

FunctionName

Y

N/A

KMSKeyArn

N

N/A

Verschlüsselung der Filterkriterien

MaximumBatchingWindowInSeconds

N

500 ms

Batching-Verhalten

ProvisionedPollersConfig

N

MinimumPollers: Standardwert von 1, wenn nicht angegeben

MaximumPollers: Standardwert von 200, wenn nicht angegeben

Konfigurieren des bereitgestellten Modus

SelfManagedEventSource

Y

N/A

Liste der Kafka Broker. Kann nur auf „Erstellen“ festgelegt werden

SelfManagedKafkaEventSourceConfig

N

Enthält das ConsumerGroupId Feld, das standardmäßig einen eindeutigen Wert hat.

Kann nur auf „Erstellen“ festgelegt werden

SourceAccessConfigurations

N

Keine Anmeldeinformationen

VPC-Informationen oder Authentifizierungsanmeldeinformationen für den Cluster

Für SASL_PLAIN, auf BASIC_AUTH gesetzt

StartingPosition

Y

N/A

AT_TIMESTAMP, TRIM_HORIZON, oder LATEST

Kann nur auf „Erstellen“ festgelegt werden

StartingPositionTimestamp

N

N/A

Erforderlich, wenn der Wert auf StartingPosition AT_TIMESTAMP gesetzt ist

Tags

N

N/A

Verwendung von Tags für Zuordnungen von Ereignisquellen

Themen

Y

N/A

Topic-Name

Kann nur auf „Erstellen“ festgelegt werden

Verwenden eines Kafka-Clusters als Ereignisquelle

Wenn Sie Ihren Apache Kafka-Cluster oder Amazon MSK als Auslöser für Ihre Lambda-Funktion hinzufügen, wird der Cluster als Ereignisquelle verwendet.

Lambda liest Ereignisdaten aus den Kafka-Themen, die Sie wie Topics in einer CreateEventSourceMappingAnfrage angeben, basierend auf den StartingPosition von Ihnen angegebenen Themen. Nach erfolgreicher Verarbeitung wird Ihr Kafka-Thema Ihrem Kafka-Cluster zugeordnet.

Wenn Sie die StartingPosition als LATEST angeben, beginnt Lambda mit dem Lesen der neuesten Nachricht in jeder zum Thema gehörenden Partition. Da es nach der Auslöserkonfiguration eine gewisse Verzögerung geben kann, bevor Lambda mit dem Lesen der Nachrichten beginnt, liest Lambda keine Nachrichten, die innerhalb dieses Zeitraums erzeugt wurden.

Lambda verarbeitet Datensätze von einer oder mehreren Kafka-Themenpartitionen, die Sie angeben, und sendet eine JSON-Nutzlast an Ihre Funktion. Eine einzelne Lambda-Nutzlast kann Nachrichten von mehreren Partitionen enthalten. Wenn mehr Datensätze verfügbar sind, setzt Lambda die Verarbeitung von Datensätzen stapelweise fort, basierend auf dem BatchSize Wert, den Sie in einer CreateEventSourceMappingAnfrage angeben, bis Ihre Funktion das Thema eingeholt hat.

Wenn Ihre Funktion einen Fehler für eine der Nachrichten in einem Batch zurückgibt, wiederholt Lambda den gesamten Nachrichtenbatch, bis die Verarbeitung erfolgreich ist oder die Nachrichten ablaufen. Sie können Datensätze, bei denen alle Wiederholungsversuche fehlschlagen, zur späteren Verarbeitung an ein Ausfallziel senden.

Anmerkung

Während Lambda-Funktionen in der Regel ein maximales Timeout-Limit von 15 Minuten haben, unterstützen Ereignisquellenzuordnungen für Amazon MSK, selbstverwaltetes Apache Kafka, Amazon DocumentDB, Amazon MQ für ActiveMQ und RabbitMQ nur Funktionen mit einem maximalen Timeout-Limit von 14 Minuten. Diese Einschränkung stellt sicher, dass die Ereignisquellenzuordnung Funktionsfehler und Wiederholungsversuche ordnungsgemäß verarbeiten kann.

Startpositionen für Abfragen und Streams

Beachten Sie, dass die Stream-Abfrage bei der Erstellung und Aktualisierung der Zuordnung von Ereignisquellen letztendlich konsistent ist.

  • Bei der Erstellung der Zuordnung von Ereignisquellen kann es mehrere Minuten dauern, bis mit der Abfrage von Ereignissen aus dem Stream begonnen wird.

  • Bei Aktualisierungen der Zuordnung von Ereignisquellen kann es mehrere Minuten dauern, bis die Abfrage von Ereignissen aus dem Stream gestoppt und neu gestartet wird.

Dieses Verhalten bedeutet, dass, wenn Sie LATEST als Startposition für den Stream angeben, die Zuordnung von Ereignisquellen bei der Erstellung oder Aktualisierung möglicherweise Ereignisse übersieht. Um sicherzustellen, dass keine Ereignisse übersehen werden, geben Sie die Startposition des Streams als TRIM_HORIZON oder AT_TIMESTAMP an.

Skalierungsverhalten des Nachrichtendurchsatzes für selbstverwaltete Apache-Kafka-Zuordnungen von Ereignisquellen

Sie können zwischen zwei Modi der Skalierung des Nachrichtendurchsatzes für Ihre Amazon MSK-Zuordnung von Ereignisquellen wählen:

Standardmodus (auf Abruf)

Wenn Sie anfänglich eine selbstverwaltete Apache Kafka-Ereignisquelle erstellen, weist Lambda eine Standardanzahl von Event-Pollern zu, um alle Partitionen im Kafka-Thema zu verarbeiten. Lambda erhöht oder verringert automatisch die Anzahl der Ereignis-Poller je nach Nachrichtenlast.

In Intervallen von einer Minute wertet Lambda die Verbraucher-Offsetverzögerung aller Partitionen im Thema aus. Wenn die Offset-Verzögerung zu hoch ist, empfängt die Partition Nachrichten schneller als Lambda sie verarbeiten kann. Falls erforderlich, fügt Lambda dem Thema Ereignis-Poller hinzu oder entfernt sie. Dieser Prozess der automatischen Skalierung durch Hinzufügen oder Entfernen von Ereignis-Pollern erfolgt innerhalb von drei Minuten nach der Auswertung.

Wenn Ihre Ziel-Lambda-Funktion gedrosselt ist, reduziert Lambda die Anzahl der Ereignis-Poller. Diese Aktion verringert den Workload der Funktion, indem sie die Anzahl der Nachrichten reduziert, die Ereignis-Poller abrufen und an die Funktion senden können.

Um den Durchsatz Ihres Kafka-Themas zu überwachen, können Sie die Apache Kafka-Verbrauchermetriken wie consumer_lag und consumer_offset anzeigen.

Konfigurieren des bereitgestellten Modus

Für Workloads, bei denen Sie den Durchsatz Ihrer Zuordnung von Ereignisquellen optimieren müssen, können Sie den Bereitstellungsmodus verwenden. Im Bereitstellungsmodus definieren Sie Mindest- und Höchstgrenzen für die Anzahl der bereitgestellten Ereignis-Poller. Diese bereitgestellten Event-Poller sind auf Ihre Zuordnung von Ereignisquellen ausgerichtet und können unerwartete Meldungsspitzen sofort verarbeiten, wenn sie auftreten. Wir empfehlen die Verwendung des Bereitstellungsmodus für Kafka-Workloads, die strenge Leistungsanforderungen haben.

In Lambda ist ein Event Poller eine Recheneinheit, die bis zu 5% MBps des Durchsatzes verarbeiten kann. Nehmen wir als Referenz an, dass Ihre Ereignisquelle eine durchschnittliche Nutzlast von 1 MB erzeugt und die durchschnittliche Funktionsdauer 1 Sekunde beträgt. Wenn die Nutzlast keiner Transformation (wie Filterung) unterzogen wird, kann ein einzelner Poller 5 MBps Durchsatz- und 5 gleichzeitige Lambda-Aufrufe unterstützen. Die Verwendung des Bereitstellungsmodus verursacht zusätzliche Kosten. Kostenvoranschläge finden Sie unter AWS Lambda -Preise.

Im Bereitstellungsmodus liegt der Bereich der akzeptierten Werte für die Mindestanzahl der Ereignis-Poller (MinimumPollers) zwischen 1 und 200 (einschließlich). Der Bereich der akzeptierten Werte für die maximale Anzahl von Event-Pollern (MaximumPollers) liegt zwischen 1 und einschließlich 2.000. MaximumPollers muss größer als oder gleich MinimumPollers sein. Um eine geordnete Verarbeitung innerhalb der Partitionen zu gewährleisten, begrenzt Lambda das MaximumPollers auf die Anzahl der Partitionen im Thema.

Weitere Einzelheiten zur Auswahl geeigneter Werte für minimale und maximale Ereignis-Poller finden Sie unter Bewährte Verfahren und Überlegungen bei der Verwendung des Bereitstellungsmodus.

Sie können den Bereitstellungsmodus für Ihre selbst verwaltete Apache Kafka-Zuordnung von Ereignisquellen über die Konsole oder die Lambda-API konfigurieren.

So konfigurieren Sie den Bereitstellungsmodus für eine vorhandene selbstverwaltete Apache-Kafka-Zuordnung von Ereignisquellen (Konsole)
  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie die Funktion mit der selbstverwalteten Apache Kafka-Zuordnung von Ereignisquellen, für die Sie den Bereitstellungsmodus konfigurieren möchten.

  3. Wählen Sie Konfiguration und anschließend Auslöser aus.

  4. Wählen Sie die selbstverwaltete Apache-Kafka-Zuordnung von Ereignisquellen, für die Sie den Bereitstellungsmodus konfigurieren möchten und wählen Sie dann Bearbeiten.

  5. Wählen Sie unter Konfiguration der Zuordnung von Ereignisquellen die Option Bereitstellungsmodus konfigurieren aus.

    • Geben Sie für Minimum Event Pollers einen Wert zwischen 1 und 200 ein. Wenn Sie keinen Wert angeben, wählt Lambda einen Standardwert von 1.

    • Geben Sie für Maximum Event Pollers einen Wert zwischen 1 und 2000 ein. Dieser Wert muss größer oder gleich Ihrem Wert für Minimum Event Pollers sein. Wenn Sie keinen Wert angeben, wählt Lambda einen Standardwert von 200.

  6. Wählen Sie Save (Speichern) aus.

Sie können den Bereitstellungsmodus programmgesteuert mithilfe des Objekts in Ihrem konfigurieren. ProvisionedPollerConfig EventSourceMappingConfiguration Der folgende UpdateEventSourceMappingCLI-Befehl konfiguriert beispielsweise einen MinimumPollers Wert von 5 und einen MaximumPollers Wert von 100.

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Nachdem Sie den Bereitstellungsmodus konfiguriert haben, können Sie die Verwendung von Event-Pollern für Ihren Workload beobachten, indem Sie die ProvisionedPollers-Metrik überwachen. Weitere Informationen finden Sie unter Metriken zur Zuordnung von Ereignisquellen.

Um den Bereitstellungsmodus zu deaktivieren und zum Standardmodus (auf Abruf) zurückzukehren, können Sie den folgenden UpdateEventSourceMappingCLI-Befehl verwenden:

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{}'

Bewährte Verfahren und Überlegungen bei der Verwendung des Bereitstellungsmodus

Die optimale Konfiguration der minimalen und maximalen Ereignispoller für Ihre Zuordnung von Ereignisquellen hängt von den Leistungsanforderungen Ihrer Anwendung ab. Wir empfehlen Ihnen, mit den standardmäßigen Minimum Event Pollers zu beginnen, um das Leistungsprofil zu erstellen. Passen Sie Ihre Konfiguration auf der Grundlage der beobachteten Nachrichtenverarbeitungsmuster und Ihres gewünschten Leistungsprofils an.

Erhöhen Sie bei Workloads mit starkem Datenverkehr und strengen Leistungsanforderungen die Mindestanzahl der Event-Poller, um plötzliche Nachrichtenfluten zu bewältigen. Um zu ermitteln, wie viele Event-Poller mindestens erforderlich sind, sollten Sie die Nachrichten pro Sekunde Ihres Workloads und die durchschnittliche Nutzlastgröße berücksichtigen und die Durchsatzkapazität eines einzelnen Event-Pollers (bis zu 5 MBps) als Referenz verwenden.

Um eine geordnete Verarbeitung innerhalb einer Partition aufrechtzuerhalten, begrenzt Lambda die maximale Anzahl der Event-Poller auf die Anzahl der Partitionen im Thema. Darüber hinaus hängt die maximale Anzahl von Event-Pollern, auf die Ihr Zuordnung von Ereignisquellen skaliert werden kann, von den Gleichzeitigkeitseinstellungen der Funktion ab.

Wenn Sie den Bereitstellungsmodus aktivieren, aktualisieren Sie Ihre Netzwerkeinstellungen, um AWS PrivateLink VPC-Endpunkte und zugehörige Berechtigungen zu entfernen.

CloudWatch Amazon-Metriken

Lambda gibt die Metrik OffsetLag aus, während Ihre Funktion Datensätze verarbeitet. Der Wert dieser Metrik ist die Differenz (der Versatz) zwischen dem letzten Datensatz, der ins Kafka-Ereignisquellen-Thema geschrieben wurde, und dem letzten Datensatz, den die Konsumentengruppe Ihrer Funktion verarbeitet hat. Sie können mit OffsetLag die Latenz zwischen dem Hinzufügen eines Datensatzes und der Verarbeitung des Datensatzes durch Ihre Konsumentengruppe abschätzen.

Ein zunehmender Trend in OffsetLag kann auf Probleme mit Pollern in der Konsumentengruppe Ihrer Funktion hinweisen. Weitere Informationen finden Sie unter CloudWatch Metriken mit Lambda verwenden.