Kafka server.properties核心参数配置原理与故障排查

Kafka server.properties核心参数配置原理与故障排查

发布时间：2026/10/19 9:43:48
Kafka server.properties核心参数配置原理与故障排查 1. 为什么改一个server.properties参数集群就“失联”了我第一次在某跨平台系统里调优Kafka集群时把advertised.listeners配成PLAINTEXT://localhost:9092本地测试跑得飞起——Producer发消息、Consumer收消息日志刷得哗哗响。结果一上测试环境下游服务集体报错Failed to find leader for topic partition。排查两小时最后发现是另一台Broker的broker.id被误设为重复值而listeners和advertised.listeners又没对齐导致ZooKeeper里注册的元数据自相矛盾。Consumer拉取到的leader地址根本连不通。这不是个例。Kafka的server.properties不是“填完就能跑”的配置清单它是一张集群通信契约每个Broker靠它声明“我是谁”“我在哪听”“别人该用什么地址找我”ZooKeeper或KRaft模式下的元数据日志据此构建整个集群的拓扑视图。一旦某个参数偏离真实网络环境整个集群的元数据就变成一张“错误地图”——Producer按图索骥发消息却发到了不存在的IPConsumer查leader位置拿到的是已下线节点的旧地址。更隐蔽的是很多参数存在强耦合关系。比如num.network.threads和num.io.threads的比值直接影响请求排队深度log.retention.hours和log.segment.bytes共同决定磁盘空间的实际占用节奏而group.initial.rebalance.delay.ms这种看似只影响Consumer Group启动的参数实则会拖慢整个集群的元数据同步速度。它们不像Web服务器的port那样改了就生效而是嵌套在Kafka的请求处理流水线、副本同步机制、心跳检测逻辑里。所以这篇不是“参数字典”而是带你拆解这张契约的签署逻辑哪些参数定义Broker的“身份ID”哪些参数划定它的“能力边界”哪些参数暴露它的“服务接口”以及当集群规模从3节点扩到30节点时哪些参数必须重算、哪些必须锁定、哪些看似无关实则牵一发而动全身。你不需要背下所有200参数但必须清楚——改哪一行会触发哪条链路的重新协商。2. 身份锚点broker.id与node.id如何决定集群的“户籍归属”Kafka集群里没有“默认主节点”所有Broker天生平等。但要让它们互相识别、协同工作必须先解决一个最基础的问题每个节点如何证明“我是我”这个身份凭证就是broker.id传统ZooKeeper模式或node.idKRaft模式。它不是IP地址不是主机名而是一个全局唯一的整数标识符。2.1 broker.idZooKeeper时代的“身份证号”在ZooKeeper模式下broker.id是Broker向ZooKeeper注册时的核心Key。ZooKeeper的路径/brokers/ids/{broker.id}下存储着该节点的完整元数据包括它监听的地址、支持的协议、当前状态等。如果两个Broker配置了相同的broker.id会出现什么后启动的Broker会成功注册覆盖前一个节点的元数据前一个节点的心跳超时后ZooKeeper将其标记为“离线”但其正在服务的Partition Leader可能尚未完成迁移Consumer继续向旧Leader发送Fetch请求得到NOT_LEADER_OR_FOLLOWER错误Producer尝试写入时Controller由broker.id最小的在线节点担任无法正确分配分区触发频繁的Leader选举。提示broker.id必须是正整数且不能为0Kafka内部将0保留给特殊用途。生产环境建议从1001开始编号避开小数字可能被脚本误用的风险。2.2 node.idKRaft模式下的“新户籍”KRaftKafka Raft Metadata mode是Kafka 3.3引入的元数据管理新范式它用内置的Raft协议替代ZooKeeper。此时broker.id被弃用取而代之的是node.id。虽然名字变了但本质未变它仍是节点在Raft集群中的唯一ID。关键区别在于node.id必须与process.roles如broker,controller配合使用Controller节点需显式指定controller.quorum.voters列出所有Controller候选节点的node.idhost:portBroker节点启动时会向controller.quorum.voters列表中的节点发起投票请求只有获得多数派同意才能加入集群。这意味着在KRaft模式下node.id不仅标识身份还直接参与集群共识决策。一个配置错误的node.id轻则导致节点无法加入重则破坏Raft多数派使整个集群元数据服务不可用。2.3 实操陷阱ID冲突的三种典型场景场景现象排查方法修复动作Docker容器复用ID多个容器共享同一broker.id1日志中反复出现Duplicate broker registration查看容器启动命令或docker inspect输出的环境变量为每个容器注入唯一ID如-e KAFKA_BROKER_ID$$HOSTNAME$$Ansible批量部署漏改所有节点broker.id均为1ZooKeeper中仅存最后一个注册成功的节点连接ZooKeeper执行ls /brokers/ids检查返回数量是否等于预期节点数修改Ansible模板用inventory_hostname生成递增IDKRaft迁移时ID未重映射从ZK迁移到KRaft沿用旧broker.id作为node.id但Controller Voter列表未更新kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe显示voter状态异常重新生成controller.quorum.voters确保node.id与主机端口严格对应我见过最痛的案例某公司用Terraform创建AWS EC2实例部署Kafkabroker.id硬编码为1。每次扩容新节点旧节点因ID冲突被踢出集群导致所有Topic的ISRIn-Sync Replicas列表瞬间清空Consumer全量rebalance。最终解决方案不是改代码而是把broker.id改为${count.index 1000}让Terraform自动分配。3. 网络契约listeners与advertised.listeners的“双面镜像”如果说broker.id定义了“我是谁”那么listeners和advertised.listeners就定义了“我在哪以及别人该怎么找我”。这是Kafka集群中最易配错、影响最广的一组参数。它们不是简单的“监听地址”和“对外地址”而是一对必须严格对齐的网络契约。3.1 listenersBroker的“耳朵”——它实际监听的端口与协议listeners参数告诉Kafka“请在我这台机器的哪些网络接口、哪些端口上用什么协议接收请求”。格式为协议名称://主机名或IP:端口[,协议名称://...]。常见组合PLAINTEXT://0.0.0.0:9092监听所有网卡的9092端口仅支持明文通信SSL://0.0.0.0:9093监听所有网卡的9093端口要求TLS加密SASL_SSL://0.0.0.0:9094监听所有网卡的9094端口要求SASL认证TLS加密。关键点在于0.0.0.0——它表示绑定到本机所有可用网络接口。但问题来了一台服务器可能有多个网卡eth0内网、eth1公网、docker0容器网桥0.0.0.0会让Kafka同时监听所有接口。如果防火墙未严格限制9092端口可能意外暴露在公网带来安全风险。注意listeners中的主机名/IP仅用于本机绑定不对外公布。它不参与集群元数据注册Consumer和Producer完全不知道这个值。3.2 advertised.listenersBroker的“名片”——它告诉世界“请这样联系我”advertised.listeners才是真正的“对外地址”。当Producer首次连接集群时它会向任意一个Broker发送MetadataRequest获取所有Topic的分区信息。Broker响应中包含每个Partition的Leader地址这个地址完全来自advertised.listeners的配置。例如Broker A配置listenersPLAINTEXT://0.0.0.0:9092 advertised.listenersPLAINTEXT://kafka-broker-a.internal:9092那么Producer收到的Leader地址就是kafka-broker-a.internal:9092。Consumer必须能DNS解析kafka-broker-a.internal且网络可达该地址的9092端口否则连接失败。这就是“双面镜像”的核心逻辑listeners是Broker的物理监听地址Binding Addressadvertised.listeners是Broker的逻辑服务地址Service Address两者协议类型必须一致都用PLAINTEXT或都用SSL端口可以不同如监听9092对外宣称9093但主机名/IP必须保证客户端能解析并连通。3.3 经典故障复现三步走完“集群失联”全过程我们来模拟一个高频踩坑场景——混合云环境部署Step 1错误配置# 所有Broker统一配置错误 listenersPLAINTEXT://0.0.0.0:9092 advertised.listenersPLAINTEXT://localhost:9092Step 2现象发生本地开发机Producer连接localhost:9092能发消息因为连的是自己测试环境的Java应用连接kafka-test.internal:9092Metadata请求成功拿到Leader地址localhost:9092应用尝试连接localhost:9092实际连到自己本机而非目标Broker报错Connection refused。Step 3根因定位用kafka-broker-api-versions.sh工具直连Broker查看其返回的advertised.listeners$ kafka-broker-api-versions.sh --bootstrap-server kafka-test.internal:9092 ... advertised.listeners: PLAINTEXT://localhost:9092 ...确认问题不在网络而在配置本身。修复方案根据环境选择纯内网环境advertised.listenersPLAINTEXT://kafka-broker-a.internal:9092推荐DNS名K8s Service暴露advertised.listenersPLAINTEXT://kafka-headless.default.svc.cluster.local:9092需要兼容内外网启用多个Listener如listenersPLAINTEXT://0.0.0.0:9092,INTERNAL://0.0.0.0:9093再配advertised.listenersPLAINTEXT://kafka-broker-a.public.com:9092,INTERNAL://kafka-broker-a.internal:9093。记住一个铁律advertised.listeners的值必须是Client端网络环境里“能ping通、能telnet通、能DNS解析”的地址。它不是Broker自己的视角而是Client的视角。4. 能力边界的量化线程池、缓冲区与副本同步的参数联动Kafka的高性能建立在精细的资源调度之上。server.properties里大量参数并非孤立存在而是构成一张资源能力矩阵网络线程决定请求接入速度IO线程决定磁盘读写吞吐副本同步参数决定数据一致性强度。改其中一个往往需要联动调整其他参数否则就会出现“木桶效应”。4.1 网络与IO线程请求流水线的“闸门”与“传送带”Kafka请求处理是典型的Reactor模式num.network.threads网络线程池负责接收Socket连接、读取请求头、解析请求体、放入请求队列num.io.threadsIO线程池从队列取出请求执行实际业务逻辑如写入Log、读取Log、处理Offsetqueued.max.requests网络线程与IO线程之间的缓冲队列最大长度。三者关系如下图文字描述[Network Thread] → [Request Queue (maxqueued.max.requests)] → [IO Thread] ↑ ↓ 接收新连接 执行业务逻辑如果num.network.threads过小高并发连接时网络线程忙于accept()来不及读取请求体导致客户端超时如果num.io.threads过小请求队列积压queued.max.requests被填满网络线程拒绝新请求抛出RequestQueueFullException。经验公式适用于中等负载num.network.threads CPU核心数 × 0.5通常2~4num.io.threads CPU核心数 × 2通常8~16queued.max.requestsnum.io.threads× 3保证队列不轻易打满。实测心得某次压测中我们将num.io.threads从8调至16TPS每秒事务数提升37%但CPU使用率从65%飙升至92%。最终平衡点定在12——既释放IO瓶颈又留出CPU余量处理GC和后台任务。4.2 日志段与清理磁盘空间的“潮汐控制”Kafka的Log不是无限追加而是分段Segment管理。log.segment.bytes单段大小和log.retention.*保留策略共同决定磁盘空间的“呼吸节奏”。log.segment.bytes10737418241GB意味着每写满1GB就滚动一个新Segment文件log.retention.hours1687天表示保留最近7天的数据log.cleanup.policydelete过期Segment被删除。但这里有个隐藏陷阱删除不是实时的。Kafka有专门的LogCleaner线程它按固定周期log.cleaner.interval.ms默认15分钟扫描所有Log找出可删除的Segment。如果log.segment.bytes设得太小如10MB会导致Segment文件数量爆炸1TB数据产生10万小文件LogCleaner扫描耗时剧增磁盘空间迟迟得不到释放。反模式案例某金融客户将log.segment.bytes设为10MB期望“更快清理”。结果集群运行一周后ls -l /kafka-logs/topic-1/ | wc -l显示超20万个文件df -h显示磁盘98%满但kafka-log-dirs.sh报告“无过期数据”。根源就是小Segment导致清理效率归零。合理配置建议场景log.segment.byteslog.retention.ms说明高吞吐日志流10MB/s2GB17280000048h大Segment减少文件数48h满足合规要求低频事件溯源1KB/s100MB259200000030d小Segment便于快速定位长保留满足审计混合型业务512MB根据SLA动态设置配合log.roll.jitter.ms增加随机性避免所有Broker同时滚动Segment4.3 副本同步ISR收缩与Leader选举的“心跳节拍器”replica.fetch.wait.max.ms和replica.fetch.min.bytes这对参数控制Follower从Leader拉取数据的“耐心程度”直接影响ISRIn-Sync Replicas列表的稳定性。replica.fetch.wait.max.ms500Follower最多等待500ms看Leader是否有新数据replica.fetch.min.bytes1只要Leader有1字节数据就立即返回。表面看很激进但问题在于网络抖动时Leader可能因GC暂停100msFollower在500ms内没等到数据就认为Leader“失联”触发ISR收缩。频繁收缩会导致Producer写入时因acksall要求ISR2而失败Controller频繁发起Leader选举增加元数据压力。优化实践将replica.fetch.wait.max.ms提高到1000msreplica.fetch.min.bytes提高到10241KB并配合replica.lag.time.max.ms3000030秒。这样Follower会耐心等待1秒只要Leader在30秒内恢复就不会被踢出ISR。实测在AWS跨可用区部署中ISR波动频率下降82%。5. 安全与治理SASL、ACL与动态配置的落地约束当Kafka从“玩具集群”走向生产环境server.properties就不再只是性能调优的战场更是安全治理的前线。SASL认证、ACL权限控制、动态配置更新——这些能力都依赖特定参数的精确配置且存在严格的启用顺序和依赖关系。5.1 SASL认证从“开关”到“密钥环”的完整链条启用SASL不是简单加几行配置而是一条完整的信任链协议开关listenersSASL_PLAINTEXT://0.0.0.0:9092或SASL_SSL机制指定sasl.mechanism.inter.broker.protocolPLAINBroker间通信机制JAAS配置sasl.jaas.config指向JAAS文件路径或通过JVM参数-Djava.security.auth.login.config/path/kafka_server_jaas.conf注入JAAS文件内容定义LoginModule、用户名、密码、回调处理器。其中最容易忽略的是第2步sasl.mechanism.inter.broker.protocol。如果Broker间通信机制与listeners协议不匹配集群根本无法形成。例如# 错误配置listeners用SASL_PLAINTEXT但Broker间用PLAIN非SASL listenersSASL_PLAINTEXT://0.0.0.0:9092 sasl.mechanism.inter.broker.protocolPLAIN # ❌ 应为SASL_PLAINTEXT结果Broker启动后日志疯狂打印Failed to send request to node XZooKeeper中Broker ID反复注册又消失。提示Kafka 3.0支持listener.name.listener_name.sasl.jaas.config允许为不同Listener配置独立JAAS实现“内网PLAINTEXT外网SASL_SSL”的混合访问。5.2 ACL权限从“白名单”到“最小权限”的演进authorizer.class.namekafka.security.authorizer.AclAuthorizer开启ACL后allow.everyone.if.no.acl.foundfalse是安全基线。但真正落地时必须理解ACL的“四元组”模型Principal用户身份如User:aliceHost客户端IP支持*通配Operation操作类型如Read、Write、DescribeResource资源类型名称如Topic:test-topic。常见误区是过度授权# 危险给所有用户所有Topic的全部权限 kafka-acls.sh --add --allow-principal User:* --operation All --topic * --authorizer-properties zookeeper.connectlocalhost:2181这相当于给数据库开GRANT ALL ON *.* TO root%。正确做法是遵循“最小权限原则”# 仅授权Producer应用写入特定Topic kafka-acls.sh --add --allow-principal User:service-producer \ --operation Write --operation Describe --topic order-events \ --authorizer-properties zookeeper.connectlocalhost:2181 # 仅授权Consumer应用读取 kafka-acls.sh --add --allow-principal User:service-consumer \ --operation Read --operation Describe --topic order-events \ --authorizer-properties zookeeper.connectlocalhost:21815.3 动态配置哪些参数真能“热更新”哪些必须重启Kafka 2.0支持kafka-configs.sh动态修改部分参数但绝非所有参数都支持。必须区分三类类别特点示例参数是否支持动态更新Runtime-Only只影响当前运行时行为无需持久化log.retention.hours,num.replica.fetchers✅ 是Dynamic-Cluster修改后广播到所有Broker需Controller协调default.replication.factor,min.insync.replicas✅ 是需--entity-type brokersStatic-Required涉及网络绑定、安全上下文等底层设施listeners,advertised.listeners,sasl.jaas.config❌ 否必须重启血泪教训某次紧急修复中运维同学执行kafka-configs.sh --alter --entity-type brokers --entity-name 1 \ --add-config advertised.listenersSASL_PLAINTEXT://kafka-01.prod:9092 \ --bootstrap-server localhost:9092命令执行成功但Broker日志报错Advertised listeners cannot be changed dynamically。原因advertised.listeners属于Static-Required类别动态API只是静默忽略实际配置未生效。最终只能滚动重启。验证动态配置是否生效的可靠方法不用信kafka-configs.sh --describe的输出直接用kafka-broker-api-versions.sh查询Broker实际返回的元数据kafka-broker-api-versions.sh --bootstrap-server kafka-01.prod:9092 | grep advertised只有这里显示的值才是Client真正看到的地址。6. 生产环境黄金配置模板从3节点到30节点的平滑演进参数配置没有“银弹”只有“适配”。下面给出一套经过某大型电商系统峰值QPS 200万验证的分阶段配置模板覆盖小规模验证、中等规模生产、大规模高可用三个阶段。所有参数均标注修改依据和影响范围拒绝“拿来主义”。6.1 阶段一3节点验证集群Dev/Test适用场景功能验证、CI/CD流水线、开发联调核心诉求快速启动、易于调试、资源占用低# 身份与网络 broker.id1 listenersPLAINTEXT://0.0.0.0:9092 advertised.listenersPLAINTEXT://kafka-01.test:9092 # 注使用DNS名而非IP避免硬编码所有节点advertised.listeners域名需提前配置好 # 性能与资源 num.network.threads3 num.io.threads8 queued.max.requests500 # 注小线程数降低CPU占用适合笔记本或虚拟机 # 日志管理 log.dirs/tmp/kafka-logs log.segment.bytes1073741824 # 1GB log.retention.hours168 # 7天 log.cleanup.policydelete # 副本与可靠性 default.replication.factor2 min.insync.replicas1 # 注测试环境不追求高可用min.insync.replicas1允许单节点写入6.2 阶段二12节点中等生产集群Online Service适用场景核心业务线、日均消息量10TB核心诉求稳定低延迟、可控磁盘增长、基础安全# 身份与网络 broker.id1001 listenersPLAINTEXT://0.0.0.0:9092,SSL://0.0.0.0:9093 advertised.listenersPLAINTEXT://kafka-01.internal:9092,SSL://kafka-01.internal:9093 listener.security.protocol.mapPLAINTEXT:PLAINTEXT,SSL:SSL # 注双协议支持内网服务走PLAINTEXT管理工具走SSL # 性能与资源 num.network.threads4 num.io.threads16 queued.max.requests1000 # 注IO线程提升至16匹配SSD磁盘IOPS # 日志管理 log.dirs/data/kafka-logs log.segment.bytes2147483648 # 2GB减少Segment碎片 log.retention.ms604800000 # 7天毫秒级精确控制 log.roll.jitter.ms300000 # 5分钟抖动避免集中滚动 log.cleanup.policycompact,delete # 同时支持Compact和Delete # 副本与可靠性 default.replication.factor3 min.insync.replicas2 unclean.leader.election.enablefalse # 注强制ISR2才允许写入杜绝数据丢失禁用非ISR Leader选举6.3 阶段三30节点大规模集群Global Platform适用场景多区域数据湖、实时风控、全站消息总线核心诉求跨AZ容灾、流量隔离、细粒度治理# 身份与网络KRaft模式 node.id1001 process.rolesbroker,controller controller.quorum.voters1001kafka-ctrl-01:9093,1002kafka-ctrl-02:9093,1003kafka-ctrl-03:9093 listenersPLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 advertised.listenersPLAINTEXT://kafka-01.region-a:9092,CONTROLLER://kafka-ctrl-01.region-a:9093 # 注Controller与Broker分离部署Controller专用节点保障元数据稳定 # 性能与资源 num.network.threads6 num.io.threads24 queued.max.requests2000 # 注更高线程数应对跨Region网络延迟 # 日志管理 log.dirs/data1/kafka-logs,/data2/kafka-logs log.segment.bytes4294967296 # 4GB极致减少文件数 log.retention.ms2592000000 # 30天满足GDPR留存要求 log.roll.jitter.ms600000 # 10分钟抖动 # 安全与治理 authorizer.class.namekafka.security.authorizer.AclAuthorizer allow.everyone.if.no.acl.foundfalse super.usersUser:admin;User:monitor # 注明确super users避免权限失控 # 动态配置基线 # 所有可动态参数均设为合理默认值后续通过kafka-configs.sh精细化调整 auto.create.topics.enablefalse default.replication.factor3 min.insync.replicas2这套模板的价值不在于参数本身而在于它背后的演进逻辑从验证阶段的“够用就好”到生产阶段的“稳字当头”再到大规模阶段的“架构驱动”。每一次扩容都不是简单复制配置而是对listeners拓扑、replication.factor冗余度、log.segment.bytes与磁盘IO的重新计算。参数配置本质上是对业务SLA、基础设施能力和运维成熟度的三方对齐。7. 故障诊断沙盒用5个命令定位90%的server.properties问题再完美的配置也逃不过线上环境的千奇百怪。与其在日志里大海捞针不如建立一套标准化的诊断流程。以下5个命令覆盖了server.properties相关问题的90%场景每个命令都附带“预期输出”和“异常信号”让你3分钟内定位根因。7.1 命令一kafka-broker-api-versions.sh—— 验证“Broker到底说了什么”作用直连Broker获取其真实暴露的API版本和advertised.listeners绕过ZooKeeper缓存。执行kafka-broker-api-versions.sh --bootstrap-server kafka-01.prod:9092正常输出片段... advertised.listeners: PLAINTEXT://kafka-01.prod:9092,SSL://kafka-01.prod:9093 ...异常信号输出中advertised.listeners为空或为localhost→ 配置未生效或Broker未加载新配置返回Connection refused但telnet kafka-01.prod 9092通 →listeners绑定地址错误如绑定了127.0.0.1advertised.listeners中的域名无法被Client DNS解析 → Client端网络配置问题。7.2 命令二kafka-metadata-shell.sh—— 检查“ZooKeeper/KRaft里存了什么”作用查看ZooKeeper或KRaft中存储的Broker元数据确认配置是否被正确注册。执行ZooKeeper模式echo ls /brokers/ids | /opt/zookeeper/bin/zkCli.sh -server zk-01:2181 # 或直接查看具体Broker echo get /brokers/ids/1001 | /opt/zookeeper/bin/zkCli.sh -server zk-01:2181正常输出{listener_security_protocol_map:{PLAINTEXT:PLAINTEXT,SSL:SSL},endpoints:[PLAINTEXT://kafka-01.prod:9092,SSL://kafka-01.prod:9093],jmx_port:-1,host:kafka-01.prod,timestamp:1712345678901,port:9092,version:4}异常信号/brokers/ids下节点数少于预期 → Broker未成功注册检查broker.id冲突或ZK连接失败endpoints字段与advertised.listeners不一致 → 配置未生效或Broker版本不兼容version为3旧格式但Broker是3.0 → 需升级ZooKeeper schema。7.3 命令三kafka-topics.sh --describe—— 观察“数据平面是否健康”作用查看Topic的分区分布、Leader位置、ISR列表暴露副本同步问题。执行kafka-topics.sh --bootstrap-server kafka-01.prod:9092 --describe --topic test-topic正常输出Topic: test-topic PartitionCount: 12 ReplicationFactor: 3 Configs: Topic: test-topic Partition: 0 Leader: 1001 Replicas: 1001,1002,1003 Isr: 1001,1002,1003异常信号Isr列表短于Replicas如Isr: 1001,1002但Replicas: 1001,1002,1003→ Follower同步延迟检查replica.fetch.*参数或网络延迟Leader为-1→ 该分区无Leader可能是Controller故障或min.insync.replicas过高Replicas中出现不存在的broker.id→ Topic创建时指定了错误的replica assignment。7.4 命令四kafka-configs.sh --describe—— 核对“动态配置是否落地”作用检查Broker当前生效的配置值特别是那些支持动态更新的参数。执行kafka-configs.sh --bootstrap-server kafka-01.prod:9092 \ --entity-type brokers --entity-name 1001 \ --describe关键检查项log.retention.ms确认是否为预期值如2592000000min.insync.replicas确认是否为2而非默认1unclean.leader.election.enable确认是否为false。异常信号输出中找不到目标参数 → 该参数不支持动态更新必须重启参数值与server.properties中配置不一致 → 配置未加载检查Broker启动日志是否有WARN提示。7.5 命令五kafka-log-dirs.sh—— 监控“磁盘空间的实时脉搏”作用查看各Broker上每个Log目录的磁盘使用率、Segment分布、清理进度。执行kafka-log-dirs.sh --bootstrap-server kafka-01.prod:9092 \ --describe --topic-list test-topic正常输出关键字段size: 1234567890, logDirs: [{logDir:/data/kafka-logs,size:1234567890,error