1. 调优从哪下手：先把Kafka的IO链路摸清楚
做Kafka调优这两年，我最大的感受是：别急着抄参数。网上随便一搜就是几百篇“压测调优指南”，照着把linger.ms调到10、把batch.size调到64KB、把线程数翻倍，结果吞吐没涨多少，反而延迟飚了、分区副本频繁失步。原因很简单——每个集群的流量模型、副本数量、磁盘类型、消费逻辑都不一样，盲目套参数等于给不同体质的病人开同一副药。
先讲一个我经历过的真实场景。某业务方的数据管道每天要处理十亿级消息，高峰期单Topic的写入速度接近5万条/秒。当时集群3个节点，IOUtil经常打满100%，延迟从几十毫秒飙到几秒，消费者侧堆积越来越严重。我们一开始加了2台节点，发现只是把问题从A节点挪到B节点，瓶颈依旧。后来从头到尾做了一轮链路拆解，才发现问题出现在好几个层级叠加：Broker的副本拉取线程只有默认的1个、生产者linger.ms=0导致小请求灌满网络、消费者max.poll.records只设了500但单条消息体很大。把这几层各调了调，同样的业务量，吞吐从峰值3.5万条/秒干到12万条/秒，端到端P99延迟从900ms降到200ms以内。
所以我把调优思路总结成一句话：先把Kafka的完整IO链路画出来，找到真正的瓶颈层，再对症下药。全链路优化的意义就在于此——你只调生产者，Broker扛不住也没用；你只调Broker，消费者处理不过来照样堆积。
1.1 一条消息从生产到消费，瓶颈到底卡在哪
一条消息从业务代码发出，到最终被下游消费，中间要经过这几道关口：
- 生产者应用：序列化、分区选择、消息聚合批次、发送
- 网络传输：客户端到Broker的TCP连接、Broker接收请求
- Broker端网络接收：网络线程（Poller）读请求
- Broker端IO处理：IO线程处理请求、写入PageCache
- 副本同步：Leader副本写入，Follower副本拉取并确认
- 刷盘：PageCache中的数据由操作系统异步刷入磁盘
- 消费者拉取：从Leader或Follower读数据，经过Socket发送给消费者
每个环节都可能成为瓶颈。IO线程不够，请求在Broker排队；PageCache命中率低，每次写入都进磁盘随机IO；副本拉取线程少，ISR缩容频繁；消费者拉取参数不合理，明明能一次拉1MB数据偏要分20次拉。调优的关键是先定位瓶颈在哪个环节，而不是把所有参数都调一遍。
我每次接手一个Kafka集群，都会先看一眼四个维度的指标：CPU使用率及平均空闲率、磁盘IO的await与util、网络带宽占用、PageCache缺页情况。哪里先被打满，哪里就是当前的主要瓶颈。
1.2 调优前必须收集的五组指标
调优一定要指标先行，否则全凭感觉。以下五组指标是我每次都会先收集的，建议你也做成固定动作：
- Broker JVM指标：堆内存使用率、GC频率与耗时、线程状态。Kafka的堆内存使用相对克制，但频繁Full GC时会直接导致请求卡顿。
- 网络与IO线程空闲率：
RequestHandlerAvgIdlePercent和NetworkProcessorAvgIdlePercent，正常情况下应接近1.0，如果长期低于0.3，说明IO线程或网络线程已经是瓶颈。 - 磁盘性能：通过
iostat看await和util。util接近100%说明磁盘饱和，await持续偏高说明磁盘响应差，需要关注刷盘策略或换更快的盘。 - Kafka关键指标：
UnderReplicatedPartitions（分区副本数不足）、ActiveControllerCount、BytesInPerSec与BytesOutPerSec、RequestQueueSize。特别关注ISR缩小的次数。 - 消费侧指标：消费者Lag、拉取请求的平均等待时间、
records-lag-max最大值。Lag持续上涨，要么是生产快消费慢，要么是分配不均。
这些指标不需要一次全看，但至少要建立一条基线，知道当前集群“哪里最接近极限”。拿到基线之后再动参数，每次只动一个维度，压测对比，才能知道哪一刀下对了。
2. Broker端参数：先把服务端的地基打牢
很多新手调Kafka，一上来就调生产者的linger.ms和生产参数，却忽略了Broker端本身才是承接所有流量的大坝。你下游再能造，大坝放水慢，一样会漫堤。Broker端的参数调整，优先级应该排在所有调优动作的最前面。
2.1 网络线程与IO线程：别让Kafka捧着金碗讨饭
Kafka的请求处理模型是典型的多阶段：网络线程（num.network.threads）负责从Socket读取请求和回写响应，IO线程（num.io.threads）负责真正的处理逻辑（写PageCache、读磁盘、副本拉取等）。默认情况下，网络线程是3个，IO线程是8个。
先说IO线程。如果你处理的是高吞吐写入场景，8个线程往往不够。我在一台32核的机器上做过对照压测：写入压力相同，IO线程从8调到16，吞吐提升了约40%。原因并不复杂，Kafka处理生产请求时，即使只是写PageCache，也需要做序列化、解析、分区追加等CPU密集操作，线程太少就会出现排队。这类开销在RequestHandlerAvgIdlePercent上反映得很直接——这个值长期低于0.3，IO线程就是瓶颈，放心调大。
网络线程也一样，可以通过NetworkProcessorAvgIdlePercent观察。如果这个值很低，日志里还会看到Unable to read more data from socket之类的报错，通常意味着网络线程处理能力不足。建议先按CPU核数分一半给网络线程，比如32核机器可以设num.network.threads=8，再观察空闲率。调完之后记得重启Broker，这个参数是静态配置，不能动态生效。
不过要注意：线程不是越多越好。线程多了会带来上下文切换开销，反而让吞吐下降。我的经验取值范围是——网络线程在CPU核数的0.5到1倍之间，IO线程在CPU核数的1到2倍之间，具体靠压测决定。
2.2 副本同步与磁盘刷盘：被很多人忽略的隐性瓶颈
副本同步是Kafka高可用设计的核心，但也是很容易被忽略的性能瓶颈。默认的num.replica.fetchers=1，也就是说每个Broker上只有一个线程从Leader拉取其他副本的数据。当Topic的分区数量多、消息体大时，单线程拉取很容易拉胯。ISR频繁收缩、副本不同步，往往就是这个线程拖了后腿。
把num.replica.fetchers从1调到3或者4，是我在多个集群上百试百灵的优化手段。尤其是在跨机架或跨可用区部署时，副本拉取要走网络，单线程的带宽利用率和延时都吃亏。多线程拉取能并行处理不同分区的数据，显著缩短Follower追上Leader的时间。注意这个参数调大后，网络带宽占用会明显上升，压测时要盯紧网卡流量，别把带宽打爆。
再谈刷盘。Kafka高性能的基石之一是PageCache——消息先写进操作系统的页缓存，由操作系统决定何时真正刷到磁盘。所以并在绝大多数场景下，你不应该把log.flush.interval.messages和log.flush.interval.ms调得太激进。有些人误以为刷盘越频繁越可靠，把刷盘间隔调到1秒甚至更短，结果每个Broker都在高频刷盘，磁盘IO直接被打成瓶颈。有人说过一句话很精辟：Kafka把刷盘交给操作系统，不是因为懒，是因为操作系统的IO调度比绝大多数应用层实现更聪明。
实际上，如果业务允许，保持默认的“不主动刷盘”（由OS自动管理刷盘）反而是最优解。如果你对可靠性有更高要求，优先考虑以副本数保证数据不丢，而不是牺牲性能去高频刷盘。另一个值得关注的参数是log.segment.bytes，默认1GB。Segment文件越大，单个文件承载的数据越多，但日志清理和索引重建的代价也更大；Segment太小则会产生大量文件碎片。一般不建议调小，除非你有特殊的冷热分离需求。
2.3 其他值得调整的Broker参数
有几个参数表面上不起眼，实战中却能救命。
socket.send.buffer.bytes和socket.receive.buffer.bytes：控制Broker与客户端之间的Socket收发缓冲区。大消息体场景建议调到1MB（默认100KB左右），能减少TCP分片带来的网络开销。socket.request.max.bytes：单次请求最大字节数，默认100MB。如果单条消息特别大（比如几十MB），这个值必须同步调大，否则直接拒绝请求。min.insync.replicas：生产端acks=all时，至少要确认写入成功的副本数。建议配合acks=all一起使用，设成2（副本数为3时），既能保证多数派确认，又能容忍单副本故障。unclean.leader.election.enable：控制副本落后太多时是否允许非ISR副本竞选Leader。这个参数默认false，建议保持false。宁可短暂不可用，也不要丢数据。
这组参数通常不需要频繁改动，但在一开始规划集群时就应该设定好，别等出了事故再改。
3. 生产者端调优：吞吐量的主战场
生产者是消息进入Kafka的入口，也是吞吐量提升收益最明显的地方。绝大多数“生产慢”的问题，根源都在生产者客户端参数没调好。这一节我会把几个决定性参数挨个讲透，并给出一份压测验证过的参考配置。
3.1 五个参数决定生产吞吐天花板
先说结论：决定生产者吞吐的核心参数是linger.ms、batch.size、compression.type、buffer.memory和max.in.flight.requests.per.connection。每个都值得单独讲一下。
linger.ms是很多人的第一把斧头，默认值是0，意味着消息一到就立刻发出。看似延迟最低，实则在高吞吐场景下是个灾难——每条消息都单独成请求，网络往返和Broker请求处理的次数暴增，吞吐直线下降。把linger.ms调大到5~20ms，生产者会在这个时间段里等待积累更多消息，一次性批量发出。这里有一个关键认知：调大linger.ms不是单纯牺牲延迟换吞吐，而是减少请求往返次数，平摊网络和请求处理的固定开销。就像一个快递员，与其件到了就送，不如攒一车一起送，总时间反而更短。
batch.size决定单个批次的最大字节数，默认16KB。消息密集且单条体积在1KB以上时，16KB意味着一个批次最多装16条左右，略微浪费。我一般会把它调到32KB或64KB，配合linger.ms使用。这里有个坑：很多人以为batch.size越大越好，其实不是。批次太大，内存占用和GC压力会上升，并且如果消息没那么密集，批次装不满，反而不如小批次有效。它应该和你的消息流量匹配，而不是拍脑袋设个256KB。
compression.type是性价比最高的参数，没有之一。生产端开启压缩，网络传输和磁盘存储的体积都大幅下降，CPU开销却能换来好几十倍的收益。我实测过：不压缩时单条1KB的消息，每秒钟5万条大概要吃掉350Mbps的带宽；开了lz4压缩后，带宽降到80Mbps左右，Broker的磁盘IO也下降了近70%。格式上我的建议是：CPU充足选zstd（压缩率最高），CPU资源紧张选lz4（压缩和解压速度更快）。snappy是曾经的默认选择，但现在无论压缩率还是速度都比较中庸，新项目不建议优先用。
buffer.memory是生产者内存池的总大小，默认32MB。如果消息峰值流量很大，这个值不够时生产者会直接阻塞，发送线程全部卡在“等待可用内存”。出现过RecordTooLargeException或者buffer.memory触顶的，建议直接提高到64~128MB。要注意这是JVM堆外内存，不是堆内存，不用过于担心GC影响。
max.in.flight.requests.per.connection允许生产者在一个连接上发送但还未确认的请求数，默认5。值越大，吞吐越高，但在启用重试时，多个请求交错可能引起消息乱序。如果你要求绝对的顺序性，把这个值设为1，但要接受吞吐下降的现实。如果只是单分区顺序要求，并且重试次数少、消息量可控，保持默认值通常是可以接受的。
3.2 acks到底怎么选：可靠性、吞吐和延迟的三方博弈
acks参数描述了生产者要求Broker在什么条件下确认写入成功，有三个可选值：0、1和all。
选择acks=0，生产者只管发，不关心Broker是否收到。这种模式下吞吐最高，但消息丢了也不会知道，只适合可以接受丢数据的场景（比如统计类日志抽样）。
选择acks=1，只要Leader副本写入成功就返回确认。这是性能与可靠性的默认平衡点。但Leader如果刚确认完就宕机，这条消息可能还没同步到Follower，重启后消息就没了。
选择acks=all，需要所有ISR副本都写入成功才确认。数据安全性最高，但因为要多等副本确认，延迟会受到副本数量和网络距离的直接影响。
实际业务中，我建议可靠消息通道一律使用acks=all，同时保证min.insync.replicas的值大于等于2。说实话，现实中很多人觉得多副本确认太慢，宁可选1降低延迟，但一旦遇到Leader切换丢数据的情况，业务方都是直接拉响故障，比那几十毫秒的延迟严重得多。延迟可以用其他手段优化，数据却是丢了就没了。
3.3 一个生产环境的压测配置参考
下面这份配置来自我之前压测的一个模拟项目X，场景是每天处理亿级消息的数据管道，消息体平均1.2KB，峰值写入6万条/秒，对顺序性没有强要求，但要求不丢数据。经过多轮压测，最终稳定使用的参数如下：
bootstrap.servers=broker1:9092,broker2:9092,broker3:9092 acks=all linger.ms=10 batch.size=65536 compression.type=lz4 buffer.memory=134217728 max.in.flight.requests.per.connection=5 retries=3 retry.backoff.ms=500 delivery.timeout.ms=120000 max.request.size=1048576这些参数的搭配逻辑是：acks=all保证数据安全，linger.ms=10给了批次积累时间，batch.size=64KB让每个批次尽量装饱满，lz4压缩把带宽和磁盘压力降一大截，buffer.memory=128MB撑住峰值流量。压测结果比调优前好了非常多：生产者侧吞吐从3.5万条/秒提升到11万条/秒以上，端到端P99延迟从850ms降到260ms。
特别提醒一句：retries不要设成无限大。默认值是2147483647，看起来是“多试几次更可靠”，实际配合较大linger.ms时，会导致部分消息在Broker端重复写入，消费端需要额外处理幂等。我们的建议是重试次数控制在3次以内，并且把delivery.timeout.ms设置一个上限，避免消息卡在内存里一直重试。
4. 消费者端调优：把下游吃满，别做木桶短板
很多人调优只管生产和Broker，觉得消费端处理慢是业务代码的问题。但消费者客户端的参数设置不合理，会让下游连Kafka已经准备好的数据都拿不走。消费端调优的目标很简单：让消费者每一轮拉取都尽可能拿满数据，并且不触发频繁的再平衡。
4.1 拉取模型怎么调：fetch.min.bytes与fetch.max.wait.ms的配合
Kafka消费者是主动拉取模型，每次拉多少、拉多久，完全由fetch.min.bytes和fetch.max.wait.ms控制。
fetch.min.bytes默认是1字节，意思是只要Broker上有一丁点数据，消费者就立刻拉走。这个设置在低延迟场景可以，但在高吞吐场景会让消费者陷入高频空转。拉取请求一轮接一轮，网络往返很多，实际拿到的数据却很少。把这个值调大，比如设成8KB或者16KB，消费者会等Broker积累足够数据后才真正发起一次拉取，请求次数大幅减少，吞吐自然上来。
fetch.max.wait.ms配合fetch.min.bytes使用。它规定了消费者最多愿意等多长时间。如果Topic流量不大，数据一直攒不够fetch.min.bytes，消费者也不能死等，到了fetch.max.wait.ms就必须先拉取当前已有的数据。默认500ms，要降低消费端延迟，可以调到100~200ms；要注意如果单次拉取的数据量很小，这个等待时间直接成为固定延迟成本。
另外一个参数fetch.max.bytes控制每次拉取响应体的大小，默认50MB，基本够用。如果单条消息特别大（比如接近max.poll.records限制），可能需要同步调大。这里有个常见误区：拉取的数据量（byte）和记录条数（record）是两个维度，你调大了fetch.min.bytes但单条消息就有几百KB，一批只拉几条，max.poll.records又设得很小，就会造成记录数和字节数之间的错配。
4.2 并发模型与再平衡：max.poll.records和线程数是关键
max.poll.records默认500，单次拉取最多返回的记录数。这个参数决定了消费者每一轮poll()拿到多少数据。如果单条消息处理耗时较长（比如需要同步写数据库），500条很可能超出处理能力，导致这一轮没处理完，还没来得及下一轮poll()，会话超时就被判定为“死亡”，被动触发再平衡，进而引发大规模分区重分配。
所以很多人踩过一个坑：max.poll.interval.ms默认5分钟，以为时间很长，但业务处理回调里偶尔发生一次慢查询或GC卡顿，就超过5分钟没调用poll()，被踢出消费组。这种问题在日志上表现为“ConsumerCoordinator not alive”或者频繁触发的Rebalance。解决办法不是盲目调大max.poll.interval.ms，而是合理估算每条消息的处理耗时、设置合适的max.poll.records，并且消费端的真正并发上限取决于分区数，而不是线程数。
如果你用多线程消费模型（一个主线程poll()，工作线程并发处理），建议max.poll.records取值在“处理延时可接受的范围内越大越好”，同时设置session.timeout.ms和max.poll.interval.ms留足余量。如果单线程同步处理模型，max.poll.records应该控制在“一轮poll()的处理时间低于max.poll.interval.ms的一半”左右。具体到数值，我一般把max.poll.records设在200~500之间，让单轮处理时间控制在几秒内。
4.3 延迟敏感场景的消费端参数取舍
消费端低延迟优化的核心思路刚好和生产端相反：生产端希望攒批，消费端则希望数据一到位、立刻拉走。
对延迟敏感的场景，我会把fetch.min.bytes降到1KB甚至保持默认1字节，同时把fetch.max.wait.ms调到50ms左右。每50ms最多延迟一次拉取，基本能满足大多数业务对秒级以下的时延要求。代价是请求次数变多，Broker的网络线程和消费者的CPU都更忙。如果你的Topic数据量本来就小（比如每分钟只有几百条），这个代价几乎可以忽略；如果是每秒钟几万条的流量，还是建议在吞吐和延迟之间找个平衡点，别一味追求低延迟。
此外，enable.auto.commit在延迟敏感场景建议设成false，改用手动提交位移。自动提交的间隔（默认5秒）和消费者处理逻辑是脱节的，如果处理完一批消息但位移还没提交，恰好此时宕机，重启后会重复消费大量消息。手动提交可以在“处理成功后提交”和“批量处理完成后提交”两种语义中精确控制，代价是代码里多几行逻辑，但可靠性和精确度都更高。
我对消费端调优的总结是：不要把消费端看成Kafka的“末端”，要把它当成整个链路的一部分来设计。你生产端再快，消费端拉不动，Lag只涨不清，什么吞吐优化都是白搭。
5. 吞吐与延迟的权衡：不存在万能参数，只存在合适的取舍
经常有人问我，有没有一组参数能把吞吐和延迟同时优化到极致？我的回答一直都是：没有。这两个指标在Kafka的架构设计里天然处于跷跷板的两端，你的任何参数调整，本质上都是在做取舍。
5.1 为什么吞吐和延迟看起来“互相矛盾”
从原理上看，吞吐是单位时间内处理的消息总量，延迟是一条消息从生产到消费所花的端到端时间。要提高吞吐，最好的办法是批量——把多条消息攒在一起发送、一批批地读写，节省系统调用的固定开销。可批量意味着消息要先在缓冲区等着，等的过程就在增加延迟。
反过来，要降低延迟，最好消息一到就立即处理、立即发送，但这样每条消息的固定开销都独立承担一遍，网络往返和请求处理次数暴增，吞吐必然下降。这就是为什么你调大linger.ms延迟变高了，但吞吐上去了；调小它吞吐下来了，延迟又降下来了。理解了这层关系，你就明白为什么网上那些“万能调优配置”不靠谱——不同业务的取舍权重完全不同，照抄只会收到相反的效果。
acks的选择也是同一个道理。acks=all意味着每条消息都要等所有副本确认，单条消息的确认延迟比acks=1高一截，但换来的是写入阶段的可靠性。生产端缓冲区大小同样是要权衡的点：缓冲大，流量洪峰时不容易阻塞，但缓冲区里堆积的消息本身就成了延迟的一部分；缓冲小，延迟低，但流量高峰时生产者程序会直接卡住。
5.2 按业务场景选择调优方向
既然参数调优本质是取舍，那第一步一定是想清楚你的业务更偏向哪一边。下面是我根据自己的实践整理的一个场景对照表，可以参考：
| 业务场景 | 核心诉求 | 建议参数取向 |
|---|---|---|
| 日志采集 | 吞吐优先，允许小范围延迟 | linger.ms=20~50，batch.size=64~128KB，压缩开启 |
| 实时风控 | 低延迟优先，单条处理要快 | linger.ms=0~5，batch.size=16KB，尽量不等待攒批 |
| 数据管道同步 | 吞吐与可靠性双高 | acks=all，压缩开启，副本拉取线程调到3以上 |
| 对账系统 | 可靠性优先，可以接受秒级延迟 | acks=all，min.insync.replicas=2，适当增加重试 |
| 用户行为分析 | 流量波动大，需要缓冲 | buffer.memory=128MB以上，消费端拉取积压时优先扩容分区 |
调优的方向定下来之后，参数具体数值还是要靠压测来验证。这里分享一个我常用的方法：先按场景定好方向，在测试环境用两倍于峰值流量的压力去压，记录吞吐、延迟、CPU、磁盘IO这四组数据；然后每次只改一个参数，记录变化，找到一个最优区间后，再去微调相邻参数。这样做出来的配置，才真正适配你的业务。
6. 常见问题与排查技巧实录
Kafka调优过程中遇到的问题五花八门，但有些问题出现的频率极高，基本是每个团队都会踩一轮的坑。我把它们整理成速查表，再挑两个印象最深的案例展开讲一讲。
6.1 问题速查表
| 现象 | 常见根因 | 排查思路 | 解决方向 |
|---|---|---|---|
| 生产吞吐上不去，CPU不高 | linger.ms=0导致请求过多 | 看请求数和批次大小 | 调大linger.ms和batch.size |
| 写入延迟忽高忽低 | PageCache命中率低或磁盘慢 | iostat看await和util | 优化刷盘策略，换SSD，或减少单Topic分区数 |
| ISR频繁收缩，分区副本失步 | num.replica.fetchers=1拉取太慢 | 看UnderReplicatedPartitions指标 | 调大到3~4，检查网络带宽 |
| 消费端频繁Rebalance | poll()处理超时或线程阻塞 | 看日志中的Rebalance事件 | 调大max.poll.interval.ms，减小max.poll.records |
| 消息出现乱序 | 重试导致多个请求乱序 | 确认是否启用重试且in.flight大于1 | max.in.flight.requests.per.connection=1 |
| 消费者Lag不降 | 分配不均或消费线程太少 | 看各分区Lag分布 | 调整分区分配策略，增加并发消费能力 |
| 请求队列堆积 | IO线程不足 | RequestQueueSize持续偏高 | 调大num.io.threads |
6.2 印象最深的两次线上事故复盘
第一次是分区扩容事故。某业务方发现Topic消费太慢，直接把分区数从12扩到48，然后重启消费组。结果Rebalance一触发，所有分区全部分配到其中一个节点上，其他节点空闲，Lag更严重了。原因是消费者用的是range分配策略，默认策略在分区数变更后容易出现分配不均。后来改成了roundrobin配合自定义分配器，才解决了倾斜问题。
第二次是副本不同步故障。某个集群的大Topic出现持续性的分区副本失步，ISR不断缩成只剩Leader，风险极高。排查发现根因是消息体突然变大，某个时段单条消息接近1MB，而网络线程接收缓冲区只有默认的100KB左右，导致网络传输效率极低，副本拉取长期跟不上。最终调大了socket.request.max.bytes和网络缓冲区，并且排查到这个变化来自某个发送端改了消息序列化格式，回滚后恢复正常。
这两次事故给我的教训很深刻：Kafka的性能问题往往不是单个参数的问题，而是参数、数据特征、业务行为三者的错配问题。调优前先理清你的数据长什么样、业务怎么写的、部署拓扑是什么，再谈参数。
6.3 我的调优习惯与工具清单
最后分享一些我个人的调优习惯，不算什么标准方法论，但确实帮我在多个集群上避过坑。
第一条，每次只改一个参数，改完必须压测对比。并行修改多个参数，你永远不知道哪个改动起了作用，哪个改动在帮倒忙。我的习惯是每轮压测只调整一个维度，记录一组结果，再做下一个。
第二条，所有参数变更走代码仓库，留变更记录。Kafka不像普通应用，调参的影响需要时间才能完全暴露。把每次改动的原因、压测数据、结果都记录下来，出了问题能回溯。别相信记忆，尤其别相信几个月后的记忆。
第三条，留存一份当前集群的“参数基线快照”。包括所有Broker和客户端的生效参数、当时的流量峰值、典型的延迟分布。等将来流量翻倍或者业务模型突变时，拿快照对比，能很快找到新引入的瓶颈。
工具方面我常用的有这几个：监控告警用Prometheus + Grafana（重点监控kafka_server_brokertopicmetrics_bytesin_total、UnderReplicatedPartitions这类指标）；排查慢请求抓线程快照用jstack；磁盘和网络性能直接用iostat、iftop，不引入额外组件。Kafka自带的命令行工具里，kafka-configs.sh可以动态查改Topic级别的配置，kafka-consumer-groups.sh用来查消费组Lag和成员状态，这两个够用了，不必一开始就上重型管控平台。
写在最后。Kafka调优这个东西，说复杂不复杂，说简单也不能轻视。真正把它调明白了，你会发现核心不是抄几个参数，而是搞懂每一层的工作原理，理解每个参数在链路中的位置，知道改了它会发生什么、代价是什么。按照“指标先行、瓶颈定位、参数适配、压测验证”的思路走一遍，你的集群离“高性能”就不远了。希望这篇全链路调优的记录，能帮你少走一些我走过的弯路。
