Kafka праз проксі: bootstrap працуе, злучэнні з брокерамі не
Тлумачыць, чаму паспяховае bootstrap-злучэнне Kafka не забяспечвае доступ праз проксі да кожнага выяўленага брокера.
Bootstrap-злучэнне можа паспяхова ўстанавіцца, але кліент Kafka ўсё яшчэ не можа адпраўляць або чытаць паведамленні. Bootstrap-серверы дапамагаюць кліенту выявіць кластар; яны не абавязкова з'яўляюцца адзінымі канчатковымі пунктамі, да якіх ён будзе падключацца.
Метаданыя брокера ўтрымліваюць адрасы, якія выкарыстоўваюцца для наступных злучэнняў. Калі гэтыя імёны або парты недаступныя праз меркаваны маршрут проксі, першае паспяховае злучэнне не вырашае рэшту задачы.
Прачытайце аб'яўленыя канчатковыя пункты
Параўнайце bootstrap-адрас з адрасамі брокераў, якія кліент фактычна атрымлівае. Публічны псеўданім bootstrap можа весці да прыватных аб'яўленых імён, а перанакіраванне аднаго лакальнага порта не перапісвае аўтаматычна ўсе адрасы ў метаданых.
Таксама вызначце шлях проксі, які падтрымлівае рэалізацыя кліента. Уласцівасць SOCKS сістэмы Java не гарантуе, што транспарт бібліятэкі на аснове NIO выкарыстоўвае механізм проксі JDK Socket. Правярайце фактычны кліент Kafka і інтэграцыю з сеткай, а не мяркуйце, што кожны сокет Java выконвае адну і тую ж наладу.
Кліенту, які ўлічвае проксі, патрэбны дазволены маршрут да адпаведных канчатковых пунктаў брокера. Арганізацыя на ўзроўні сеткі патрабуе адпаведнай даступнасці і развязання імён. Гэта розныя праекты, і ні адзін з іх не забяспечваецца проста пералікам проксі як bootstrap-сервера.
Трымайце налады пратаколу бяспекі і аўтэнтыфікацыі асобна. Проксі можа ўстанавіць шлях TCP, але ідэнтычнасць TLS, аўтэнтыфікацыя SASL або аўтарызацыя брокера ўсё яшчэ могуць не прайсці.
Для дыягностыкі адзначце, які канчатковы пункт не спрацаваў і ці прыйшоў ён са статычнай канфігурацыі або з вернутых метаданых. Гэта адрозненне звужае праблему значна больш, чым пастаянная змена канчатковага пункта, які ўжо быў даступны.