监控长连接断连需聚焦时间点、原因及上下文，通过dmesg查内核异常、ss查连接状态、tcpdump验中间设备干扰、业务日志定位根因，并用脚本持续采样连接数波动以触发告警。
监控特定服务的长连接断开与重连，关键不是只盯“连接通不通”，而是捕获连接状态变化的**时间点、原因和上下文**——比如 TCP RST、FIN 交换异常、keepalive 超时、或进程主动关闭 socket。Linux 不会默认记录每次断连细节，需组合内核日志、连接跟踪、进程行为与业务日志交叉印证。
抓取内核级断连信号：dmesg + ss 实时比对
长连接异常中断常触发内核干预，留下可追溯痕迹：
- 运行 dmesg -T | grep -i "reset\|fin\|drop\|orphaned"，重点关注：
• "TCP: too many orphaned sockets" → 连接未正确 close，被内核强制回收
• "TCP: out of memory — consider tuning tcp_mem" → 内存不足导致静默丢包或 RST
• "nf_conntrack: table full" → NAT/防火墙环境连接跟踪溢出，长连接状态丢失 - 同时用 ss -tinp state established '( dport = :端口号 )'（如
ss -tinp state established '( dport = :8080 )'）查看当前活跃连接及对应 PID；若某连接突然消失，再查该 PID 是否仍在运行（ps -p PID -o pid,comm,etime），可判断是服务崩溃还是连接被外力中断
检查 keepalive 生效性与中间设备超时
很多“长连接断开”实际是因 keepalive 未启用或被中间设备（云 LB、防火墙）提前切断：
- 确认服务端 socket 启用了 keepalive：
• 查看 sysctl：sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
• 默认 time=7200 秒（2 小时），若业务心跳间隔 > 该值，且负载均衡器空闲超时设为 600 秒，则连接会在第 10 分钟被单向断开 - 验证是否真被中间设备干扰：
• 在服务端用 tcpdump -i any port 端口号 -w conn.pcap 抓包，观察 FIN/RST 出现位置（本端发？对端发？无响应后超时？）
• 若只有 SYN 发出、无 SYN-ACK 返回，或 ESTABLISHED 后突然收到 RST，大概率是防火墙/NAT 设备主动干预
关联业务日志与连接生命周期
应用层日志才是断连根因的直接证据，但需与连接状态对齐时间：
- 在服务启动时开启详细网络日志（如 Java 应用加
-Djavax.net.debug=ssl:handshake或 Netty 的logging.level.io.netty.handler.logging=DEBUG） - 搜索日志中含 “close”、“reset”、“broken pipe”、“connection reset by peer”、“read timeout” 的行，并用 grep -B5 -A5 "reset" 查看前后上下文，确认是主动关闭（如服务 reload）、被动终止（如对端 crash），还是读写阻塞超时
- 若服务使用连接池（如 HikariCP、Druid），重点查 pool 日志中的 "Connection is not available" 或 "Evicting connection"，可能表明连接已断但池未及时检测，后续请求才暴露问题
构建轻量断连事件记录脚本
不依赖外部工具，用 shell 持续采样并落盘关键状态：
- 每 30 秒执行一次：
date +"%F %T"; ss -tinp state established '( dport = :端口号 )' | wc -l; ss -tinp state fin-wait-2,closed-wait,time-wait '( dport = :端口号 )' | wc -l; echo "---" - 将输出追加到
/var/log/service_conn.log，配合 awk 统计单位时间连接数波动：awk '/^2026/{c++; if($3==0) down++} END{print "total:",c,"down events:",down}' /var/log/service_conn.log - 发现连续 2 次 ESTABLISHED 数为 0，或 FIN_WAIT2/CLOSE_WAIT 持续增长，即可触发告警或自动拉起健康检查
