最近，我们的服务器监控系统发出了紧急警报：服务器的各项关键性能指标在 2025 年 8 月 15 日 11:30 左右出现了同步飙升。面对这一异常，我们并没有急于猜测，而是通过一个核心线索——公网流出流量，一步步揭开了问题的真相。本文将详细记录我们的排查过程，并深入解析每一步的工具应用与背后原理。
第一步：从宏观监控入手，锁定异常的核心
故障排查的第一步，是细致分析监控图表，从中提取关键信息，从而圈定问题发生的精确时间。
如上图所示，我们发现，在 2025 年 8 月 15 日 11:30 左右，服务器的各项指标出现了显著异常：
- 公网流出带宽：在 11:37:00 这个时间点，公网流出带宽达到了惊人的 110.899 M bit/s 的峰值，远超正常水平。与此同时，公网流入带宽也有轻微增加，但量级远小于流出带宽。
- CPU 使用率：在带宽飙升的同时，CPU 使用率也从 25% 左右的正常水平，迅速升高到接近 100% 的峰值。
- 磁盘 I/O：磁盘的读操作吞吐量和次数也出现了同步的峰值。
此外，网络连接数的监控图也揭示了重要线索：
- 在 11:30 左右，服务器的网络连接总数从约 2.5K 激增至 5.5K 左右。
- 其中，
NON_ESTABLISHED（非活跃）连接数急剧增加，最高达到了约 2.475K，与ESTABLISHED（已建立）连接数几乎持平。
排查原理：多项关键指标在同一时间点同步异常，这强烈暗示着某个进程或任务正在大量消耗系统资源。公网带宽的异常是本次故障的核心线索，它将我们的排查方向聚焦于网络流量。同时，网络连接数中非活跃连接的激增，表明问题可能与高频率的连接建立与关闭有关，而非简单的持续高流量。这些宏观的监控数据，为我们后续深入排查提供了明确的起点和方向。
第二步：iftop
定位流量去向，一剑封喉
既然问题是公网流出流量异常，那么这些流量究竟流向哪里？这是我们排查的下一个关键问题。我们运行了
iftop
工具，它能够实时监控网络流量的流向，结果令人震惊：
iftop实时监控显示，服务器的公网流出流量（=>）绝大部分都流向了 IP 地址xxx。- 流出速率高达每秒 165M bits/s，与监控图上的带宽峰值完全吻合。
iftop底部的TX（发送）流量峰值达到了 181M bits，进一步证实了带宽飙升的根源。
排查原理：iftop
的强大之处在于它的实时性和直观性。它将服务器抽象的带宽数据，具象化为"本地
IP A 到远端 IP B 的流量"。通过观察 iftop
的输出，我们立刻将目光从"哪台服务器出了问题"转移到"这台服务器在向哪里发送数据""，从而大大缩短了排查路径。
第三步：nethogs
锁定应用进程，确认元凶
我们已经知道是服务器在向 xxx
发送大量数据，但具体是哪个应用在做这件事？我们使用
nethogs工具，它能够按进程实时监控流量，最终锁定了“元凶”：
nethogs的输出明确显示，snakeweb_应用是产生这些高流量的进程。- 其发送（
SENT）和接收（RECEIVED）流量都远超其他进程，证实了它是本次故障的直接“元凶”。
排查原理：nethogs 将流量与具体的进程
ID（PID）和程序路径关联起来，为我们提供了最终的、无可辩驳的证据。至此，我们已经完整地锁定了问题：snakeweb_
应用向 IP xxx 发送大量数据。
第四步：发现
TIME_WAIT 堆积，理解行为模式
在确认了应用和流量去向后，我们回过头来审视最初的一些异常现象。网络连接数的监控图显示，NON_ESTABLISHED（非活跃）连接数在
11:30 左右急剧增加，最高达到了约 2.475K，与
ESTABLISHED（已建立）连接数几乎持平。
排查原理：大量的 TIME_WAIT 连接是 TCP
连接在主动关闭后保持的一段等待时间。这一现象揭示了问题的另一面：snakeweb_
应用在发送数据时，采用了高频率的短连接方式。每一次连接的建立和关闭，都在系统中留下了大量的
TIME_WAIT
状态连接，虽然不直接消耗带宽，但却占用了文件描述符等系统资源，成为了一个需要优化的次要问题。
第五步：身份确认，解决问题
通过 whois 查询，我们确认了流量流出的 IP
属于阿里云，也是我们的一个服务之一。至此，整个问题链条已经完整。最后经过排查，内部的另外一个服务，新加了一个实时同步数据的功能，导致了流量的飙升。
总结与反思
这次排查完美地展示了工具在故障排查中的巨大作用。我们从公网流量飙升这个核心问题入手，利用
iftop 快速将抽象的性能异常转化为清晰的网络通信流；再通过
nethogs，我们锁定了具体进程；最后通过对
TIME_WAIT
等次要症状的分析，我们还原了应用的具体行为模式。整个过程环环相扣，最终成功定位并解决了问题。这提醒我们，在开发过程中，应时刻关注新功能对网络带宽、连接模式等底层资源的影响，避免因业务逻辑的改动而引发潜在的性能危机。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
