Не удается запустить Kafka connect для поиска Elasti c в распределенном режиме - PullRequest
Новая
       64

Не удается запустить Kafka connect для поиска Elasti c в распределенном режиме

0 голосов
/ 30 января 2020

Я пытаюсь запустить Kafka Connect в распределенном режиме, даже в автономном режиме, и я не могу продолжить

Это мои elasti c свойства приемника поиска 

name=elasticsearch-sink
connector.class=io.confluent.connect.elasticsearch.ElasticsearchSinkConnector
tasks.max=5
topics=fsp-audit
key.ignore=true
connection.url=https://****.amazonaws.com
type.name=kafka-connect
errors.tolerance = all
errors.deadletterqueue.topic.name = fsp-dlq-audit-event

это мои connect-distributed.properties 

bootstrap.servers=***:9092,***:9092,***:9092
group.id=connect-cluster
key.converter=org.apache.kafka.connect.json.JsonConverter
value.converter=org.apache.kafka.connect.json.JsonConverter
key.converter.schemas.enable=false
value.converter.schemas.enable=false
offset.storage.topic=connect-offsets
offset.storage.replication.factor=1
schema.enabled=false
config.storage.topic=connect-configs
config.storage.replication.factor=1
status.storage.topic=connect-status
status.storage.replication.factor=1
offset.flush.interval.ms=10000
plugin.path=/usr/local/confluent/share/java

Я также создал три топи заранее 

connect-offsets
connect-configs
connect-status

Я запускаю это на EC2 и использую MSK в качестве Кафки. Я проверил подключение от моего EC2 к MSK, и я могу telent

Ошибка, я получаю это 

[2020-01-30 08:53:12,126] INFO [AdminClient clientId=adminclient-1] Metadata update failed (org.apache.kafka.clients.admin.internals.AdminMetadataManager:237)
org.apache.kafka.common.errors.TimeoutException: Timed out waiting to send the call.
[2020-01-30 08:53:12,145] INFO [AdminClient clientId=adminclient-1] Metadata update failed (org.apache.kafka.clients.admin.internals.AdminMetadataManager:237)
org.apache.kafka.common.errors.TimeoutException: Timed out waiting to send the call.
[2020-01-30 08:53:12,149] ERROR Stopping due to error (org.apache.kafka.connect.cli.ConnectDistributed:83)
org.apache.kafka.connect.errors.ConnectException: Failed to connect to and describe Kafka cluster. Check worker's broker connection and security properties.
        at org.apache.kafka.connect.util.ConnectUtils.lookupKafkaClusterId(ConnectUtils.java:64)
        at org.apache.kafka.connect.util.ConnectUtils.lookupKafkaClusterId(ConnectUtils.java:45)
        at org.apache.kafka.connect.cli.ConnectDistributed.startConnect(ConnectDistributed.java:94)
        at org.apache.kafka.connect.cli.ConnectDistributed.main(ConnectDistributed.java:77)
Caused by: java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Timed out waiting for a node assignment.
        at org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
        at org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
        at org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
        at org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
        at org.apache.kafka.connect.util.ConnectUtils.lookupKafkaClusterId(ConnectUtils.java:58)

Вопрос : Если я должен запустить Kafka, подключитесь в распределенный режим, мне нужно использовать более одного EC2 / VM?

Ответы [ 2 ]

1 голос
/ 31 января 2020

Хорошо, изучив более подробную информацию, я обнаружил, что проблема заключалась в NACL, который блокировал несколько IP-адресов подсетей.

Итак, я проверил таблицу группы безопасности / ACL / маршрутной сети на стороне MSK и нашел их будь умницей. Это означает, что проблема может быть связана с экземпляром EC2, поэтому я проверил группу безопасности / таблицу маршрутов экземпляра и обнаружил, что они правильно настроены.

Однако при проверке ACL (acl-***) сети, подключенного к Экземпляр EC2, я видел, что есть правило Inbound, разрешающее 0.0.0.0/0 для эфемерных портов, которое должно позволять посредникам общаться с экземпляром EC2. Однако, глядя на исходящие правила, я увидел, что он разрешает только диапазон su bnet, в котором присутствует b-2, но у него не было явного правила исходящих событий, разрешающего либо b-3 (10.**.**.0/24), либо b-4 * 1007. * su bnet range.
Когда я добавил новое правило, я смог полностью пропинговать и успешно подключаться

0 голосов
/ 31 января 2020

Если мне нужно запустить Kafka connect в распределенном режиме, нужно ли мне использовать более одного EC2 / vm?

Нет, вы можете запустить один экземпляр с псевдо-распределением , Основное различие между автономным и распределенным состоит в том, как он обрабатывает хранение смещений и конфигураций.

...