sar本身不直接统计连接数，但可通过-n sock（totsck/tcpsck）、-n dev（rxpck/s异常升高）、-n edev（rxdrop/s飙升）等指标组合定位连接暴增时段与特征，并需结合-s/-e时间窗口及ss/netstat验证。
排查历史网络连接数暴增，sar 本身不直接统计“连接数”（如 ESTABLISHED 连接个数），它记录的是网络接口吞吐、包量、错误及 socket 统计——但这些数据能帮你反向定位连接异常增长的时段和特征。关键不是查“有多少连接”，而是看“什么时间点网络行为明显偏离基线”。
确认 sar 是否有可用的网络历史数据
连接数暴增通常伴随流量、包量或错误率突变，先确认能否读取对应日期的网络采样：
- 检查 /var/log/sa/ 目录是否存在目标日期文件（如今天是 7 月 30 日，查 7 月 28 日就看 sa28）：
ls -l /var/log/sa/sa* - 若文件缺失，说明 sysstat 未运行或 cron 失效——此时无法回溯，需转向其他日志（如 netstat 快照、应用 access log 或防火墙 conntrack 日志）
- 确保使用
-f参数在最前：正确写法是sar -f /var/log/sa/sa28 -n SOCK，写成sar -n SOCK -f /var/log/sa/sa28会失败
重点看三个 sar 网络指标：SOCK、DEV、EDev
这三个视图分别反映连接状态、接口负载和错误源头，组合起来可判断是否为连接数问题：
-
sar -f /var/log/sa/sa28 -n SOCK查看 socket 统计：重点关注totsck（当前总 socket 数）、tcpsck（TCP socket 数）、udpsck（UDP socket 数）。若某时段totsck比平时高 3–5 倍且持续 10 分钟以上，大概率存在连接堆积 -
sar -f /var/log/sa/sa28 -n DEV看网卡收发包量（rxpck/s,txpck/s）和字节数（rxkB/s,txkB/s）。连接暴增常伴随大量小包（SYN/ACK/RST），表现为rxpck/s显著升高但rxkB/s升幅不大 -
sar -f /var/log/sa/sa28 -n EDev查错误包（rxerr/s,txerr/s）、丢包（rxdrop/s,txdrop/s）。若连接数涨的同时rxdrop/s也飙升，可能是内核 backlog 溢出或网卡队列满，而非应用层连接泄漏
结合时间窗口缩小范围并交叉验证
单看 sar 只能定位“异常时段”，要确认是不是连接数问题，必须联动其他命令还原现场：
- 用
-s和-e锁定分钟级区间：sar -f /var/log/sa/sa28 -n SOCK -s 14:30:00 -e 14:45:00（查下午 2:30–2:45） - 在同一时段查 CPU 和内存：
sar -f /var/log/sa/sa28 -u -r -s 14:30:00 -e 14:45:00若 CPU idle 骤降 +totsck暴涨，说明连接处理逻辑正在消耗资源；若 CPU 仍高 idle 但totsck高，则更可能是连接未释放（如 CLOSE_WAIT 堆积） - 事后补查确认：在疑似时段的服务器上执行
ss -s或netstat -s | grep -A 5 "Tcp:"，比对sar -n SOCK中的tcpsck是否吻合
常见误判与绕过限制的方法
sar 不记录每个连接详情，所以不能直接看到谁连了、连了多久。遇到以下情况需换思路：
- 若
sar -n SOCK显示totsck正常，但业务反馈连接超时——问题可能在连接建立后卡住（如 read timeout），应查sar -n TCP的retrans/s（重传率）或应用层日志 - 容器环境或 systemd-journald 未开启，
sar数据可能被截断。此时可查/proc/net/snmp或conntrack -S的历史快照（如有定期采集） - 想长期监控连接数，
sar不是最佳工具。建议搭配ss -s定时采集写入文件，或用 Prometheus + node_exporter 的node_netstat_Tcp_CurrEstab指标
