kafka集群under replicated分析
近期随着业务消息量增大，现网几套kafka集群频繁收到under repliacted告警，集合近期定位分析过程，主要有以下几个方面：
1. 查看是否有主机挂掉，或近期是否有主机重启，通过kafdrop查看started时间，若有异常重启，需要分析日志定位原因；
2. 使用kafdrop可以对分区副本情况进行排查，若发现大部分under replicated的分区都与某个broker上的副本有关，则很可能是broker的问题，可以重点分析下server.log和controller.log
3. 消息量大导致broker间同步消息瓶颈，由于默认副本同步线程数num.replica.fetchers=5，所以针对消息量大或者消息体较大的场景，可以适当调高该配置；
4. CPU负载：检查CPU负载，检查软中断均衡是否开启，消息量大的场景建议开启软中断均衡，但是软中断开启均衡后可能加剧CPU的负载，因为CPU用于单块CPU用于上下文切换的时间减少了，如果请求量足够，会放通更多的请求进来，TPS进一步增加，若CPU持续高于40%，建议扩容CPU，或者增加扩容broker节点数并rebalance topic数据，或者新建集群迁移部分topic过去；
5.磁盘负载：
a. 使用top查看wa占用CPU的百分比，如果该占比长时间大于5%，则需要考虑优化；
b. 使用iostat -x 1查看磁盘io状态，util%为操作的时间占比，长时间接近100%说明磁盘满负荷工作，需要优化，svctm是平均每次io操作的服务时间，await是平均每次io操作的等待时间（包括服务时间），如果两者接近，则io几乎没有等待，如果await远大于svctm，则说明IO队列太长，应用得到响应变慢；
c. 磁盘故障，需要优化磁盘监控，版本优化，支持坏盘自动剔除；
可以考虑更换更快的磁盘；增加磁盘数量，动态新增log.dirs并均衡数据，提高并发度；调整内核elevator算法；优化应用；升级CPU等；
6. 内存负载： kafka使用堆外内存来缓存pagecache，增加发送和消费的性能，大部分内存会被cache掉，内存瓶颈很少遇到；
7. 网卡负载： 目前大部分主流机器都是万兆网卡起步了，网卡瓶颈的案例现网较少遇到，但还是发生过，某些TPS高伴随消息体大的业务，会大大消耗磁盘和网卡的性能，可以网卡发送、接受的buffer情况，通过netstat -an | grep 9092 查看3、4列，如果持续堆积较大，则存在网卡瓶颈，跨机房场景出现网卡瓶颈要多一些，也可以结合netstat -s 和ss -s一起分析丢包情况；
8. 查看进程gc情况，jstat -gcutil pid 1000， 若gc较频繁，考虑增加堆内存大小；
提升：
1. 使用netstat -s 、ss -s分析问题能力
2. kafka socket buffer配置调优
3. 磁盘监控，dmesg分析问题
————————————————
版权声明：本文为CSDN博主「所长是我呦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ggh5201314/article/details/89298523
1. 查看是否有主机挂掉，或近期是否有主机重启，通过kafdrop查看started时间，若有异常重启，需要分析日志定位原因；
2. 使用kafdrop可以对分区副本情况进行排查，若发现大部分under replicated的分区都与某个broker上的副本有关，则很可能是broker的问题，可以重点分析下server.log和controller.log
3. 消息量大导致broker间同步消息瓶颈，由于默认副本同步线程数num.replica.fetchers=5，所以针对消息量大或者消息体较大的场景，可以适当调高该配置；
4. CPU负载：检查CPU负载，检查软中断均衡是否开启，消息量大的场景建议开启软中断均衡，但是软中断开启均衡后可能加剧CPU的负载，因为CPU用于单块CPU用于上下文切换的时间减少了，如果请求量足够，会放通更多的请求进来，TPS进一步增加，若CPU持续高于40%，建议扩容CPU，或者增加扩容broker节点数并rebalance topic数据，或者新建集群迁移部分topic过去；
5.磁盘负载：
a. 使用top查看wa占用CPU的百分比，如果该占比长时间大于5%，则需要考虑优化；
b. 使用iostat -x 1查看磁盘io状态，util%为操作的时间占比，长时间接近100%说明磁盘满负荷工作，需要优化，svctm是平均每次io操作的服务时间，await是平均每次io操作的等待时间（包括服务时间），如果两者接近，则io几乎没有等待，如果await远大于svctm，则说明IO队列太长，应用得到响应变慢；
c. 磁盘故障，需要优化磁盘监控，版本优化，支持坏盘自动剔除；
可以考虑更换更快的磁盘；增加磁盘数量，动态新增log.dirs并均衡数据，提高并发度；调整内核elevator算法；优化应用；升级CPU等；
6. 内存负载： kafka使用堆外内存来缓存pagecache，增加发送和消费的性能，大部分内存会被cache掉，内存瓶颈很少遇到；
7. 网卡负载： 目前大部分主流机器都是万兆网卡起步了，网卡瓶颈的案例现网较少遇到，但还是发生过，某些TPS高伴随消息体大的业务，会大大消耗磁盘和网卡的性能，可以网卡发送、接受的buffer情况，通过netstat -an | grep 9092 查看3、4列，如果持续堆积较大，则存在网卡瓶颈，跨机房场景出现网卡瓶颈要多一些，也可以结合netstat -s 和ss -s一起分析丢包情况；
8. 查看进程gc情况，jstat -gcutil pid 1000， 若gc较频繁，考虑增加堆内存大小；
提升：
1. 使用netstat -s 、ss -s分析问题能力
2. kafka socket buffer配置调优
3. 磁盘监控，dmesg分析问题
————————————————
版权声明：本文为CSDN博主「所长是我呦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ggh5201314/article/details/89298523
