大量短连接过多导致的丢包排查

小记

问题#

查看监控平台发现某个服务采集不到数据，在Grafana中异常显示为断点。

此异常服务为阿里云灰度一部分流量至腾讯云，监控表现也都集中在腾讯云。

排查思路#

1. 最开始表现为Grafana异常，也就着手与prometheus数据采集，是不是数据没有采集到，发现prometheus并没有异常，因为监控的其它服务并没有采集不到数据指标的情况
2. 后端报用户访问确实个别存在异常，怀疑服务本身问题，从服务pod cpu/内存，包括pod所在cpu/内存上看，一切正常
3. 通过监控告警发现通知：NodeHighNumberConntrackEntriesUsed，通过这一现象怀疑节点的连接跟踪异常
4. 连接节点主机，查看内核消息，mesg -T，异常提示：nf_conntrack: nf_conntrack: table full, dropping packet
5. 定位故障，大量短连接占用过多连接跟踪表记录，超过内核：net.nf_conntrack_max(连接跟踪最大值)

内核参数介绍#

net.nf_conntrack_max：

​ 该值为连接跟踪记录条目数，一般配置大小需根据机器规格定义，因为跟踪记录保存至内存中，记录条数越多，占用内存越大，当不合理配置该值，也会导致节点主机内存超过其限制。

nf_conntrack_tcp_timeout_time_wait：

连接跟踪条目数GC时间，默认的 established 状态的 GC 时间是 423000s（5 天），设置成这么长的 可能原因是：TCP/IP 协议中允许 established 状态的连接无限期不发送任何东西（但仍然活着），为防止 GC 掉这样长时间没流量但实际还活着的连接，就设置一个足够保守的 timeout 时间，如果对自己的网络环境和需求非常清楚，那可以将这个时间调到一个合理的、足够小的值； 如果不是非常确定的话，还是建议保守一些，例如设置 6 个小时，