Linux进程网络流量监控：nethogs与bmon实战指南

1. 为什么需要监控进程级网络流量？

在日常的Linux系统运维、开发调试，甚至是个人使用中，我们经常会遇到一些令人困惑的网络问题：服务器带宽突然被占满，导致网站访问缓慢或SSH连接卡顿；云主机的流量费用莫名飙升，超出了预算；某个后台服务运行一段时间后，响应变慢，怀疑它在“偷偷”上传或下载数据。面对这些情况，我们通常的第一反应是使用top或htop查看CPU和内存，或者用nload、iftop查看整体的网络带宽使用情况。

iftop确实是个好工具，它能告诉你哪个IP地址在和你的服务器疯狂通信，占用了大量带宽。但问题来了：当你看到192.168.1.100:443这个连接占用了50Mbps的带宽时，你只知道有一个到该IP的加密连接很忙，却无法立刻知道是系统上哪一个具体的进程（比如是nginx、mysql还是某个你自己写的python脚本）发起的。在服务器上可能运行着成百上千个进程，定位到“元凶”就成了一个“抓瞎”的过程。

这就是进程级网络监控的必要性。它直接建立“网络流量”与“系统进程”之间的桥梁，让你能一目了然地看到：

• 哪个进程是流量消耗大户。
• 它正在与哪些远程地址通信。
• 通信的端口是什么。
• 实时速率(KB/s, MB/s) 和累计流量(总发送/接收字节数) 是多少。

掌握了这些信息，你就能快速做出判断：如果是正常的业务进程（如视频转码、数据备份），可以评估其合理性或进行优化；如果是未知的、可疑的进程（如潜在的挖矿木马、异常爬虫、配置错误的服务），就能立即采取行动，终止进程或深入调查。

2. 核心工具选型：从iftop到更精细的nethogs与bmon

iftop是基于网络接口和连接（socket）的监控工具，它工作在更底层。而我们要找的进程级工具，需要能够关联到/proc/net下的网络状态信息和/proc/[pid]/下的进程信息。市面上有几个经典选择，各有优劣。

2.1 nethogs：专注进程的“流量顶流”

nethogs是我在应急排查时最常使用的工具之一。它的设计哲学非常简单直接：像一个针对网络流量的top命令。启动后，它会实时刷新，按进程分组显示当前的网络带宽使用情况（发送和接收速率）。

安装（以CentOS/RHEL和Ubuntu/Debian为例）：

# CentOS/RHEL sudo yum install epel-release -y sudo yum install nethogs -y # Ubuntu/Debian sudo apt update sudo apt install nethogs -y

基本使用：直接运行sudo nethogs会监控默认的网络接口（通常是eth0或ens33）。它的输出非常直观：

PID USER PROGRAM DEV SENT RECEIVED 1234 www-data nginx: worker process eth0 5.553KB 124.770KB 5678 mysql mysqld eth0 0.247KB 0.476KB 9012 john /usr/bin/python3 eth0 202.112KB 0.000KB

你可以一眼看到，PID为9012的python进程正在以约200KB/s的速度向外发送数据，而接收几乎为零，这很可能是在上传文件或进行数据外传，非常值得警惕。

高级用法与技巧：

• sudo nethogs eth1：指定监控特定的网络接口，在多网卡服务器上非常有用。
• sudo nethogs -d 2：设置刷新间隔为2秒，默认是1秒。在流量波动大时，适当调大间隔可以让输出更稳定易读。
• sudo nethogs -t：追踪模式。这会启动一个交互式界面，你可以按s键按发送流量排序，按r键按接收流量排序，按m键在KB/s、KB、B等不同单位间切换。这是最常用的交互模式。
• 排查技巧：当你怀疑某个进程时，在nethogs的交互界面里，选中该进程对应的行，按m键可以显示该进程更详细的路径和参数，有助于确认进程身份。

nethogs的局限性：它主要展示实时速率，对于历史累计流量的统计较弱。虽然可以看到当前连接，但对于该进程所有历史连接的总流量统计，不是它的强项。

2.2 bmon：兼顾整体与细节的“控制面板”

bmon是一个功能更丰富的带宽监控和速率估算工具。它不仅能像iftop一样展示每个连接的流量，还能通过插件的形式展示每个进程的流量（需要额外安装）。它的界面更像一个图形化的仪表盘。

安装与启用进程监控：

# 安装bmon sudo apt install bmon -y # Ubuntu/Debian sudo yum install bmon -y # CentOS/RHEL (可能需要EPEL) # 运行bmon并启用进程模块 sudo bmon -p eth0 -o ascii -r 2 -R proc

• -p eth0: 指定接口。
• -o ascii: 使用ASCII文本输出（适合终端）。
• -r 2: 2秒刷新一次。
• -R proc:关键参数，加载并启用proc插件，这是显示进程流量的核心。

在bmon的界面中，你可以按方向键选择不同的视图。当proc插件启用后，你可以找到一个显示进程流量（Proc）的视图，它会列出进程的PID、命令名以及对应的发送/接收速率。

bmon的优势与不足：优势在于它集成了多种视图（整体带宽、单连接、进程），在一个工具内能完成多角度分析。不足是它的进程视图信息相对nethogs较为简洁，且需要记住加载插件的参数，对新手稍不友好。

工具选型心得：对于“快速定位哪个进程在吃带宽”这种紧急任务，我首选nethogs，因为它最直接、最快。对于需要同时观察整体带宽趋势和进程贡献度的场景，或者进行稍长时间的监控，bmon是更好的选择。iftop则用于当你知道问题出在网络层，需要分析具体IP和端口对话时使用。

3. 深度排查：结合ss/netstat与/proc文件系统

上面两个工具能帮你快速定位到“嫌疑进程”。但有时候，我们需要更深入的信息：这个进程到底建立了哪些连接？对方是谁？连接状态如何？累计传输了多少数据？这时，就需要结合传统网络诊断命令和Linux内核暴露的详细信息。

3.1 使用ss命令锁定进程的连接

ss(Socket Statistics) 是比古老netstat更现代、更快的工具。我们可以用它来过滤出特定进程打开的所有网络连接。

# 查找指定PID（例如9012）打开的所有网络套接字 sudo ss -tunap | grep -E “pid=9012(,|$)” # 解释： # -t: TCP连接 # -u: UDP连接 # -n: 以数字形式显示地址和端口（不解析主机名和服务名） # -a: 显示所有连接（监听和非监听） # -p: 显示进程信息（需要sudo） # grep: 过滤出包含该PID的行

执行后，你可能会看到类似这样的输出：

tcp ESTAB 0 0 192.168.1.5:5678 203.0.113.10:443 users:((“python3”,pid=9012,fd=3))

这告诉我们，PID 9012的python3进程，通过文件描述符3，建立了一个到203.0.113.10:443的TCP连接，当前状态是ESTABLISHED。

3.2 挖掘/proc文件系统：获取累计流量“元数据”

Linux内核将每个进程的详细信息都放在/proc/[pid]/目录下。其中有两个文件对我们追踪流量至关重要：

1. /proc/[pid]/net/dev：这个文件包含了该进程视角下的每个网络接口的累计流量统计。注意，这里的“累计”是该进程生命周期内通过该接口发送和接收的总字节数。

   sudo cat /proc/9012/net/dev

   输出类似于系统级的/proc/net/dev，但只统计该进程的流量。你可以找到eth0那一行，查看bytes（接收字节）和bytes（发送字节）两个字段。这是计算进程总消耗流量的最准确来源之一。

2. /proc/[pid]/fd/：这个目录包含了该进程打开的所有文件描述符（fd）。网络连接也是以文件描述符的形式存在的。你可以看到fd 3对应着什么：

   sudo ls -la /proc/9012/fd/3

   输出可能是socket:[12345678]，这证实了它是一个网络套接字。结合ss命令，你就完整地勾勒出了“进程 -> 文件描述符 -> 网络套接字 -> 远程地址”的完整链条。

3.3 一个实战排查案例：揪出异常数据上传进程

假设你收到云平台报警，服务器出向带宽持续跑满。你快速登录服务器操作：

1. 第一步，全局观：运行sudo nethogs -d 5。等待几秒刷新后，发现一个名为backup_script.py的进程独占带宽，发送速率达到80MB/s，而接收几乎为零。
2. 第二步，查身份：记下其PID，比如是2048。通过ps aux | grep 2048或cat /proc/2048/cmdline查看该进程的完整启动命令和参数，确认它是否为你知晓的备份脚本。
3. 第三步，查连接：运行sudo ss -tunap | grep pid=2048。发现它正与一个外部IP198.51.100.25的22端口（SSH）保持多个ESTAB连接。
4. 第四步，评估影响：查看sudo cat /proc/2048/net/dev，发现eth0的发送字节数已经达到了上百GB。这解释了为什么流量费用激增。
5. 第五步，做决策：如果这是一个未经授权的或配置错误（如循环上传）的备份任务，你可以选择用kill -TERM 2048优雅地终止它，或者先kill -STOP 2048暂停它，再检查其日志和配置文件。

这套组合拳下来，从发现问题到定位根因，思路清晰，证据链完整。

4. 进阶：持续监控、日志记录与自动化脚本

手动排查解决了突发问题，但对于需要长期监控、生成报告或设置警报的场景，我们需要更自动化的方法。

4.1 使用nethogs进行快照式监控

nethogs本身支持将一段时间内的统计信息输出到文件，虽然功能比较基础，但可用于简单记录。

# 运行nethogs 30秒，并将输出重定向到文件 timeout 30 sudo nethogs -t -d 2 > nethogs_log.txt 2>&1

之后你可以分析nethogs_log.txt文件，观察进程流量的变化趋势。

4.2 利用/proc实现自定义流量监控脚本

更灵活的方式是编写一个Shell或Python脚本，定期抓取/proc/[pid]/net/dev和进程信息，计算差值，从而得到每个进程在监控周期内的流量消耗。

下面是一个简单的Shell脚本示例monitor_net_proc.sh，它每10秒采样一次，计算每个进程的流量增量：

#!/bin/bash INTERVAL=10 LOG_FILE="/var/log/proc_net_usage.log" # 函数：获取所有进程的流量快照 get_snapshot() { local snapshot_file="/tmp/net_proc_snapshot.$$" > “$snapshot_file” # 清空或创建临时文件 # 遍历/proc下所有数字目录（即进程目录） for pid_dir in /proc/[0-9]*/; do pid=$(basename “$pid_dir”) if [ -r “$pid_dir/net/dev” ]; then # 提取进程名 comm=$(cat “$pid_dir/comm” 2>/dev/null | tr -d ‘\n’) # 提取eth0的接收和发送总字节数（根据你的网卡名调整） # awk ‘NR>2’ 跳过前两行标题行 traffic_info=$(awk ‘/eth0:/ {print $2“,“$10}’ “$pid_dir/net/dev” 2>/dev/null) if [ -n “$traffic_info” ]; then echo “$pid,$comm,$traffic_info” >> “$snapshot_file” fi fi done echo “$snapshot_file” } echo “开始监控进程网络流量，间隔 ${INTERVAL}秒…” | tee -a “$LOG_FILE” last_snapshot=$(get_snapshot) while true; do sleep $INTERVAL current_snapshot=$(get_snapshot) # 使用awk比较两次快照，计算流量差 awk -F, ‘ NR==FNR { # 读取第一个文件（上次快照） last_rx[$1]=$3; last_tx[$1]=$4; last_comm[$1]=$2; next; } { # 读取第二个文件（本次快照） pid=$1; comm=$2; rx=$3; tx=$4; if (pid in last_rx) { diff_rx = rx - last_rx[pid]; diff_tx = tx - last_tx[pid]; # 转换为KB/s (因为INTERVAL秒内的差值) rate_rx_kbs = diff_rx / 1024 / ‘“$INTERVAL”‘; rate_tx_kbs = diff_tx / 1024 / ‘“$INTERVAL”‘; # 只打印有流量的进程 if (rate_rx_kbs > 0.1 || rate_tx_kbs > 0.1) { printf “[%s] PID: %-6s %-20s RX: %8.2f KB/s, TX: %8.2f KB/s\n”, strftime(“%H:%M:%S”), pid, comm, rate_rx_kbs, rate_tx_kbs; } } # 更新为本次快照，用于下次比较 last_rx[pid]=rx; last_tx[pid]=tx; } ’ “$last_snapshot” “$current_snapshot” | tee -a “$LOG_FILE” # 为下一次循环更新快照文件 rm -f “$last_snapshot” last_snapshot=$current_snapshot done

脚本使用注意：这个脚本是一个基础示例，需要root权限运行，且网卡名（eth0）需要根据你的实际环境修改。它在生产环境使用前需要加强错误处理（比如进程中途退出）、优化性能（避免频繁遍历/proc）以及处理新出现的进程。

4.3 集成到现有监控系统

对于企业级监控，更常见的做法是将进程级网络指标收集到如Prometheus这样的监控系统中。可以利用：

• node_exporter的netstat或sockstat收集器：它可以暴露每个进程的网络连接数等信息，但默认不包含流量字节数。
• ebpf_exporter或自定义eBPF程序：这是更高级和强大的方案。eBPF（Extended Berkeley Packet Filter）可以在内核态高效地跟踪每个进程的网络数据包，并统计其流量，然后将指标导出给Prometheus。这提供了近乎实时的、低开销的精细监控能力，是未来主流的方向。
• 商业APM（应用性能监控）工具：如Datadog, New Relic等，它们的代理程序通常具备深度集成，能够自动关联应用、进程与网络指标。

从临时的命令行排查，到编写脚本进行定期记录，再到接入完善的监控体系，你对进程网络流量的掌控力也随之层层递进。核心思路始终不变：将网络层面的数据流（IP:Port）与系统层面的执行实体（Process）准确关联起来。掌握了nethogs、bmon，理解了/proc文件系统的奥秘，并学会用脚本将这一切自动化，你就再也不会对服务器上“谁在偷跑流量”这个问题感到迷茫了。