Kafka消费lag大幅上涨及broker出现too many files open错误咨询

lsof输出中标记为can't identify protocol的文件描述符，本质是内核未完成回收的半关闭状态TCP套接字，并非磁盘数据文件，你观测到的7万+打开文件数绝大部分属于这类异常残留的网络连接，触发原因可从以下方向排查：

• 检查Kafka的connections.max.idle.ms配置：该参数默认值为600000（10分钟），即Broker会主动断开空闲超过10分钟的连接。若你集群该参数被调大至远大于默认值，甚至设为-1（永不关闭空闲连接），搭配客户端侧存在连接泄漏、用完连接不主动关闭的问题，就会持续累积TCP连接占用文件句柄，直到触及进程句柄上限抛出too many files open错误。
• 检查Kafka进程的文件句柄上限配置：生产环境Kafka进程的句柄上限至少要配置到65536以上，推荐配置20万+。若你使用systemd管理Kafka服务，需单独修改服务配置中的LimitNOFILE参数，仅修改全局ulimit不会对systemd托管的服务生效。
• 排查近期客户端侧变更：若有新上线的生产者/消费者服务未配置连接池、或连接池配置错误，每次请求都新建连接不复用，会短时间产生大量短连接，TCP半连接状态的套接字来不及被内核回收，就会快速堆积占用句柄。

消费lag的计算逻辑是分区最新end offset与消费者已提交offset的差值，异常暴涨的常见原因如下：

• 本次Broker是句柄耗尽导致的强制宕机，并非优雅停机，宕机时大量已写入消息的offset元数据未及时持久化到__consumer_offsets主题。若宕机节点承载了分区的leader副本，触发leader选举时如果ISR列表不完整，会出现位点截断或跳跃的情况，若消费者已提交的offset小于新leader的最早位点，会按照auto.offset.reset规则重置位点，若配置为latest则直接跳到最新位点，中间所有未消费的消息都会被计入lag。
• 宕机期间Broker不可用，配置了重试机制的生产者会将消息暂存在本地缓冲区，Broker恢复后会批量发送积压的消息，短时间内分区end offset会快速上涨，而消费者侧需要完成重连、分区重分配、位点拉取的流程才能恢复消费，消费速度远跟不上生产速度，直接推高lag。
• 若__consumer_offsets主题的副本落在宕机的Broker上，宕机期间__consumer_offsets的leader无法正常选举，消费者拉取不到自己之前提交的offset，会直接触发位点重置逻辑，大量历史未消费消息被计入lag，就会出现你观测到的lag从8亿直接飙升至100亿的情况。

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