我之前维护多节点Kafka集群时也碰到过类似的CC监控卡住的情况，结合你给出的日志和现象，大概率是多节点环境下的配置遗漏或网络/权限问题，给你几个针对性的排查方向：

1. 先确认每个Broker的JMX配置是否正确开启 #

Cruise Control完全依赖JMX来拉取Broker和分区的监控指标，单节点时默认配置可能能工作，但多节点集群必须确保每个Broker都正确配置了JMX：

• 打开每个Broker的server.properties，检查是否添加了正确的JMX参数：

# 开启JMX端口，建议统一设置为相同端口，比如9999
JMX_PORT=9999
# 关键：跨机器部署时不能设为localhost，要绑定到Broker的实际IP或0.0.0.0，否则CC无法远程连接
JMX_HOSTNAME=0.0.0.0

• 验证JMX是否可访问：用jconsole或者jmxterm工具连接每个Broker的JMX端口，看看能不能找到kafka.server相关的MBean（比如kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec），如果连不上，那就是JMX配置的问题。

2. 核对Cruise Control的核心配置 #

打开cruisecontrol.properties，重点检查以下几个配置项：

• Broker列表：确保bootstrap.servers完整包含了3个节点的地址，不能只写一个：

bootstrap.servers=broker1:9092,broker2:9092,broker3:9092

• JMX端口映射：如果你的Broker JMX端口不是默认的9999，一定要指定broker.jmx.port：

broker.jmx.port=9999

• 采样配置：虽然你的问题不是等待时间不够，但可以确认下采样窗口的配置，比如：

sampling.window.ms=30000  # 每个采样窗口30秒
num.valid.windows=1       # 需要1个有效快照就开始分析

3. 检查网络连通性 #

多节点集群最容易踩的坑就是网络不通：

• 从CC所在机器ping每个Broker的IP，确保网络可达；
• 用nc命令测试JMX端口和Kafka端口是否能通：

# 测试JMX端口
nc -zv broker1 9999
# 测试Kafka端口
nc -zv broker1 9092

• 如果集群有防火墙，记得开放这两个端口的入站规则，不然CC连不上Broker的JMX。

4. 验证版本兼容性 #

你用的是Kafka 1.1版本，要确认你部署的Cruise Control版本是否兼容Kafka 1.1。早期的CC版本对旧Kafka版本的支持可能有问题，建议找对应兼容分支的CC版本（比如CC 2.0.x系列，这个版本对Kafka 1.1的支持比较稳定）。

5. 深挖CC日志细节 #

你给出的日志只显示了采集到0个样本，但没说为什么采集不到。可以把CC的日志级别调得更细：

• 打开log4j.properties，把com.linkedin.kafka.cruisecontrol.monitor.sampling.SamplingFetcher的日志级别改成DEBUG：

log4j.logger.com.linkedin.kafka.cruisecontrol.monitor.sampling.SamplingFetcher=DEBUG

• 重启CC后，查看日志里的详细报错，比如是不是JMX连接超时、权限拒绝，或者找不到对应的MBean，这些细节能直接定位问题。

6. 检查集群的认证配置 #

如果你的Kafka集群开启了SASL或SSL认证，CC也需要配置对应的认证参数才能访问Broker：

• 比如SASL PLAIN认证的配置：

security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="cc_user" password="cc_password";

• 如果是SSL，还要配置密钥库、信任库的路径和密码，确保CC能正常连接Kafka集群。

从你的日志来看，最可能的原因是Broker的JMX绑定到了localhost导致CC无法远程访问，或者网络防火墙挡住了JMX端口，建议先从这两个点入手排查。

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