基于Streaming Analytics Manager的Kafka-Druid数据推送配置异常求助

别急，我之前在Hortonworks沙箱环境里碰到过几乎一模一样的SAM-Kafka集成问题，咱们一步步来定位：

1. 先确认Kafka集群本身的连通性 #

先排除Kafka侧的问题，这是最基础的：

• 登录到SAM所在的节点（或者沙箱主机），先测试端口连通性：
  telnet sandbox-hdf.hortonworks.com 6667
  如果连接失败，大概率是网络问题——要么沙箱的6667端口没开放，要么DNS解析出问题了，试试直接用沙箱的IP替代域名：telnet [沙箱实际IP] 6667
• 再用Kafka自带工具验证生产消费流程：
  先启动生产者发测试消息：
  kafka-console-producer.sh --broker-list sandbox-hdf.hortonworks.com:6667 --topic [你的目标Topic]
  输入几条随便内容的消息，再启动消费者验证：
  kafka-console-consumer.sh --bootstrap-server sandbox-hdf.hortonworks.com:6667 --topic [你的目标Topic] --from-beginning
  如果这一步都收不到消息，那问题和SAM无关，先搞定Kafka本身。

2. 检查SAM Kafka源的细节配置 #

你给出的基础配置看起来没问题，但有几个容易踩的小坑：

• Topic名称必须完全匹配：SAM的Kafka源要指定具体Topic，确认配置的名称和Kafka中存在的Topic大小写、拼写完全一致（Kafka Topic是大小写敏感的！）
• 消费者组ID冲突：如果有其他消费者用了同一个组ID，可能会导致SAM拿不到分区偏移量。可以临时修改SAM源的消费者组ID，或者把偏移量重置到最早位置试试。
• 隐性安全配置排查：虽然你用的是PLAINTEXT，但要确认Kafka的server.properties里没有偷偷开启其他安全配置——比如检查listeners配置是不是只有PLAINTEXT://sandbox-hdf.hortonworks.com:6667，没有额外的SASL或SSL监听。

3. 扒SAM日志找错误线索 #

SAM的日志是定位问题的核心，沙箱环境下日志一般在/var/log/sam/目录：

• 实时查看SAM服务日志：tail -f /var/log/sam/sam-server.log
• 重点搜这些关键词：KafkaSource、connection failed、topic not found、offset error
  比如如果看到TopicAuthorizationException，说明哪怕安全协议是PLAINTEXT，Kafka可能开了ACL，得给SAM的消费者账号授权访问目标Topic。

4. 顺便验证Druid目标端的状态 #

有时候SAM会因为目标端配置错误，悄悄暂停数据拉取，看起来像是没从Kafka拿到数据：

• 确认Druid Overlord服务正常：可以通过Druid控制台（默认端口8888）看Overlord状态，或者用ZK命令检查服务发现路径：zkCli.sh -server [你的ZK地址] ls /druid/discovery，确保能看到overlord的节点。
• 检查SAM里Druid目标的索引任务配置：比如数据格式（JSON/CSV）是否和Kafka里的消息格式匹配，如果格式不兼容，SAM会直接丢弃数据，看起来就像没拉到。

5. 沙箱环境的特殊坑点 #

因为你用的是Hortonworks Sandbox，还有两个容易忽略的问题：

• 端口映射：如果是本地虚拟机跑沙箱，要确认宿主机能访问6667端口；如果SAM部署在沙箱外部，得在虚拟机设置里手动转发6667端口。
• 主机名解析：沙箱重启后，/etc/hosts里的sandbox-hdf.hortonworks.com可能会失效，手动检查下这个域名是否指向沙箱的正确IP。

如果排查完这些还是有问题，把SAM日志里的具体错误信息贴出来，我再帮你分析。

内容的提问来源于stack exchange，提问作者Robert Lepen