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.

Problembehandlung bei Ihrem Amazon MSK-Cluster

Die folgenden Informationen können zum Beheben von Problemen mit Ihrem Amazon-MSK-Cluster nützlich sein. Sie können Ihr Problem auch im AWS re:Post posten. Informationen zur Fehlerbehebung bei Amazon MSK Replicator finden Sie unter. Problembehandlung bei Replicator MSK

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

Bei einem ungeplanten Ausfall der Volume-Hardware kann Amazon MSK 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 ISR-Mitgliedschaft (In-Sync Replica) in Frage.

Problem

Bei einem Broker, der sich nach dem Austausch eines Volumes erholt, können einige Partitionen unterschiedlicher Größe vor anderen wieder online gehen. 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 ISR mit den aufgenommenen Partitionen teilen (nicht nur bei 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.

Verbrauchergruppe steckt im Status PreparingRebalance fest

Wenn sich eine oder mehrere Ihrer Verbrauchergruppen in einem Zustand der ständigen Neuausrichtung befinden, kann 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 Amazon-MSK-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 die Amazon-MSK-Bugfix-Version 2.4.1.1 finden Sie unter Aktualisieren Sie die Apache Kafka-Version.

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

Implementierung des Static-Membership-Protokolls

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

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.

Den koordinierenden Broker-Knoten neu starten

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

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 hängen Sie die folgende JSON-Datei an.

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

Wenn Sie versuchen, den obigen JSON-Code 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, den JSON an eine andere Ihrer Amazon CloudWatch Logs-Richtlinien 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 einen Fehler über das Fehlen einer Standardsicherheitsgruppe erhalten, verwenden Sie möglicherweise eine VPC, die für Sie freigegeben wurde. Bitten Sie Ihren Administrator, Ihnen die Berechtigung zur Beschreibung der Sicherheitsgruppen auf dieser VPC zu erteilen, und versuchen Sie es erneut. Ein Beispiel für eine Richtlinie, die diese Aktion zulässt, finden Sie unter Amazon EC2: Ermöglicht die programmgesteuerte Verwaltung von EC2 Sicherheitsgruppen, die einer bestimmten VPC zugeordnet sind, und zwar programmgesteuert und in der Konsole.

Der Cluster steckt anscheinend im Status „CREATING“ fest.

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

Der Cluster-Status wird von „CREATING“ in „FAILED“ geändert.

Versuchen Sie erneut, den Cluster zu erstellen.

Der Cluster-Status ist „ACTIVE“, Produzenten können jedoch keine Daten senden oder Konsumenten können keine Daten empfangen.

AWS CLI erkennt Amazon MSK nicht

Wenn Sie das AWS CLI installiert haben, es aber die Amazon MSK-Befehle nicht erkennt, führen Sie ein Upgrade AWS CLI auf die neueste Version durch. Detaillierte Anweisungen zum Upgrade von finden Sie AWS CLI unter Installation von. AWS Command Line Interface Informationen zur Verwendung der Befehle AWS CLI zum Ausführen von Amazon MSK-Befehlen finden Sie unterDie wichtigsten Funktionen und Konzepte von Amazon MSK.

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.

Die unterreplizierten Partitionen (URP) sind größer als Null

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

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 dem Namen __amazon_msk_canary_state hat. Dies sind interne Themen, die Amazon MSK erstellt und für Metriken zum Cluster-Zustand und zur Diagnose 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_ACTIONS nicht ACLs aktiviert haben.

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:

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.

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. Verwenden Sie bootstrap-brokers dazu eine der unter beschriebenen MethodenHolen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster. topicErsetzen Sie es durch den 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.

EC2 Amazon-Client und MSK-Cluster in derselben VPC

Wenn sich der Client-Computer in derselben VPC wie der 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 in derselben VPC wie der Cluster befindet, finden Sie unterErste Schritte mit Amazon MSK.

EC2 Amazon-Client und MSK-Cluster in verschiedenen VPCs

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

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

On-Premises-Client

Stellen Sie bei einem lokalen Client, der so eingerichtet ist, dass er eine Verbindung zum MSK-Cluster herstellt AWS VPN, Folgendes sicher:

Weitere Anleitungen AWS VPN zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Client VPN.

AWS Direct Connect

Wenn der Client verwendet AWS Direct Connect, finden Sie weitere Informationen unter 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 zum Analysieren des Datenverkehrs und stellen Sie sicher, dass er den MSK-Cluster erreicht.

Fehlgeschlagene Authentifizierung: Zu viele Verbindungen

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

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

Authentifizierung fehlgeschlagen: Sitzung zu kurz

Der Failed authentication ... Session too short Fehler tritt auf, wenn Ihr Client versucht, mithilfe von IAM-Anmeldeinformationen, die bald ablaufen, eine Verbindung zu einem Cluster herzustellen. Stellen Sie sicher, dass Sie überprüfen, wie Ihre IAM-Anmeldeinformationen aktualisiert werden. Höchstwahrscheinlich werden die Anmeldeinformationen zu kurz vor Ablauf der Sitzung ersetzt, was zu Problemen auf der Serverseite und Authentifizierungsfehlern führt.

MSK Serverless: Die Cluster-Erstellung schlägt fehl

Wenn Sie versuchen, einen MSK-Serverless-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 Berechtigung 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 Amazon-MSK-Aktionen erforderlich sind, finden Sie unter AWS verwaltete Richtlinie: Amazon MSKFull Access.