Ubuntu虚拟机执行Confluent CLI启动服务时Connect启动失败

该报错属于confluent local命令的健康检查误判，并非Kafka Connect服务本身启动失败：

• 手动启动Connect后最终日志显示Kafka Connect started，说明服务可正常运行，日志中出现的Jersey接口警告、log4j2配置缺失提示均为非致命问题，不会导致服务崩溃。
• confluent local命令启动服务时默认设置了较短的健康检查超时时间，Connect启动过程中需要扫描插件、加载REST资源，启动耗时超过阈值后，命令就会直接判定启动失败，而后台的Connect进程实际上还在继续启动，最终会正常运行。
• 若你的Connect配置中plugin.path包含大量第三方连接器，插件扫描耗时会进一步拉长，更容易触发超时误判。

• 延长健康检查超时阈值
  打开Confluent安装目录下的etc/confluent/local.properties文件，新增/修改参数：

  confluent.local.start.timeout.ms=180000
  

  将超时时间调整为3分钟，给Connect留出足够的启动时间。
• 减少不必要的启动耗时
  修复log4j2配置缺失的报错，将Connect的日志配置文件路径加入环境变量，编辑当前用户的~/.bashrc文件，新增如下内容（替换为你实际的Confluent安装路径）：

  export KAFKA_LOG4J_OPTS="-Dlog4j.configurationFile=/opt/confluent-7.0.0/etc/kafka/connect-log4j2.properties"
  

  执行source ~/.bashrc生效后可消除日志初始化报错，略微缩短启动耗时。
• 优化插件扫描速度
  打开etc/kafka/connect-distributed.properties文件，调整plugin.path配置，仅保留你需要用到的连接器所在目录，删除无用路径，减少插件扫描的时间消耗。
• 临时验证方案
  若不想修改配置，可在confluent local services start报Connect启动失败后，等待10-30秒再执行confluent local services connect status，通常会显示服务已经处于UP状态，可正常使用。

注：日志中的Jersey空路径注解警告是Confluent 7.0.x版本的已知非致命问题，不影响任何功能使用，无需额外处理。

内容的提问来源于stack exchange，提问作者sharon rogers