Linux服务器网络流量异常?用Nethogs揪出罪魁祸首(附实时监控脚本)
深夜两点,服务器告警铃声突然响起——带宽使用率突破95%。作为运维工程师,这种场景再熟悉不过。传统工具如iftop能告诉你流量去向,却无法精确到进程级别。这就是Nethogs的价值所在:它像手术刀般精准定位每个吞噬带宽的进程,而不仅仅是展示宏观流量。
1. 为什么Nethogs是排查流量异常的终极武器
当服务器出现带宽暴增时,多数管理员的第一反应是查看网络接口统计。但ifconfig或ip -s link只能显示总体流量,就像只知道水库总出水量却找不到漏水的管道。Nethogs的独特之处在于其进程级监控能力,直接关联网络流量与具体应用进程。
与传统工具的对比:
| 工具 | 监控维度 | 实时性 | 需root权限 | 数据持久化 |
|---|---|---|---|---|
| iftop | 连接/端口级别 | 高 | 是 | 否 |
| nload | 设备级别 | 高 | 否 | 否 |
| vnstat | 历史统计 | 低 | 否 | 是 |
| Nethogs | 进程级别 | 高 | 是 | 可配置 |
实际案例:某电商平台大促期间MySQL从库突然出现网络吞吐激增。使用Nethogs发现是备份脚本异常执行导致,而常规监控只显示"3306端口流量过高"这类模糊信息。
2. 快速部署与核心操作指南
2.1 跨平台安装方案
主流Linux发行版只需一条命令:
# Debian/Ubuntu
sudo apt install nethogs -y
# RHEL/CentOS
sudo yum install epel-release && sudo yum install nethogs
# Arch Linux
sudo pacman -S nethogs
对于Docker环境,建议使用主机模式运行:
docker run --net=host -it ubuntu bash -c "apt update && apt install -y nethogs && nethogs"
2.2 实战命令手册
基础监控:
sudo nethogs eth0 -d 5 # 每5秒刷新指定网卡
高级用法组合:
# 记录日志并过滤Java进程
sudo nethogs -t -p | grep -i java > java_network.log
# 监控特定用户进程
sudo nethogs -u www-data
常用参数解析:
-v:显示版本并退出-c:刷新次数限制(适合脚本调用)-s:按流量排序(默认降序)
3. 异常诊断四步法
3.1 实时捕获阶段
运行sudo nethogs -d 1观察流量突增进程,重点关注:
- 未知二进制文件
- 非常规用户启动的进程
- 持续增长的TX流量(可能数据外泄)
3.2 进程溯源技巧
发现可疑PID后,深入检查:
# 查看进程完整路径
ls -l /proc/<PID>/exe
# 检查进程树
pstree -p <PID>
# 检查网络连接
ss -tunap | grep <PID>
3.3 自动化处置方案
将以下脚本保存为/usr/local/bin/network_killer.sh:
#!/bin/bash
THRESHOLD=1024 # KB/s
INTERFACE=eth0
LOG=/var/log/nethogs_alert.log
nethogs -t -d 1 -c 10 $INTERFACE | awk -v limit=$THRESHOLD '
$6 > limit {
system("kill -9 " $1);
print strftime("%Y-%m-%d %H:%M:%S"), $0 >> "'"$LOG"'";
print "Killed PID", $1, "("$2") using", $6, "KB/s";
}'
3.4 数据持久化方案
使用systemd服务实现长期监控:
# /etc/systemd/system/nethogs_monitor.service
[Unit]
Description=Nethogs Network Monitor
[Service]
ExecStart=/usr/sbin/nethogs -t -d 300 -c 288 eth0 >> /var/log/nethogs_daily.log
Restart=always
[Install]
WantedBy=multi-user.target
4. 企业级监控系统集成
4.1 Prometheus数据导出
通过nethogs-exporter实现指标采集:
#!/usr/bin/env python3
import subprocess
from prometheus_client import start_http_server, Gauge
NETWORK_USAGE = Gauge('process_network_bytes',
'Network usage per process',
['pid', 'user', 'program'])
def collect():
output = subprocess.check_output(['sudo', 'nethogs', '-t', '-d', '1', '-c', '1'])
for line in output.decode().split('\n'):
parts = line.split()
if len(parts) >= 7:
NETWORK_USAGE.labels(pid=parts[0],
user=parts[1],
program=parts[2]).set(parts[6])
if __name__ == '__main__':
start_http_server(8000)
while True:
collect()
4.2 Grafana看板配置
建议监控以下关键指标:
- 进程流量TOP10
- 异常流量增长率
- 非业务进程流量占比
- 突发流量持续时间

5. 高级防护策略
5.1 网络流量基线
建立正常流量profile:
# 生成7天流量基线
for i in {1..7}; do
nethogs -t -d 3600 -c 24 >> baseline_$(date +%u).log
done
# 分析基准值
awk '{print $6}' baseline_*.log | sort -n | uniq -c
5.2 安全加固方案
对高风险进程实施限制:
# 使用cgroups限制网络带宽
cgcreate -g net_cls:limited
echo 0x1001 > /sys/fs/cgroup/net_cls/limited/net_cls.classid
tc filter add dev eth0 parent 1: protocol ip handle 1: cgroup
# 限制特定进程
cgclassify -g net_cls:limited $(pidof risky_program)
6. 性能优化与陷阱规避
常见问题排查:
- 若nethogs无输出,检查
CAP_NET_ADMIN权限 - 高负载环境下使用
-d 5降低刷新频率 - 虚拟化环境需开启混杂模式
替代方案对比:
- 容器环境:
nsenter + nethogs - 云平台:结合VPC流日志分析
- 大规模集群:eBPF方案如
tcptop
实际运维中发现,某次"内存泄漏"实则是PHP-FPM进程持续外联传输日志文件。通过nethogs定位后,添加了log_rate_limit配置解决问题。这种案例印证了精准监控工具在复杂故障排查中的不可替代性。
&spm=1001.2101.3001.5002&articleId=154274782&d=1&t=3&u=a4dc607f49a8492abb448aefeeec6c9f)
329

被折叠的 条评论
为什么被折叠?



