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.

Beheben Sie Probleme mit 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 Amazon MSK Replicator

Der Austausch eines Datenträgers führt aufgrund einer Überlastung der Replikation zu einer Überlastung

Bei einem ungeplanten Ausfall der Volume-Hardware ersetzt Amazon MSK das Volume möglicherweise durch eine neue Instance. Kafka füllt das neue Volume erneut auf, indem es Partitionen von anderen Brokern im Cluster repliziert. Sobald die Partitionen repliziert sind und den aktuellen Stand erreicht haben, kommen sie für eine Leadership- und In-Sync-Replica-Mitgliedschaft (ISR) in Frage.

Problem

In einem Broker, der sich nach einem Speicherwechsel erholt, sind einige Partitionen unterschiedlicher Größe möglicherweise vor anderen wieder online. Dies kann problematisch sein, da diese Partitionen den Datenverkehr desselben Brokers abwickeln können, der immer noch andere Partitionen abholt (repliziert). Dieser Replikationsdatenverkehr kann manchmal die zugrunde liegenden Volumendurchsatzgrenzen überlasten, die in der Standardeinstellung 250 MiB pro Sekunde betragen. Wenn diese Überlastung eintritt, wirkt sich dies auf alle Partitionen aus, die bereits überlastet sind. Dies führt zu Latenz im gesamten Cluster für alle Broker, die ISR mit diesen aufgefangenen Partitionen teilen (nicht nur 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 eine oder mehrere Ihrer Verbrauchergruppen in einem Zustand der ständigen Neuverteilung feststecken, könnte die Ursache ein Apache Kafka-Problem KAFKA-9752 sein, 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 Broker-Logs an Amazon CloudWatch Logs gesendet werden, erhalten Sie möglicherweise eine von zwei Ausnahmen.

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 den folgenden JSON-Code an.

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

Wenn Sie versuchen, das obige JSON 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, das 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-Zustellung 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 es, die mit einer bestimmten VPC verknüpften EC2-Sicherheitsgruppen programmgesteuert und in der Konsole zu verwalten .

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, aktualisieren Sie es AWS CLI auf die neueste Version. Eine ausführliche Anleitung zum Upgrade von finden Sie AWS CLI unter Installation des AWS Command Line Interface. Informationen zur Verwendung der 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.

Under-replicated Partitionen (URP) 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 keine ACLs für CLUSTER_ACTIONS festgelegt 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:

Über IPv6-Bootstrap kann nicht auf den Cluster zugegriffen werden

Wenn Sie Probleme haben, mithilfe der bereitgestellten IPv6-Bootstrap-Zeichenfolgen eine Verbindung zu einem Cluster herzustellen, gehen Sie wie folgt vor:

Auf den Cluster kann von innen nicht 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 zum Abrufen 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.

Amazon-EC2-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 Amazon-EC2-Instance aus, die sich in derselben VPC wie der Cluster befindet, finden Sie unter Beginnen Sie mit der Verwendung von Amazon MSK.

Amazon-EC2-Client und MSK-Cluster in verschiedenen VPCs

Wenn sich der Clientcomputer und der Cluster in zwei verschiedenen VPCs befinden, stellen Sie Folgendes sicher:

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

On-premises Kunde

Stellen Sie bei einem lokalen Client, der für die Verbindung mit dem MSK-Cluster eingerichtet ist Site-to-Site VPN, Folgendes sicher:

Weitere Anleitungen zur Fehlerbehebung finden Sie unter Site-to-Site VPN Problembehandlung bei Client-VPN. https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html

Direct Connect

Wenn der Client es verwendet Direct Connect, finden Sie weitere Informationen unter Problembehandlung 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.

Fehlgeschlagene Authentifizierung: 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 zu 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: AmazonMSKFullAccess.

Die MSK-Konfiguration kann nicht aktualisiert KafkaVersionsList werden

Wenn Sie die KafkaVersionsList Eigenschaft in der Ressource AWS: :MSK: :Configuration aktualisieren, schlägt die Aktualisierung mit dem folgenden Fehler fehl.

Resource of type 'AWS::MSK::Configuration' with identifier '<identifierName>' already exists.

Wenn Sie die KafkaVersionsList Eigenschaft aktualisieren, AWS CloudFormation erstellt eine neue Konfiguration mit der aktualisierten Eigenschaft, bevor Sie die alte Konfiguration löschen. Die CloudFormation Stack-Aktualisierung schlägt fehl, weil die neue Konfiguration denselben Namen wie die vorhandene Konfiguration verwendet. Ein solches Update erfordert einen Ressourcenaustausch. Für eine erfolgreiche Aktualisierung KafkaVersionsList müssen Sie im gleichen Vorgang auch die https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name Name-Eigenschaft aktualisieren.

Wenn Ihre Konfiguration mit Clustern verknüpft ist, die mit AWS-Managementkonsole oder erstellt wurden AWS CLI, fügen Sie Ihrer Konfigurationsressource außerdem Folgendes hinzu, um fehlgeschlagene Versuche zum Löschen von Ressourcen zu verhindern.

UpdateReplacePolicy: Retain

Nachdem das Update erfolgreich war, wechseln Sie zur Amazon MSK-Konsole und löschen Sie die alte Konfiguration. Informationen zu MSK-Konfigurationen finden Sie unter Von Amazon MSK bereitgestellte Konfiguration.

Fehler bei der Konfiguration benutzerdefinierter Domainnamen

Wenn Sie eine Konfiguration erstellen oder anwenden, die Folgendes umfasstcustom.advertised.listeners, können die folgenden Fehler auftreten. Weitere Informationen zur Konfiguration benutzerdefinierter Domänennamen finden Sie unterKonfigurieren Sie benutzerdefinierte Domainnamen für Ihren Amazon MSK-Cluster.

Ungültiges Format

Die API gibt einen HTTP 400-Fehler mit invalidParameter=serverproperties der folgenden Meldung zurück.

Invalid custom.advertised.listeners format. Expected: LISTENER_NAME://host:port+{broker_id} (comma-separated for multiple).

Der von Ihnen angegebene Wert custom.advertised.listeners entspricht nicht dem erforderlichen Format. Korrigieren Sie den Wert, sodass er das Muster verwendetLISTENER_NAME://hostname:port+{broker_id}, stellen Sie sicher, dass die {broker_id} Vorlagenvariable im Port erscheint, sodass jeder Broker in eine eindeutige Adresse aufgelöst wird, und trennen Sie mehrere Listener durch ein Komma. Senden Sie dann die korrigierte Konfiguration erneut mit. UpdateClusterConfiguration

Der Listener ist nicht an den Cluster gebunden

Die API gibt einen HTTP 400-Fehler mit invalidParameter=configurationInfo und der folgenden Meldung zurück.

Custom advertised listener(s) [CLIENT_SECURE] are not bound on this cluster. Valid client listeners: [CLIENT_IAM]. A broker cannot advertise a listener it does not bind.

Der von Ihnen angegebene Listener ist in Ihrem Cluster nicht aktiv. Dieser Fehler tritt währenddessen aufUpdateClusterConfiguration, nicht CreateConfiguration währenddessen. Ein Broker kann nur für einen Listener werben, den er auch tatsächlich bindet. Aktualisieren Sie Ihren custom.advertised.listeners Wert so, dass er auf einen der gültigen Client-Listener verweist, die in der Fehlermeldung für Ihren Cluster aufgeführt sind (z. B.). CLIENT_IAM Wenn der Listener auf dem Cluster noch nicht aktiviert ist (z. B.CLIENT_SECURE), aktivieren Sie zuerst diese Authentifizierung oder diesen Listenertyp. Wenden Sie dann die Konfiguration erneut an mit. UpdateClusterConfiguration

Der Aktualisierungsvorgang schlägt fehl

Überprüfen Sie Ihren custom.advertised.listeners Wert auf Probleme wie Portkonflikte oder unlösbare Hostnamen, korrigieren Sie die Konfiguration und wenden Sie sie erneut mit an. UpdateClusterConfiguration

Wenn der Fehler auf einen Skalierungsvorgang zurückzuführen ist, fügen Sie den entsprechenden Network Load Balancer-Listener, die Zielgruppe und den DNS-Eintrag für jeden neuen Broker hinzu. Vergewissern Sie sich, dass alle Clients den benutzerdefinierten Domainnamen auflösen können. Sie können auch zur vorherigen funktionierenden Konfiguration zurückkehren, indem Sie die alte Konfiguration anwenden.