Fehlerbehebung bei Ihrem MSK Amazon-Cluster - Amazon Managed Streaming für Apache Kafka
Der Austausch eines Volumes führt aufgrund einer Überlastung der Replikation zu einer Überlastung der FestplatteVerbrauchergruppe steckt im Status PreparingRebalance festFehler beim Senden von Broker-Protokollen an Amazon CloudWatch LogsKeine Standard-SicherheitsgruppeDer Cluster scheint im Status festzustecken CREATINGDer Clusterstatus geht von CREATING bis FAILEDDer Clusterstatus lautetACTIVE, aber Produzenten können keine Daten senden oder Verbraucher können keine Daten empfangenAWS CLI erkennt Amazon nicht MSKPartitionen werden auf „offline“ festgelegt oder Replikate sind nicht synchronisiert.Wenig SpeicherplatzWenig ArbeitsspeicherDer Produzent erhält NotLeaderForPartitionExceptionZu wenig replizierte Partitionen (URP) größer als NullDer Cluster hat die Themen __amazon_msk_canary und __amazon_msk_canary_stateDie Partitionsreplikation schlägt fehlEs kann nicht auf einen Cluster zugegriffen werden, für den der öffentliche Zugriff aktiviert istVon innen kann nicht auf den Cluster zugegriffen werden AWS: NetzwerkproblemeFehlgeschlagene Authentifizierung: Zu viele VerbindungenMSKServerlos: Die Clustererstellung schlägt fehl

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.

Fehlerbehebung bei Ihrem MSK Amazon-Cluster

Die folgenden Informationen können Ihnen bei der Behebung von Problemen helfen, die Sie möglicherweise mit Ihrem MSK Amazon-Cluster haben. Sie können Ihr Problem auch an folgende Adresse posten AWS re:Post. Informationen zur Fehlerbehebung bei Amazon MSK Replicator finden Sie unterProblembehandlung bei Replicator MSK.

Der Austausch eines Volumes führt aufgrund einer Überlastung der Replikation zu einer Überlastung der Festplatte

Bei einem ungeplanten Hardware-Ausfall eines Volumes MSK kann Amazon das Volume durch eine neue Instance ersetzen. Kafka füllt das neue Volume erneut auf, indem es Partitionen von anderen Brokern im Cluster repliziert. Sobald Partitionen repliziert und aufgeholt wurden, kommen sie für eine Leadership- und In-Sync-Mitgliedschaft bei replica () in Frage. ISR

Problem

Bei einem Broker, der sich nach dem Austausch eines Volumes erholt, kann es sein, dass einige Partitionen unterschiedlicher Größe wieder online sind, bevor andere Partitionen wieder online sind. Dies kann problematisch sein, da diese Partitionen Datenverkehr von demselben Broker bereitstellen können, der immer noch andere Partitionen abholt (repliziert). Dieser Replikationsverkehr kann manchmal die zugrundeliegenden Volumendurchsatzgrenzen, die im Standardfall 250 MiB pro Sekunde betragen, sättigen. Wenn diese Sättigung eintritt, sind alle Partitionen betroffen, die bereits abgeholt wurden. Dies führt zu einer Latenz im gesamten Cluster bei allen Brokern, die die Partitionen gemeinsam nutzen ISR (nicht nur die Leader-Partitionen aufgrund von Remote-Acks). acks=all Dieses Problem tritt häufiger bei größeren Clustern auf, die eine größere Anzahl von Partitionen mit unterschiedlicher Größe haben.

Empfehlung

  • Um den I/O-Status der Replikation zu verbessern, stellen Sie sicher, dass die Thread-Einstellungen nach bewährten Methoden vorhanden sind.

  • Um die Wahrscheinlichkeit einer zugrundeliegenden Volumensättigung zu verringern, sollten Sie bereitgestellten Speicher mit einem höheren Durchsatz aktivieren. Für Replikationsfälle mit hohem Durchsatz wird ein Mindestdurchsatz von 500 MiB/s empfohlen, der tatsächlich benötigte Wert hängt jedoch vom Durchsatz und vom Anwendungsfall ab. Bereitstellen des Speicherdurchsatzes.

  • Um den Replikationsdruck num.replica.fetchers zu minimieren, senken Sie den Wert auf den Standardwert von2.

Verbrauchergruppe steckt im Status PreparingRebalance fest

Wenn eine oder mehrere Ihrer Nutzergruppen ständig neu gewichtet werden, könnte dies am Apache Kafka-Problem KAFKA-9752 liegen, das die Apache Kafka-Versionen 2.3.1 und 2.4.1 betrifft.

Um dieses Problem zu beheben, empfehlen wir Ihnen, Ihren Cluster auf die Version MSKAmazon-Bugfix Version 2.4.1.1 zu aktualisieren, die eine Lösung für dieses Problem enthält. Informationen zur Aktualisierung eines vorhandenen Clusters auf MSK Amazon-Bug-Fix-Version 2.4.1.1 finden Sie unter. Aktualisieren der Apache Kafka-Version

Um dieses Problem zu lösen, ohne den Cluster auf die MSK Amazon-Bug-Fix-Version 2.4.1.1 zu aktualisieren, müssen Sie entweder die zu Static-Membership-Protokoll verwendenden Kafka-Clients oder den koordinierenden Broker-Knoten Identifizieren und neu starten der festgefahrenen Verbrauchergruppe einrichten.

Implementierung des Static-Membership-Protokolls

Gehen Sie folgendermaßen vor, um das Static-Membership-Protokoll in Ihren Clients zu implementieren:

  1. Setzen Sie die group.instance.id-Eigenschaft Ihrer Kafka-Verbraucher-Konfiguration auf eine statische Zeichenfolge, die den Verbraucher in der Gruppe identifiziert.

  2. Stellen Sie sicher, dass andere Instances der Konfiguration aktualisiert werden, sodass sie die statische Zeichenfolge verwenden.

  3. Stellen Sie die Änderungen für Ihre Kafka-Verbraucher bereit.

Die Verwendung des Static Membership Protocol ist effektiver, wenn das Sitzungs-Timeout in der Client-Konfiguration auf eine Dauer festgelegt ist, die es dem Verbraucher ermöglicht, sich zu erholen, ohne vorzeitig eine Neuverteilung der Verbrauchergruppen auszulösen. Wenn Ihre Verbraucheranwendung beispielsweise eine Nichtverfügbarkeit von 5 Minuten toleriert, wäre ein angemessener Wert für das Sitzungs-Timeout 4 Minuten anstelle des Standardwerts von 10 Sekunden.

Anmerkung

Die Verwendung des Static-Membership-Protokolls verringert nur die Wahrscheinlichkeit, dass dieses Problem auftritt. Dieses Problem kann auch dann auftreten, wenn Sie das Static-Membership-Protokoll verwenden.

Den koordinierenden Broker-Knoten neu starten

Gehen Sie wie folgt vor, um den koordinierenden Broker-Knoten neu zu starten:

  1. Identifizieren Sie den Gruppenkoordinator mithilfe des Befehls kafka-consumer-groups.sh.

  2. Starten Sie den Gruppenkoordinator der festgefahrenen Verbrauchergruppe mithilfe der Aktion neu. RebootBrokerAPI

Fehler beim Senden von Broker-Protokollen an Amazon CloudWatch Logs

Wenn Sie versuchen, Ihren Cluster so einzurichten, dass er Broker-Logs an Amazon CloudWatch Logs sendet, kann es zu einer von zwei Ausnahmen kommen.

Wenn Sie die Ausnahme InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded erhalten, wiederholen Sie den Vorgang, verwenden jedoch Protokollgruppen, die mit /aws/vendedlogs/ beginnen. Weitere Informationen finden Sie unter Aktivieren der Protokollierung aus bestimmten Amazon Web Services.

Wenn Sie eine InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded Ausnahme erhalten, wählen Sie eine bestehende Amazon CloudWatch Logs-Richtlinie in Ihrem Konto aus und fügen Sie ihr Folgendes JSON hinzu.

{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}

Wenn Sie versuchen, die JSON oben genannten Informationen an eine bestehende Richtlinie anzuhängen, aber eine Fehlermeldung erhalten, die besagt, dass Sie die maximale Länge für die von Ihnen gewählte Richtlinie erreicht haben, versuchen Sie, sie an eine andere Ihrer Amazon CloudWatch Logs-Richtlinien JSON anzuhängen. Nachdem Sie das JSON an eine bestehende Richtlinie angehängt haben, versuchen Sie erneut, die Broker-Log-Übermittlung an Amazon Logs einzurichten. CloudWatch

Keine Standard-Sicherheitsgruppe

Wenn Sie versuchen, einen Cluster zu erstellen, und die Fehlermeldung angezeigt wird, dass es keine Standardsicherheitsgruppe gibt, liegt das möglicherweise daran, VPC dass Sie eine verwenden, die mit Ihnen geteilt wurde. Bitten Sie Ihren Administrator, Ihnen die Erlaubnis zu erteilen, die Sicherheitsgruppen in diesem Bereich zu beschreiben, VPC und versuchen Sie es erneut. Ein Beispiel für eine Richtlinie, die diese Aktion zulässt, finden Sie unter AmazonEC2: Ermöglicht die programmgesteuerte Verwaltung von EC2 Sicherheitsgruppen, die einer bestimmten Person zugeordnet sindVPC, und zwar programmgesteuert und in der Konsole.

Der Cluster scheint im Status festzustecken CREATING

Gelegentlich dauert die Cluster-Erstellung bis zu 30 Minuten. Warten Sie 30 Minuten und überprüfen Sie den Status des Clusters erneut.

Der Clusterstatus geht von CREATING bis FAILED

Versuchen Sie erneut, den Cluster zu erstellen.

Der Clusterstatus lautetACTIVE, aber Produzenten können keine Daten senden oder Verbraucher können keine Daten empfangen

  • Wenn die Cluster-Erstellung erfolgreich ist (der Cluster-Status lautet „ACTIVE“), Sie jedoch keine Daten senden oder empfangen können, stellen Sie sicher, dass Ihre Produzenten- und Konsumentenanwendungen auf den Cluster zugreifen können. Weitere Informationen finden Sie in der Anleitung in Schritt 3: Einen Client-Computer erstellen.

  • Wenn Ihre Produzenten und Verbraucher Zugriff auf den Cluster haben, aber immer noch Probleme bei der Erzeugung und Nutzung von Daten haben, könnte die Ursache KAFKA-7697 sein. Dies betrifft Apache Kafka Version 2.1.0 und kann zu einem Deadlock in einem oder mehreren Brokern führen. Ziehen Sie eine Migration zu Apache Kafka 2.2.1 in Betracht. Diese Version ist von diesem Fehler nicht betroffen. Weitere Informationen zur Migration finden Sie unter Migration zu einem Amazon-MSK-Cluster.

AWS CLI erkennt Amazon nicht MSK

Wenn du die hast AWS CLI installiert, aber es erkennt die MSK Amazon-Befehle nicht, aktualisiere dein AWS CLI auf die neueste Version. Für detaillierte Anweisungen zum Upgrade des AWS CLI, siehe Installation des AWS Command Line Interface. Für Informationen zur Verwendung des AWS CLI Informationen zum Ausführen von MSK Amazon-Befehlen finden Sie unterAmazonMSK: So funktioniert's.

Partitionen werden auf „offline“ festgelegt oder Replikate sind nicht synchronisiert.

Dies können Anzeichen von wenig Speicherplatz sein. Siehe Wenig Speicherplatz.

Wenig Speicherplatz

Lesen Sie die folgenden bewährten Methoden für die Verwaltung des Speicherplatzes: Überwachen der Festplattenkapazität und Anpassen der Datenaufbewahrungsparameter.

Wenig Arbeitsspeicher

Wenn Sie sehen, dass die MemoryUsed-Metrik hoch oder MemoryFree niedrig ist, deutet das nicht auf ein Problem hin. Apache Kafka wurde entwickelt, um so viel Speicher wie möglich zu verwenden, und es verwaltet ihn optimal.

Der Produzent erhält NotLeaderForPartitionException

Dies ist oft ein vorübergehender Fehler. Legen Sie den retries-Konfigurationsparameter des Produzenten auf einen Wert fest, der höher als sein aktueller Wert ist.

Zu wenig replizierte Partitionen (URP) größer als Null

Die Überwachung der UnderReplicatedPartitions-Metrik ist wichtig. In einem fehlerfreien MSK Cluster hat diese Metrik den Wert 0. Der Wert kann aus Folgenden Gründen größer als Null sein.

  • Falls es zu Spitzenwerten bei UnderReplicatedPartitions kommt, wird der Cluster möglicherweise nicht in der richtigen Größe für die Verarbeitung von eingehendem und ausgehendem Datenverkehr bereitgestellt. Siehe Bewährte Methoden.

  • Wenn der UnderReplicatedPartitions Wert durchweg größer als 0 ist, auch in Zeiten mit geringem Datenaufkommen, liegt das Problem möglicherweise darin, dass Sie Beschränkungen festgelegt habenACLs, die Brokern keinen Zugriff auf das Thema gewähren. Um Partitionen replizieren zu können, müssen Broker für beide READ Themen autorisiert sein. DESCRIBE DESCRIBEwird standardmäßig mit der READ Autorisierung erteilt. Informationen zur Einstellung ACLs finden Sie unter Autorisierung und ACLs in der Apache Kafka-Dokumentation.

Der Cluster hat die Themen __amazon_msk_canary und __amazon_msk_canary_state

Möglicherweise sehen Sie, dass Ihr MSK Cluster ein Thema mit dem Namen __amazon_msk_canary und ein anderes mit diesem Namen __amazon_msk_canary_state hat. Dies sind interne Themen, die Amazon für Cluster-Integritäts- und Diagnosemetriken MSK erstellt und verwendet. Diese Themen haben eine vernachlässigbare Größe und können nicht gelöscht werden.

Die Partitionsreplikation schlägt fehl

Stellen Sie sicher, dass Sie CLUSTER _ nicht ACLs aktiviert habenACTIONS.

Es kann nicht auf einen Cluster zugegriffen werden, für den der öffentliche Zugriff aktiviert ist

Wenn für Ihren Cluster der öffentliche Zugriff aktiviert ist, Sie aber immer noch nicht über das Internet darauf zugreifen können, gehen Sie wie folgt vor:

  1. Stellen Sie sicher, dass die Regeln der Sicherheitsgruppe für eingehenden Datenverkehr Ihre IP-Adresse und den Port des Clusters erlauben. Eine Liste der Cluster-Portnummern finden Sie unter Port-Informationen. Stellen Sie außerdem sicher, dass die Regeln für ausgehenden Datenverkehr der Sicherheitsgruppe ausgehende Kommunikation zulassen. Weitere Informationen zu Sicherheitsgruppen und ihren Regeln für eingehenden und ausgehenden Datenverkehr finden Sie unter Sicherheitsgruppen für Sie VPC im VPC Amazon-Benutzerhandbuch.

  2. Stellen Sie sicher, dass Ihre IP-Adresse und der Port des Clusters in den Regeln für eingehenden Datenverkehr des Cluster-Netzwerks zulässig sind. VPC ACL Im Gegensatz zu Sicherheitsgruppen ACLs sind Netzwerke zustandslos. Dies bedeutet, dass Sie die Regeln für den ein- und ausgehenden Datenverkehr konfigurieren müssen. Erlauben Sie in den Regeln für ausgehenden Datenverkehr den gesamten Datenverkehr (Portbereich: 0–65535) zu Ihrer IP-Adresse zu. Weitere Informationen finden Sie unter Regeln hinzufügen und löschen im VPC Amazon-Benutzerhandbuch.

  3. Stellen Sie sicher, dass Sie die Bootstrap-Brokers-Zeichenfolge mit öffentlichem Zugriff für den Zugriff auf den Cluster verwenden. Ein MSK Cluster, bei dem der öffentliche Zugriff aktiviert ist, hat zwei verschiedene Bootstrap-Broker-Strings, eine für den öffentlichen Zugriff und eine für den Zugriff von innen AWS. Weitere Informationen finden Sie unterHolen Sie sich die Bootstrap-Broker mit dem AWS Management Console.

Von innen kann nicht auf den Cluster zugegriffen werden AWS: Netzwerkprobleme

Wenn Sie über eine Apache Kafka-Anwendung verfügen, die nicht erfolgreich mit einem MSK Cluster kommunizieren kann, führen Sie zunächst den folgenden Konnektivitätstest durch.

  1. Verwenden Sie eine der in Die Bootstrap-Broker für einen Amazon-Cluster abrufen MSK beschriebenen Methoden, um die Adressen der Bootstrap-Broker zu erhalten.

  2. Ersetzen Sie im folgenden Befehl bootstrap-broker mit einer der Brokeradressen, die Sie im vorherigen Schritt erhalten haben. Ersetzen port-number mit 9094, wenn der Cluster für die Verwendung der TLS Authentifizierung eingerichtet ist. Wenn der Cluster keine TLS Authentifizierung verwendet, ersetzen Sie port-number mit 9092. Führen Sie den Befehl vom Clientcomputer aus.

    telnet bootstrap-broker port-number

    Wobei die Portnummer ist:

    • 9094, wenn der Cluster für die Verwendung TLS der Authentifizierung eingerichtet ist.

    • 9092 Wenn der Cluster keine Authentifizierung verwendetTLS.

    • Eine andere Portnummer ist erforderlich, wenn der öffentliche Zugriff aktiviert ist.

    Führen Sie den Befehl vom Clientcomputer aus.

  3. Wiederholen Sie den vorherigen Befehl für alle Bootstrap-Broker.

Wenn der Client-Computer auf die Broker zugreifen kann, bedeutet dies, dass keine Verbindungsprobleme vorliegen. Führen Sie in diesem Fall den folgenden Befehl aus, um zu überprüfen, ob Ihr Apache Kafka Client korrekt eingerichtet ist. Um zu bekommen bootstrap-brokers, verwenden Sie eine der unter beschriebenen MethodenDie Bootstrap-Broker für einen Amazon-Cluster abrufen MSK. Ersetzen topic mit dem Namen Ihres Themas.

<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic

Wenn der vorherige Befehl erfolgreich ist, bedeutet dies, dass Ihr Client korrekt eingerichtet ist. Wenn Sie immer noch nicht in der Lage sind, aus einer Anwendung zu produzieren und zu konsumieren, debuggen Sie das Problem auf Anwendungsebene.

Wenn der Client-Computer nicht auf die Broker zugreifen kann, finden Sie in den folgenden Unterabschnitten Anleitungen, die auf Ihrem Client-Computer-Setup basieren.

EC2Amazon-Client und MSK Cluster im selben VPC

Wenn sich der Client-Computer im selben VPC MSK Cluster befindet, stellen Sie sicher, dass die Sicherheitsgruppe des Clusters über eine Regel für eingehenden Datenverkehr verfügt, die Datenverkehr von der Sicherheitsgruppe des Client-Computers akzeptiert. Informationen zum Einrichten dieser Regeln finden Sie unter Sicherheitsgruppenregeln. Ein Beispiel für den Zugriff auf einen Cluster von einer EC2 Amazon-Instance aus, die sich im selben VPC Cluster befindet, finden Sie unterErste Schritte mit Amazon MSK.

EC2Amazon-Client und MSK Cluster in verschiedenen VPCs

Wenn sich der Client-Computer und der Cluster in zwei verschiedenen Umgebungen befindenVPCs, stellen Sie Folgendes sicher:

  • Die beiden VPCs werden miteinander verbunden.

  • Der Status der Peering-Verbindung ist aktiv.

  • Die Routentabellen der beiden VPCs sind korrekt eingerichtet.

Informationen zum VPC Peering finden Sie unter Arbeiten mit VPC Peering-Verbindungen.

On-Premises-Client

Im Fall eines lokalen Clients, der so eingerichtet ist, dass er eine Verbindung mit dem Cluster herstellt MSK AWS VPN, stellen Sie Folgendes sicher:

  • Der VPN Verbindungsstatus istUP. Informationen zum Überprüfen des VPN Verbindungsstatus finden Sie unter Wie überprüfe ich den aktuellen Status meines VPN Tunnels? .

  • Die Routentabelle des Clusters VPC enthält die Route für ein lokales SystemCIDR, dessen Ziel das Format Virtual private gateway(vgw-xxxxxxxx) hat.

  • Die Sicherheitsgruppe des MSK Clusters erlaubt Datenverkehr auf Port 2181, Port 9092 (wenn Ihr Cluster Klartext-Verkehr akzeptiert) und Port 9094 (wenn Ihr Cluster -verschlüsselten Verkehr akzeptiert). TLS

Für mehr AWS VPN Anleitungen zur Fehlerbehebung finden Sie unter Troubleshooting Client VPN.

AWS Direct Connect

Wenn der Client verwendet AWS Direct Connect, siehe Problembehandlung AWS Direct Connect.

Wenn die vorherige Anleitung zur Fehlerbehebung das Problem nicht beheben kann, stellen Sie sicher, dass keine Firewall den Netzwerkverkehr blockiert. Verwenden Sie zum weiteren Debuggen Tools wie tcpdump und, Wireshark um den Datenverkehr zu analysieren und sicherzustellen, dass er den MSK Cluster erreicht.

Fehlgeschlagene Authentifizierung: Zu viele Verbindungen

Der Failed authentication ... Too many connects Fehler weist darauf hin, dass ein Broker sich selbst schützt, weil ein oder mehrere IAM Clients versuchen, mit einer aggressiven Geschwindigkeit eine Verbindung zu ihm herzustellen. Um Brokern zu helfen, eine höhere Anzahl neuer IAM Verbindungen zu akzeptieren, können Sie den reconnect.backoff.msKonfigurationsparameter erhöhen.

Weitere Informationen zu den Ratenlimits für neue Verbindungen pro Broker finden Sie auf der MSKAmazon-Kontingent-Seite.

MSKServerlos: Die Clustererstellung schlägt fehl

Wenn Sie versuchen, einen MSK serverlosen Cluster zu erstellen, und der Workflow fehlschlägt, sind Sie möglicherweise nicht berechtigt, einen VPC Endpunkt zu erstellen. Stellen Sie sicher, dass Ihr Administrator Ihnen die Erlaubnis erteilt hat, einen VPC Endpunkt zu erstellen, indem Sie die ec2:CreateVpcEndpoint Aktion zulassen.

Eine vollständige Liste der Berechtigungen, die für die Ausführung aller MSK Amazon-Aktionen erforderlich sind, finden Sie unterAWS verwaltete Richtlinie: Ein mazonMSKFull Zugriff.