Wie behebe ich Fehler, die ich erhalte, wenn ich versuche, eine Verbindung zu meinem Amazon MSK-Cluster herzustellen?

Lösung

Fehler, die nicht mit einem bestimmten Authentifizierungstyp zusammenhängen

Wenn du versuchst, eine Verbindung zum Amazon MSK-Cluster herzustellen, wird möglicherweise einer der folgenden Fehler angezeigt, der nicht mit dem von dir verwendeten Authentifizierungstyp zusammenhängt.

java.lang.OutOfMemoryError: Java heap space

Du erhältst den Fehler OutOfMemoryError, wenn du einen Befehl für Cluster-Operationen ohne die Client-Eigenschaftendatei ausführst. Um dieses Problem zu beheben, nimm die entsprechenden Eigenschaften auf der Grundlage des Authentifizierungstyps in die Datei client.properties auf.

Beispielbefehl mit nur einem AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Authentifizierungsport:

./kafka-topics.sh --create --bootstrap-server $BOOTSTRAP:9098 --replication-factor 3 --partitions 1 --topic TestTopic

Beispielbefehl mit einem IAM-Authentifizierungsport und der Client-Eigenschaftendatei:

./kafka-topics.sh --create --bootstrap-server $BOOTSTRAP:9098  --command-config client.properties --replication-factor 3 --partitions 1 --topic TestTopic

org.apache.kafka.common.errors.TimeoutException: Zeitüberschreitung beim Warten auf eine Knotenzuweisung. Call: createTopics

Möglicherweise erhältst du den TimeoutException-Fehler, wenn eine Netzwerkfehlkonfiguration zwischen der Client-Anwendung und dem Amazon MSK-Cluster vorliegt.

Führe den folgenden Konnektivitätstest auf dem Client-Computer aus, um dieses Problem zu beheben:

telnet bootstrap-broker port-number

Hinweis: Ersetze bootstrap-broker durch eine der Broker-Adressen aus dem Amazon MSK-Cluster. Ersetze port-number durch den entsprechenden Portwert, der auf der für den Cluster aktivierten Authentifizierung basiert.

Wenn der Client-Computer auf die Broker zugreifen kann, gibt es keine Verbindungsprobleme. Wenn der Client-Computer nicht auf die Broker zugreifen kann, überprüfe die Netzwerkkonnektivität. Überprüfe die Regeln für eingehenden und ausgehenden Datenverkehr für die Sicherheitsgruppe.

org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to access topics: [test_topic]

Du erhältst den TopicAuthorizationException-Fehler, wenn du eine IAM-Authentifizierung verwendest und die Zugriffsrichtlinie Themenoperationen wie WriteData und ReadData blockiert.

Hinweis: Berechtigungsgrenzen und Service-Kontrollrichtlinien (SCP) blockieren auch den Versuch eines Benutzers, ohne die erforderliche Autorisierung eine Verbindung zum Cluster herzustellen.

Wenn du eine Authentifizierung verwendest, bei der es sich nicht um IAM handelt, überprüfe, ob du Zugriffssteuerungslisten (ACLs) auf Themenebene hinzugefügt hast, die Operationen blockieren.

Führe den folgenden Befehl aus, um die ACLs aufzulisten, die auf ein Thema angewendet werden:

bin/kafka-acls.sh --bootstrap-server $BOOTSTRAP:PORT --command-config adminclient-configs.conf --list --topic testtopic

ZooKeeperClientTimeoutException

Möglicherweise erhältst du den Fehler ZooKeeperClientTimeoutException, wenn der Client versucht, über die Apache ZooKeeper-Zeichenfolge eine Verbindung zum Cluster herzustellen, und die Verbindung nicht hergestellt werden kann. Möglicherweise erhältst du diesen Fehler auch, wenn die Apache ZooKeeper-Zeichenfolge falsch ist.

Beispiel für eine falsche Apache Zookeeper-Zeichenfolge:

./kafka-topics.sh --zookeeper z-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:2181,z-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:2181,z-3.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:2181 --list[2020-04-10 23:58:47,963] WARN Client session timed out, have not heard from server in 10756ms for sessionid 0x0 (org.apache.zookeeper.ClientCnxn)

Beispielausgabe:

[2020-04-10 23:58:58,581] WARN Client session timed out, have not heard from server in 10508ms for sessionid 0x0 (org.apache.zookeeper.ClientCnxn)
[2020-04-10 23:59:08,689] WARN Client session timed out, have not heard from server in 10004ms for sessionid 0x0 (org.apache.zookeeper.ClientCnxn)
Exception in thread "main" kafka.zookeeper.ZooKeeperClientTimeoutException: Timed out waiting for connection while in state: CONNECTING
    at kafka.zookeeper.ZooKeeperClient.$anonfun$waitUntilConnected$3(ZooKeeperClient.scala:259)
    at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
    at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
    at kafka.zookeeper.ZooKeeperClient.waitUntilConnected(ZooKeeperClient.scala:255)
    at kafka.zookeeper.ZooKeeperClient.<init>(ZooKeeperClient.scala:113)
    at kafka.zk.KafkaZkClient$.apply(KafkaZkClient.scala:1858)
    at kafka.admin.TopicCommand$ZookeeperTopicService$.apply(TopicCommand.scala:321)
    at kafka.admin.TopicCommand$.main(TopicCommand.scala:54)
    at kafka.admin.TopicCommand.main(TopicCommand.scala)

Gehe wie folgt vor, um dieses Problem zu beheben:

• Stelle sicher, dass du die richtige Apache ZooKeeper-Zeichenfolge verwendest.
• Stelle sicher, dass die Sicherheitsgruppe für den Amazon MSK-Cluster eingehenden Datenverkehr von der Sicherheitsgruppe des Clients auf den Apache ZooKeeper-Ports zulässt.

Der Broker ist möglicherweise nicht verfügbar

„Topic 'topicName' not present in metadata after 60000 ms. or Connection to node -<node-id> (<broker-host>/<broker-ip>:<port>) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)“

Möglicherweise erhältst du den oben genannten Fehler, wenn eine der folgenden Bedingungen zutrifft:

• Der Produzent oder Verbraucher kann keine Verbindung zum Broker-Host und -Port herstellen.
• Die Broker-Zeichenfolge ist falsch.

Wenn du diesen Fehler erhältst, obwohl die Client- oder Broker-Konnektivität ursprünglich funktioniert hat, ist der Broker möglicherweise nicht verfügbar.

Möglicherweise erhältst du diesen Fehler auch, wenn du die Broker-Zeichenfolge verwendest, um Daten für den Zugriff auf den Cluster von außerhalb der Virtual Private Cloud (VPC) zu erzeugen.

Beispiel für eine Produzent-Broker-Zeichenfolge:

./kafka-console-producer.sh --broker-list b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9092,b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9092 --topic test

Beispielausgabe:

[2020-04-10 23:51:57,668] ERROR Error when sending message to topic test with key: null, value: 1 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
org.apache.kafka.common.errors.TimeoutException: Topic test not present in metadata after 60000 ms.

Beispiel für eine Verbraucher-Broker-Zeichenfolge:

./kafka-console-consumer.sh --bootstrap-server b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9092,b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9092 --topic test

Beispielausgabe:

[2020-04-11 00:03:21,157] WARN [Consumer clientId=consumer-console-consumer-88994-1, groupId=console-consumer-88994] Connection to node -1 (b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com/172.31.6.19:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
[2020-04-11 00:04:36,818] WARN [Consumer clientId=consumer-console-consumer-88994-1, groupId=console-consumer-88994] Connection to node -2 (b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com/172.31.44.252:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
[2020-04-11 00:05:53,228] WARN [Consumer clientId=consumer-console-consumer-88994-1, groupId=console-consumer-88994] Connection to node -1 (b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com/172.31.6.19:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)

Gehe wie folgt vor, um diesen Fehler zu beheben:

• Stelle sicher, dass du die richtige Broker-Zeichenfolge und den richtigen Port verwendest.
• Wenn der Broker nicht verfügbar ist, überprüfe die Amazon CloudWatch-Metrik ActiveControllerCount, um sicherzustellen, dass der Controller während des Zeitraums aktiv war. Wenn der Wert der Metrik nicht 1 ist, ist einer der Broker im Cluster möglicherweise nicht verfügbar.
• Überprüfe die ZooKeeperSessionState-Metrik, um zu bestätigen, dass die Broker kontinuierlich mit den Apache ZooKeeper-Knoten kommunizieren.
• Um zu verstehen, warum der Broker ausgefallen ist, überprüfe die Metrik KafkaDataLogsDiskUsed, um festzustellen, ob dem Broker der Speicherplatz ausgegangen ist. Weitere Informationen findest du unter Amazon MSK-Metriken für die Überwachung von Standard-Brokern mit CloudWatch.
• Prüfe, ob die Netzwerkkonfiguration das Problem verursacht hat. Amazon MSK-Ressourcen werden innerhalb der VPC bereitgestellt. Du musst eine Verbindung zum Amazon MSK-Cluster herstellen oder vom Cluster aus über ein privates Netzwerk in derselben VPC produzieren und verwenden. Weitere Informationen findest du unter Kein Zugriff auf den Cluster innerhalb von AWS: Netzwerkprobleme und Wie stelle ich eine Verbindung zu meinem Amazon MSK-Cluster innerhalb des AWS-Netzwerks, aber außerhalb der Amazon VPC des Clusters her?

Thema ist in den Metadaten nicht enthalten

„org.apache.kafka.common.errors.TimeoutException: Topic test not present in metadata after 60000 ms“

Du erhältst die obige Fehlermeldung, wenn das Thema, in das du schreiben möchtest, in Amazon MSK nicht existiert. Prüfe, ob das Thema im Amazon MSK-Cluster existiert. Stelle sicher, dass du in der Client-Konfiguration die richtige Broker-Zeichenfolge und den richtigen Port verwendet hast. Wenn das Thema nicht existiert, erstelle das Thema entweder in Amazon MSK oder setze auto.create.enable in der Cluster-Konfiguration auf true (wahr). Wenn auto.create.enable auf true gesetzt ist, werden Themen automatisch erstellt.

Möglicherweise erhältst du diesen Fehler auch, wenn das Thema existiert, die Partition jedoch nicht. Zum Beispiel hast du eine einzelne partition[0] und der Produzent versucht, an partition[1] zu senden.

Stelle sicher, dass die Sicherheitsgruppe des Amazon MSK-Clusters eingehenden Datenverkehr von der Sicherheitsgruppe der Client-Anwendung an den entsprechenden Ports zulässt.

Wenn der Fehler plötzlich auftritt, nachdem das System zuvor funktioniert hat, ergreife die folgenden Maßnahmen, um den Status des Amazon MSK-Brokers zu überprüfen:

• Überprüfe die ActiveControllerCount-Metrik. Der Wert muss 1 sein. Wenn die Metrik einen anderen Wert hat, ist einer der Broker im Cluster nicht verfügbar.
• Überprüfe die ZooKeeprSessionState-Metrik, um zu bestätigen, dass die Broker kontinuierlich mit den ZooKeeper-Knoten kommunizieren.
• Überwache die KafkaDataLogsDiskUsed-Metrik, um sicherzustellen, dass dem Broker nicht der Speicherplatz ausgeht.

Stelle sicher, dass du nicht versucht hast, ohne die richtige Konfiguration von außerhalb der VPC auf den Cluster zuzugreifen. Amazon MSK-Ressourcen werden standardmäßig innerhalb der VPC bereitgestellt. Du musst eine Verbindung über ein privates Netzwerk in derselben VPC herstellen.

Wenn du versuchst, von außerhalb der VPC auf den Cluster zuzugreifen, stelle sicher, dass du die erforderlichen Netzwerkkonfigurationen wie AWS Client VPN oder AWS Direct Connect einrichtest.

Falsche Konfiguration des Kafka-Client-Produzenten oder -Verbrauchers

Um die falsche Konfiguration eines Kafka-Client-Produzenten oder -Verbrauchers zu beheben, stelle sicher, dass die Konfiguration der Clients die richtigen Bootstrap-Server enthält. Stelle außerdem sicher, dass die Konfiguration die erforderlichen Sicherheitseinstellungen und die Kompatibilitätsversionen von Kafka-Client und Spring Boot enthält.

Fehler, die spezifisch für die TLS-Client-Authentifizierung sind

Der Bootstrap-Broker ist getrennt

„Bootstrap broker <broker-host>:9094 (id: -<broker-id> rack: null) disconnected“

Möglicherweise erhältst du den oben genannten Fehler, wenn du versuchst, eine Verbindung zu einem Cluster herzustellen, bei dem die SSL/TLS-Client-Authentifizierung aktiviert ist.

Möglicherweise erhältst du diesen Fehler auch, wenn der Produzent oder Verbraucher versucht, über den TLS-Port 9094 eine Verbindung zu einem SSL/TLS-verschlüsselten Cluster herzustellen, und die SSL/TLS-Konfiguration nicht besteht. Um dieses Problem zu beheben, richte die SSL/TLS-Konfiguration ein.

Im folgenden Beispiel tritt ein Fehler auf, wenn der Produzent versucht, eine Verbindung zum Cluster herzustellen:

./kafka-console-producer.sh --broker-list b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094,b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 --topic test[2020-04-10 18:57:58,019] WARN [Producer clientId=console-producer] Bootstrap broker b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -2 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)

Beispielausgabe:

[2020-04-10 18:57:58,342] WARN [Producer clientId=console-producer] Bootstrap broker b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -2 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)
[2020-04-10 18:57:58,666] WARN [Producer clientId=console-producer] Bootstrap broker b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -1 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)

Im folgenden Beispiel tritt ein Fehler auf, wenn der Verbraucher versucht, eine Verbindung zum Cluster herzustellen:

./kafka-console-consumer.sh --bootstrap-server b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094,b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 --topic test[2020-04-10 19:09:03,277] WARN [Consumer clientId=consumer-console-consumer-79102-1, groupId=console-consumer-79102] Bootstrap broker b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -1 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)

Beispielausgabe:

[2020-04-10 19:09:03,596] WARN [Consumer clientId=consumer-console-consumer-79102-1, groupId=console-consumer-79102] Bootstrap broker b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -1 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)
[2020-04-10 19:09:03,918] WARN [Consumer clientId=consumer-console-consumer-79102-1, groupId=console-consumer-79102] Bootstrap broker b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 (id: -2 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)

Wenn die Client-Authentifizierung für den Cluster aktiviert ist, musst du zusätzliche Parameter für die AWS Private Certificate Authority angeben. Weitere Informationen findest du unter Gegenseitige TLS-Client-Authentifizierung für Amazon MSK.

Fehler beim Zugriff auf den Schlüsselspeicher

„ERROR Modification time of key store could not be obtained: <configure-path-to-truststore>“

-oder-

„Failed to load keystore“

Möglicherweise erhältst du die oben genannten Fehler, wenn du den Vertrauensspeicher falsch konfigurierst und die Vertrauensspeicher-Dateien für den Produzenten und den Verbraucher lädst. Gib in der SSL/TLS-Konfiguration den richtigen Pfad für die Vertrauensspeicher-Datei an, um dieses Problem zu beheben.

Beispiel für eine falsche Verbraucher-Broker-Zeichenfolge:

./kafka-console-consumer --bootstrap-server b-2.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094,b-1.encryption.3a3zuy.c7.kafka.us-east-1.amazonaws.com:9094 --topic test --consumer.config /home/ec2-user/ssl.config

Beispielausgabe:

[2020-04-11 10:39:12,194] ERROR Modification time of key store could not be obtained: /home/ec2-ser/certs/kafka.client.truststore.jks (org.apache.kafka.common.security.ssl.SslEngineBuilder)
java.nio.file.NoSuchFileException: /home/ec2-ser/certs/kafka.client.truststore.jks
[2020-04-11 10:39:12,253] ERROR Unknown error when running consumer: (kafka.tools.ConsoleConsumer$)  
Caused by: org.apache.kafka.common.KafkaException: org.apache.kafka.common.KafkaException: org.apache.kafka.common.KafkaException: Failed to load SSL keystore /home/ec2-ser/certs/kafka.client.truststore.jks of type JKS

Dieser Fehler kann auch auftreten, wenn die Vertrauensspeicher- oder Schlüsselspeicherdatei beschädigt ist oder das Passwort für die Vertrauensspeicher-Datei falsch ist.

SSL/TLS-Handshake-Fehler

„Error when sending message to topic test with key: null, value: 0 bytes with error (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback) org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed“

-oder-

„Connection to node -<broker-id> (<broker-hostname>/<broker-hostname>:9094) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)“

Möglicherweise erhältst du einen der oben genannten Fehler, wenn du den Schlüsselspeicher des Produzenten oder Verbrauchers falsch konfiguriert hast und ein Authentifizierungsfehler auftritt. Stelle sicher, dass du den Schlüsselspeicher richtig konfiguriert hast.

Beispiel für eine falsche Broker-Zeichenfolge für den Schlüsselspeicher des Produzenten:

./kafka-console-producer --broker-list b-2.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094,b-1.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094,b-4.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094 --topic example --producer.config/home/ec2-user/ssl.config

Beispielausgabe:

[2020-04-11 11:13:19,286] ERROR [Producer clientId=console-producer] Connection to node -3 (b-4.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com/172.31.6.195:9094) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)

Beispiel für eine falsche Broker-Zeichenfolge für den Schlüsselspeicher des Verbrauchers:

./kafka-console-consumer --bootstrap-server b-2.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094,b-1.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094,b-4.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com:9094 --topic example --consumer.config/home/ec2-user/ssl.config

Beispielausgabe:

[2020-04-11 11:14:46,958] ERROR [Consumer clientId=consumer-1, groupId=console-consumer-46876] Connection to node -1 (b-2.tlscluster.5818ll.c7.kafka.us-east-1.amazonaws.com/172.31.15.140:9094) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2020-04-11 11:14:46,961] ERROR Error processing message, terminating consumer process: (kafka.tools.ConsoleConsumer$)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed

Das Schlüsselspeicher-Passwort ist falsch

 „java.io.IOException: keystore password was incorrect“

Möglicherweise erhältst du den vorherigen Fehler, wenn das Passwort für den Schlüsselspeicher oder Vertrauensspeicher falsch ist.

Um dieses Problem zu beheben, führe den folgenden Befehl aus, um zu überprüfen, ob das Schlüsselspeicher- oder Vertrauensspeicher-Passwort korrekt ist:

keytool -list -keystore kafka.client.keystore.jksEnter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
schema-reg, Jan 15, 2020, PrivateKeyEntry,
Certificate fingerprint (SHA1): 4A:F3:2C:6A:5D:50:87:3A:37:6C:94:5E:05:22:5A:1A:D5:8B:95:ED

Wenn das Passwort für den Schlüsselspeicher oder Vertrauensspeicher falsch ist, wird möglicherweise die folgende Fehlermeldung angezeigt:

„keytool error: java.io.IOException: keystore password was incorrect“

Um die ausführliche Ausgabe des vorherigen Befehls anzuzeigen, füge das Flag -v hinzu:

keytool -list -v -keystore kafka.client.keystore.jks

Du kannst auch die vorherigen Befehle ausführen, um zu überprüfen, ob der Schlüsselspeicher beschädigt ist.

Möglicherweise erhältst du diesen Fehler auch, wenn du den geheimen Schlüssel, der dem Alias zugeordnet ist, in der Produzenten- und Verbraucher-SSL/TLS-Konfiguration falsch konfigurierst. Führe den folgenden Befehl aus, um zu überprüfen, ob dies das Problem ist:

keytool -keypasswd -alias schema-reg -keystore kafka.client.keystore.jks

Wenn das Passwort für das Secret des Alias korrekt ist, wirst du aufgefordert, ein neues Passwort für den geheimen Schlüssel einzugeben:

Enter keystore password:
Enter key password for <schema-reg>
New key password for <schema-reg>:
Re-enter new key password for <schema-reg>:

Andernfalls schlägt der Befehl mit der folgenden Meldung fehl:

„keytool error: java.security.UnrecoverableKeyException: Get Key failed: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.“

Führe den folgenden Befehl aus, um zu überprüfen, ob ein Alias Teil des Schlüsselspeichers ist:

keytool -list -keystore kafka.client.keystore.jks -alias schema-reg

Beispielausgabe:

Enter keystore password:
schema-reg, Jan 15, 2020, PrivateKeyEntry,
Certificate fingerprint (SHA1): 4A:F3:2C:6A:5D:50:87:3A:37:6C:94:5E:05:22:5A:1A:D5:8B:95:ED

Fehler, die spezifisch für die IAM-Client-Authentifizierung sind

Fehlgeschlagene Authentifizierung, Zugriff verweigert

„Connection to node -1 (b-1.testcluster.abc123.c2.kafka.us-east-1.amazonaws.com/10.11.111.123:9098) failed authentication due to: Access denied“

-oder-

„org.apache.kafka.common.errors.SaslAuthenticationException: Access denied“

Du erhältst einen der oben genannten Fehler, wenn Zugriffsrichtlinien, Berechtigungsgrenzen und SCPs Benutzer blockieren, die die erforderliche Autorisierung nicht bestehen.

Stelle mithilfe der IAM-Zugriffskontrolle sicher, dass die IAM-Rolle Cluster-Operationen ausführen kann, um dieses Problem zu beheben.

SaslAuthenticationException

„org.apache.kafka.common.errors.SaslAuthenticationException: Too many connects“

-oder-

„org.apache.kafka.common.errors.SaslAuthenticationException: Internal error“

Du erhältst die oben genannten Fehler, wenn du den Cluster auf dem Brokertyp kafka.t3.small mit IAM-Zugriffskontrolle ausführst und du das Verbindungskontingent überschreitest. Der Instance-Typ kafka.t3.small akzeptiert nur eine TCP-Verbindung pro Broker pro Sekunde. Wenn du das Verbindungskontingent überschreitest, schlägt der Erstellungstest fehl. Weitere Informationen findest du unter So funktioniert Amazon MSK mit IAM.

Gehe wie folgt vor, um diese Probleme zu beheben:

• Aktualisiere in der Amazon MSK Connect-Worker-Konfiguration die Werte für reconnect.backoff.ms und reconnect.backoff.max.ms auf 1000 oder höher.
• Führe ein Upgrade auf einen größeren Broker-Instance-Typ durch, z. B. kafka.m5.large. Weitere Informationen findest du unter Größe des Clusters anpassen: Anzahl der Partitionen pro Standard-Broker.

Fehler, die spezifisch für die SASL/SCRAM-Client-Authentifizierung sind

Der Client-SASL-Mechanismus ist deaktiviert

„Connection to node -1 (b-1-testcluster.abc123.c7.kafka.us-east-1.amazonaws.com/3.11.111.123:9098) failed authentication due to: Client SASL mechanism 'SCRAM-SHA-512' not enabled in the server, enabled mechanisms are [AWS_MSK_IAM]“

-oder-

„Connection to node -1 (b-1-testcluster.abc123.c7.kafka.us-east-1.amazonaws.com/3.11.111.123:9096) failed authentication due to: Client SASL mechanism 'AWS_MSK_IAM' not enabled in the server, enabled mechanisms are [SCRAM-SHA-512]“

Du erhältst die oben genannten Fehler, wenn die Portnummer nicht mit dem Simple Authentication and Security Layer (SASL)-Mechanismus in der Client-Eigenschaftendatei übereinstimmt. Dies ist die Eigenschaftendatei, die du im Befehl zum Ausführen von Cluster-Operationen verwendet hast.

Verwende die folgenden Ports, um mit Brokern in einem Cluster zu kommunizieren, der Simple Authentication und Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) verwendet:

• Port 9096 für den Zugriff innerhalb von AWS
• Port 9196 für öffentlichen Zugriff

Um mit Brokern in einem Cluster zu kommunizieren, der die IAM-Zugriffskontrolle verwendet, verwende die Ports 9098 für den Zugriff innerhalb von AWS und Port 9198 für den öffentlichen Zugriff.

Fehler bei der Authentifizierung der SASL-Anmeldeinformationen

„Connection to node -1 (b-3.testcluster.abc123.c2.kafka.us-east-1.amazonaws.com/10.11.111.123:9096) failed authentication due to: Authentication failed during authentication due to invalid credentials with SASL mechanism SCRAM-SHA-512“

Stelle sicher, dass du die Benutzeranmeldeinformationen in AWS Secrets Manager gespeichert und diese Anmeldeinformationen mit dem Amazon MSK-Cluster verknüpft hast.

Wenn du über Port 9096 auf den Cluster zugreifst, müssen der Benutzer und das Passwort in AWS Secrets Manager mit den Client-Eigenschaften übereinstimmen.

Wenn du den Befehl get-secret-value ausführst, um die Secrets abzurufen, stelle sicher, dass das Passwort in AWS Secrets Manager keine Sonderzeichen enthält.

ClusterAuthorizationException

„org.apache.kafka.common.errors.ClusterAuthorizationException: Request Request(processor=11, connectionId=INTERNAL_IP-INTERNAL_IP-0, session=Session(User:ANONYMOUS,/INTERNAL_IP), listenerName=ListenerName(REPLICATION_SECURE), securityProtocol=SSL, buffer=null) is not authorized“

Du erhältst den vorherigen Fehler, wenn die beiden folgenden Bedingungen zutreffen:

• Die SASL/SCRAM-Authentifizierung ist für den Amazon MSK-Cluster aktiviert.
• In den ACLs für deinen Cluster ist resourceType auf CLUSTER und operation auf CLUSTER_ACTION gesetzt.

Der Amazon MSK-Cluster unterstützt die vorherigen Einstellungen nicht, da die Einstellungen die interne Apache Kafka-Replikation verhindern. Die Identität der Broker wird für die Kommunikation zwischen Brokern als ANONYMOUS (anonym) angezeigt. Wenn der Cluster die ACLs unterstützen und die SASL/SCRAM-Authentifizierung verwenden muss, erlaube dem ANONYMOUS-Benutzer, die Operation ALL (alle) zu verwenden.

Führe den folgenden Befehl aus, um dem ANONYMOUS Benutzer die Operation ALL zu gewähren:

./kafka-acls.sh --authorizer-propertieszookeeper.connect=example-ZookeeperConnectString --add --allow-principal User:ANONYMOUS --operation ALL --cluster

Ähnliche Informationen

Eine Verbindung zu einem von Amazon MSK bereitgestellten Cluster herstellen

Wie behebe ich häufig auftretende Probleme, wenn ich meinen Amazon MSK-Cluster mit SASL/SCRAM-Authentifizierung verwende?