Eine Bootstrap-Verbindung kann gelingen, während der Kafka-Client weiterhin nicht produzieren oder konsumieren kann. Bootstrap-Server helfen dem Client, den Cluster zu entdecken; sie sind nicht unbedingt die einzigen Endpunkte, zu denen er eine Verbindung aufbaut.

Broker-Metadaten enthalten Adressen, die für spätere Verbindungen verwendet werden. Wenn diese Namen oder Ports über die vorgesehene Proxy-Route nicht erreichbar sind, löst die erste erfolgreiche Verbindung den Rest der Aufgabe nicht.

Die angekündigten Endpunkte lesen

Vergleichen Sie die Bootstrap-Adresse mit den Broker-Adressen, die der Client tatsächlich erhält. Ein öffentlicher Bootstrap-Alias kann zu privaten angekündigten Namen führen, und die Weiterleitung eines einzelnen lokalen Ports schreibt nicht automatisch jede Adresse in den Metadaten um.

Ermitteln Sie außerdem den Proxy-Pfad, den die Client-Implementierung unterstützt. Eine Java-System-SOCKS-Eigenschaft ist keine Garantie dafür, dass der NIO-basierte Transport einer Bibliothek den Socket-Proxy-Mechanismus des JDK verwendet. Prüfen Sie den tatsächlichen Kafka-Client und die Netzwerkintegration, statt anzunehmen, dass jeder Java-Socket dieselbe Einstellung beachtet.

Ein proxyfähiger Client benötigt eine erlaubte Route zu den relevanten Broker-Endpunkten. Eine Regelung auf Netzwerkebene benötigt entsprechende Erreichbarkeit und Namensauflösung. Das sind unterschiedliche Entwürfe; keiner davon entsteht allein dadurch, dass ein Proxy als Bootstrap-Server aufgeführt wird.

Halten Sie Sicherheitsprotokoll und Authentifizierungseinstellungen getrennt. Ein Proxy kann einen TCP-Pfad herstellen, während TLS-Identität, SASL-Authentifizierung oder Broker-Autorisierung weiterhin fehlschlagen.

Notieren Sie bei der Diagnose, welcher Endpunkt fehlgeschlagen ist und ob er aus der statischen Konfiguration oder aus zurückgegebenen Metadaten stammt. Diese Unterscheidung grenzt das Problem viel stärker ein als wiederholtes Ändern eines Endpunkts, der bereits erreichbar war.

Ähnliche Artikel