1. 项目概述为什么需要监控进程级网络流量在Linux服务器运维、性能调优或者排查线上故障时我们经常会遇到一些经典问题服务器带宽突然跑满但top或htop显示CPU和内存都挺正常每月流量账单异常超标却不知道是哪个“内鬼”程序在偷偷上传下载安全巡检时发现异常外连需要快速定位是哪个进程在“搞鬼”。这时候系统自带的ifconfig、ip -s link只能看到网卡级别的总流量nethogs这类工具能看进程但信息又不够持久和全面。所以一个能持续监控、精准定位、历史回溯进程级网络流量和实时网速的方案就成了系统管理员和开发者的刚需。这不仅仅是运行一个命令那么简单它涉及到从内核数据获取、用户态工具解析到数据持久化、可视化展示的一整套方法论。今天我就结合自己多年在运维和性能分析中的实战经验带你从原理到实践彻底搞懂如何在Linux下查看进程的网速和流量使用情况并搭建一个轻量级的长期监控体系。2. 核心原理与工具选型从内核到用户态要监控进程的网络流量我们必须理解数据是如何从网卡流经内核再被应用程序处理的。简单来说当数据包到达网卡后内核的网络协议栈进行处理并将其交付给对应的Socket。每个Socket都与一个进程或线程相关联。因此监控流量的本质就是监控这些Socket的读写活动。2.1 内核数据源/proc文件系统与NetlinkLinux提供了两个主要的数据来源/proc/net/dev这个文件提供了网络接口级别的流量统计包括接收和发送的字节数、包数等。它是ifconfig和ip -s命令的数据来源。但它的粒度太粗无法关联到进程。/proc/PID/net/dev和/proc/PID/fd/每个进程都有自己视角的网络命名空间信息。更关键的是在/proc/PID/fd/目录下你可以看到进程打开的所有文件描述符其中类型为socket:[inode]的链接就指向了网络套接字。通过解析这个inode号我们就能将套接字与系统全局的Socket信息关联起来。/proc/net/tcp/proc/net/udp/proc/net/tcp6/proc/net/udp6这些文件列出了系统所有活跃的TCP/UDP连接其中就包含了每个连接对应的inode号、本地地址、远程地址、状态等信息。Netlink Socket这是一个更现代、更高效的内核与用户空间通信的机制。像ss、ip命令就使用Netlink来获取网络连接和路由信息。一些高级监控工具也通过Netlink直接订阅内核的网络事件实现实时性更高的监控。注意/proc文件系统是动态的每次读取都会获取瞬时快照。因此要计算网速单位时间内的流量变化就必须进行周期性的采样和差值计算。2.2 用户态工具对比各显神通基于上述原理社区诞生了多种工具各有侧重工具名称工作原理实时网速历史流量进程关联特点与适用场景nethogs直接解析/proc优秀无优秀经典工具类似top的交互式界面实时刷新各进程流量排查突发流量神器。iftop解析/proc/net/dev和pcap优秀无一般仅IP/端口显示主机间流量可看到IP和端口级对话但默认不关联进程名。nload解析/proc/net/dev优秀无无专注于网卡级别的实时流量图形化显示非常直观。vnstat定期采样/proc/net/dev无优秀无历史流量统计之王。后台守护进程按小时、天、月统计网卡总流量生成报表。bmon多种来源proc netlink优秀简单历史无功能强大的带宽监控器支持多种输出格式和图形化界面。iptraf-ng/ntopng包捕获分析优秀有一般更专业的网络监控和流量分析平台功能全面但配置复杂。选型心得快速排查“谁在跑流量”首选nethogs 直接sudo nethogs eth0 一目了然。想看IP之间的流量对话用iftop -n。长期统计服务器出口总流量vnstat是不二之选配置简单数据可靠。想要同时监控进程并记录历史没有现成的“银弹”需要组合工具或自己动手。这也是我们后面要深入的重点。3. 实时监控实战快速定位流量消耗进程当告警响起带宽飙升我们需要的是最快的手段。这里介绍最有效的实时监控组合拳。3.1 使用 nethogs 进行进程级流量 TOPnethogs的安装很简单主流发行版都有包。# Debian/Ubuntu sudo apt-get install nethogs # CentOS/RHEL/Fedora sudo yum install nethogs # 或 sudo dnf install nethogs使用起来更简单sudo nethogs 网卡名例如sudo nethogs eth0或sudo nethogs enp3s0。如果不指定网卡它会监控默认路由出口的网卡。输出解读与交互PID USER PROGRAM DEV SENT RECEIVED 1234 www-data /usr/bin/php-fpm8.2 eth0 0.173 5.132 KB/sec 5678 mysql /usr/sbin/mysqld eth0 12.592 0.000 KB/sec 9012 john /usr/lib/firefox/firefox eth0 0.047 58.921 KB/sec TOTAL 12.812 64.053 KB/secSENT/RECEIVED实时上行/下行速度。nethogs默认每秒刷新一次。交互命令m 在 KB/sec KB B MB 等不同单位间切换显示。s 按发送流量排序。r 按接收流量排序。q 退出。实操心得nethogs需要root权限因为它要读取所有进程的/proc信息。对于短时爆发的进程它可能来不及捕捉就结束了。这时可以尝试缩短采样间隔虽然本身不支持但可以配合脚本。它不显示具体的连接IP:Port如果你发现某个进程流量异常还需要用ss或lsof进一步排查该进程建立了哪些连接。3.2 进阶关联从进程到具体连接假设我们用nethogs发现PID为9012的firefox流量异常。下一步就是看它到底连了哪里。# 方法1: 使用 ss (推荐 比 netstat 更快更现代) sudo ss -tunap | grep pid9012 # -t: TCP, -u: UDP, -n: 数字形式(不解析主机名), -a: 所有, -p: 显示进程信息 # grep pid 是 ss 显示进程信息的格式 # 方法2: 使用 lsof sudo lsof -i -a -p 9012 # -i: 列出网络连接 -a: AND条件 -p: 指定PID # 方法3: 查看进程的文件描述符 sudo ls -la /proc/9012/fd/ | grep socket # 会得到像 socket:[1234567] 这样的输出 这个1234567就是内核中的Socket inode号。 # 然后去 /proc/net/tcp 里搜索这个inode需要将10进制inode转为16进制 就能找到对应的连接详情。这个方法比较底层 通常用前两种。示例输出 (ss)ESTAB 0 0 192.168.1.100:5678 203.0.113.10:443 users:((firefox,pid9012,fd123))这告诉我们Firefox (PID 9012) 通过本地端口5678正在与IP203.0.113.10的443端口很可能是某个HTTPS网站建立着ESTABLISHED连接。3.3 网卡级流量速览iftop 与 nload如果想先宏观再看微观可以先跑一下iftop或nload。iftop像网络版的top展示主机对主机的流量。sudo iftop -n -i eth0 # -n: 不解析主机名直接显示IP更快 -i: 指定网卡界面分为三部分顶部的流量刻度条中间的主机对流量列表显示双方IP和端口以及实时速率底部的发送、接收、总计速率。按p可以切换显示端口。nload则更专注于网卡本身的输入输出速率以动态图形条显示非常直观。nload eth0它默认分上下两个窗格分别显示流入Incoming和流出Outgoing流量有曲线图、刻度值和最大值标记对观察流量波动趋势很有帮助。4. 构建长期流量监控与统计体系实时监控解决了“当下是谁”的问题但运维更需要回答“过去是谁”、“用了多少”的问题。这就需要历史数据。我们的目标是既能查看任意时间段内进程的累计流量又能保留网卡的总流量历史。4.1 基石使用 vnstat 进行网卡级历史流量统计vnstat是一个轻量级、无依赖、后台运行的网络流量统计器。它不监控进程只定期默认5分钟从/proc/net/dev读取数据并将聚合后的数据存入本地数据库通常是/var/lib/vnstat/。安装与基本配置# 安装 sudo apt-get install vnstat # Debian/Ubuntu sudo yum install vnstat # CentOS/RHEL sudo dnf install vnstat # Fedora # 安装后通常服务会自动启动。如果没有需要初始化数据库并启动服务 sudo vnstat -i eth0 --create # 为eth0网卡创建数据库 sudo systemctl enable --now vnstat # 启用并启动服务常用命令vnstat -i eth0 # 查看eth0的今日、本月概要 vnstat -d # 查看日流量统计 vnstat -m # 查看月流量统计 vnstat -h # 查看小时流量统计 vnstat -l # 实时监控模式类似nload但基于统计 vnstat -tr # 显示最近5分钟的速率输出示例 (vnstat -d)eth0 / daily day rx | tx | total | avg. rate ----------------------------------------------------------------- 2024-05-10 15.23 GiB | 4.67 GiB | 19.90 GiB | 1.93 Mbit/s 2024-05-11 12.87 GiB | 3.89 GiB | 16.76 GiB | 1.62 Mbit/s ----------------------------------------------------------------- estimated 14 GiB | 4 GiB | 18 GiB |这非常清晰地展示了每天的流量消耗对于核对云服务商账单、评估带宽升级需求至关重要。配置心得vnstat的配置文件通常在/etc/vnstat.conf。你可以调整数据更新间隔UpdateInterval 数据保留时长 或者为多个网卡同时做监控。它非常稳定几乎不消耗系统资源是每个服务器都应该安装的基础工具。4.2 挑战与方案实现进程级历史流量监控这是难点因为Linux内核本身并不持久化记录每个进程的历史网络流量。我们需要自己动手思路是定期采样进程的瞬时流量通过计算差值来估算其速率并累加得到历史流量。方案一使用 iftop 的文本模式配合脚本iftop有一个非常实用的-t参数可以输出纯文本格式并且可以通过-s N指定运行N秒后退出。我们可以写一个脚本定期运行它并解析输出。#!/bin/bash # 脚本名monitor_traffic.sh INTERVAL10 # 采样间隔单位秒 IFACEeth0 LOG_FILE/var/log/process_traffic.log while true; do TIMESTAMP$(date %Y-%m-%d %H:%M:%S) # 运行iftop 2秒获取文本输出并过滤出包含“”或“”的行即流量行 OUTPUT$(sudo iftop -t -s 2 -i $IFACE 2/dev/null | grep -E (|\s*[0-9])) # 这里需要对OUTPUT进行复杂解析提取IP、端口、速率信息。 # 一个简化的示例我们可以记录下总带宽占用最高的几个IP echo $TIMESTAMP - Top Talkers: $LOG_FILE echo $OUTPUT | head -5 $LOG_FILE # 记录前5行 echo --- $LOG_FILE sleep $INTERVAL done这个方案的问题在于iftop的文本输出解析起来比较麻烦且它默认不显示进程名只有IP和端口。需要结合ss或lsof将端口映射回进程复杂度较高。方案二使用 nethogs 的批处理模式配合脚本遗憾的是nethogs官方没有提供稳定的批处理或文本输出模式。一些旧版本的-t参数可能有效但新版本不一定支持。强行用sudo nethogs -t eth0可能会卡住。因此这个方案不推荐。方案三推荐使用内核eBPF技术——bcc工具集这是现代Linux系统内核4.1上最强大、最优雅的方案。eBPF允许我们在内核中安全地运行沙盒程序以极低的开销捕获事件。bcc是Facebook开源的一套eBPF工具集其中就包含了我们需要的工具tcptop和tcplife。首先安装bcc-tools# Ubuntu/Debian sudo apt-get install bpfcc-tools linux-headers-$(uname -r) # CentOS/RHEL 8 sudo dnf install bcc-tools # 安装后工具通常在 /usr/share/bcc/tools/ 目录下使用tcptop实时查看进程级TCP流量sudo /usr/share/bcc/tools/tcptop -C # -C 表示不滚动清屏适合脚本抓取它会像top一样实时刷新显示每个进程PID、COMM的TCP发送和接收速率以及远程IP和端口信息非常完整。使用tcptrace或自定义eBPF脚本进行历史记录bcc提供了Python前端我们可以编写简单的Python脚本让tcptop的数据输出到文件或时间序列数据库如InfluxDB中从而实现历史监控。一个简化的示例脚本log_traffic.py#!/usr/bin/env python3 from bcc import BPF import time import datetime # 定义eBPF程序C语言代码 bpf_text #include uapi/linux/ptrace.h #include net/sock.h #include bcc/proto.h struct data_t { u32 pid; u64 ts; u64 rx_b; u64 tx_b; char comm[TASK_COMM_LEN]; }; BPF_PERF_OUTPUT(events); int kprobe__tcp_sendmsg(struct pt_regs *ctx, struct sock *sk, struct msghdr *msg, size_t size) { u32 pid bpf_get_current_pid_tgid() 32; struct data_t data {}; data.pid pid; data.ts bpf_ktime_get_ns(); data.tx_b size; bpf_get_current_comm(data.comm, sizeof(data.comm)); events.perf_submit(ctx, data, sizeof(data)); return 0; } // 同样可以挂载tcp_recvmsg等函数来监控接收 # 这里只是一个极度简化的框架完整的程序需要处理更多细节如连接跟踪、累计流量等。这个方案功能强大但对使用者要求较高需要一定的eBPF和Python知识。对于大多数场景定期运行tcptop并配合其他日志工具可能更实用。方案四折中实用使用pidstat配合系统审计pidstat是sysstat工具包的一部分它可以按进程统计IO但默认不包括网络IO。不过我们可以通过一个“曲线救国”的方式监控进程的read和write系统调用并过滤出socket文件描述符。这同样复杂。最终建议 对于绝大多数运维场景我推荐“vnstat总流量历史 nethogs/tcptop实时进程定位”的组合。这已经能解决95%的问题。如果确实需要严格的进程级历史流量审计例如在多租户环境进行计费那么投入精力搭建基于eBPF的定制化数据采集管道并将数据存入Prometheus Grafana这样的监控栈是更专业的长期方案。5. 自动化监控脚本与告警集成将上面的手动检查过程自动化是提升运维效率的关键。这里提供一个实用的思路和脚本框架。5.1 核心思路定期采样、差值计算、阈值告警采样每隔一段时间如10秒记录每个活跃进程的累计发送/接收字节数。数据可以从/proc/PID/net/dev进程视角获取但更简单的方法是解析nethogs或ss -tunap的瞬时快照并估算速率。计算将本次采样的字节数与上次采样值相减除以时间间隔得到该时间段内的平均速率。累加将每个时间段的流量速率×时间累加到该进程的“今日流量”计数器。告警当某个进程的实时速率超过阈值如10 MB/s或者其“今日流量”超过配额如1 GB时触发告警发送邮件、写入日志、调用Webhook。5.2 脚本示例简易进程流量监控与日志记录下面是一个简化版的Bash脚本它利用ss和/proc/net/dev的差值计算来估算进程流量。请注意这是一个概念验证脚本在生产环境使用需要更严谨的错误处理和性能优化。#!/bin/bash # 脚本名proc_net_monitor.sh INTERVAL5 # 采样间隔秒 LOG_DIR/var/log/net_monitor mkdir -p $LOG_DIR LOG_FILE$LOG_DIR/traffic_$(date %Y%m%d).log # 关联数组用于存储上次的字节数 declare -A prev_rx prev_tx echo 开始监控进程网络流量间隔${INTERVAL}秒日志$LOG_FILE while true; do TIMESTAMP$(date %Y-%m-%d %H:%M:%S) # 获取当前所有TCP/UDP连接的进程信息 (简化处理这里只取TCP) # 使用ss获取PID本地端口远程IP:PORT以及连接状态 CONN_INFO$(sudo ss -tunap | awk /ESTAB/ {print $6, $5} | tr -d users:() | sed s/pid//g) # 遍历每个连接信息格式PID,LocalIP:Port-RemoteIP:Port # 注意这里为了简化我们假设一个进程只有一个连接。实际情况需要聚合。 while IFS read -r line; do if [[ -z $line ]]; then continue; fi PID$(echo $line | cut -d, -f1) # 获取进程名 if [[ -f /proc/$PID/comm ]]; then COMM$(cat /proc/$PID/comm) else COMMunknown fi # 获取该进程网络命名空间下的总流量注意这是该进程所有网络流量的总和不区分连接 # 读取 /proc/$PID/net/dev 的第二行eth0等网卡的rx_bytes和tx_bytes # 这里存在巨大简化实际中进程可能在多个网络命名空间且/proc/$PID/net/dev可能不存在或格式不同。 if [[ -f /proc/$PID/net/dev ]]; then NET_INFO$(grep -E eth0|ens|enp /proc/$PID/net/dev | head -1) if [[ ! -z $NET_INFO ]]; then RX_CURR$(echo $NET_INFO | awk {print $2}) # 接收字节 TX_CURR$(echo $NET_INFO | awk {print $10}) # 发送字节 KEY$PID-$COMM # 计算差值 if [[ -n ${prev_rx[$KEY]} ]]; then RX_DIFF$((RX_CURR - prev_rx[$KEY])) TX_DIFF$((TX_CURR - prev_tx[$KEY])) RX_RATE$(echo scale2; $RX_DIFF / $INTERVAL / 1024 | bc) # KB/s TX_RATE$(echo scale2; $TX_DIFF / $INTERVAL / 1024 | bc) # KB/s # 记录到日志示例只记录速率大于1KB/s的 if (( $(echo $RX_RATE 1 || $TX_RATE 1 | bc -l) )); then echo $TIMESTAMP PID:$PID COMM:$COMM RX:${RX_RATE}KB/s TX:${TX_RATE}KB/s $LOG_FILE fi fi # 更新上一次的值 prev_rx[$KEY]$RX_CURR prev_tx[$KEY]$TX_CURR fi fi done $CONN_INFO sleep $INTERVAL done重要警告上述脚本是一个高度简化且存在缺陷的示例。它最大的问题在于/proc/PID/net/dev显示的是该进程所在网络命名空间中所有接口的流量如果该命名空间里有多个接口如Docker容器数据会混在一起。它无法准确区分单个连接的流量。频繁读取/proc文件系统在进程数很多时可能对性能有轻微影响。生产环境建议 对于真正的生产监控应该考虑使用eBPF工具如bcc的tcptop作为数据源准确性更高开销更低。将采集到的数据进程名、PID、速率、累计流量发送到时间序列数据库如Prometheus。使用Grafana制作监控仪表盘并设置告警规则。或者使用成熟的APM应用性能监控或网络性能监控NPM商业/开源解决方案它们通常已经集成了进程级流量监控功能。6. 常见问题排查与实战技巧在实际操作中你肯定会遇到各种奇怪的情况。这里分享一些我踩过的坑和解决技巧。6.1 工具输出为空或看不到进程使用sudonethogs、iftop、ss -p等工具需要root权限才能读取其他进程的网络信息。指定正确的网卡服务器可能有多个网卡eth0eth1bond0docker0等。使用ip addr或ifconfig确认流量经过的网卡名。对于容器网络需要查看veth接口或进入容器的网络命名空间。流量类型nethogs默认只监控IPv4 TCP/UDP流量。一些工具可能不显示本地回环lo流量或IPv6流量请查阅工具手册。瞬时无流量如果采样瞬间进程没有活跃连接可能不会被捕捉到。持续观察或拉长监控时间。6.2 如何监控Docker容器的流量Docker容器有自己的网络命名空间这是监控的难点也是重点。进入容器网络命名空间监控# 找到容器的PID docker inspect --format {{.State.Pid}} 容器名或ID # 假设PID是12345 sudo nsenter -t 12345 -n nethogs # -n表示进入网络命名空间然后在这个命名空间内运行nethogs这样看到的流量就是该容器“眼里”的流量。从宿主机监控veth接口 Docker会为每个容器创建一对veth设备一端在容器内通常叫eth0一端在宿主机上名字像vethxxxxxx。# 找到容器对应的veth接口 docker inspect 容器名 | grep -i veth # 或者更精确的方法先找到容器的网络命名空间索引 # 然后使用ip link或brctl show如果使用bridge网络查找 # 监控这个veth接口 sudo nethogs vethxxxxxx使用Docker原生命令docker stats命令可以显示容器的CPU、内存、网络IO等实时数据其中网络IO就是容器级别的总流量。docker stats --format table {{.Name}}\t{{.NetIO}}使用cAdvisor Prometheus 这是容器监控的标准方案。cAdvisor会采集每个容器的详细性能指标包括网络流量并暴露给Prometheus采集最终在Grafana中展示。6.3 流量统计不准与云控制台或账单差异大这是一个非常常见的问题可能的原因有统计维度不同云厂商控制台统计的是经过虚拟化层Hypervisor的“外网”流量通常只计费流出Egress流量并且可能不包括同一可用区内、同一VPC内或与云服务如OSS、RDS通信的流量。而你用vnstat在系统内统计的是物理/虚拟网卡的所有流量包括内网流量、系统更新、备份流量等。采样误差vnstat默认5分钟采样一次如果流量在采样间隙突发又结束可能会被漏计或低估。可以调小UpdateInterval但会增加轻微负载。工具覆盖不全vnstat基于/proc/net/dev如果有些流量不经过这里例如某些特定的内核模块、隧道流量就可能统计不到。时间区间对齐云账单通常是按自然月结算而vnstat -m显示的是从当月1号到现在的流量在月中对比时数据必然对不上。排查建议在服务器上安装vnstat并确保其正常运行sudo vnstat -d查看历史。在云控制台开启流量监控查看其提供的监控图表对比同一时间段的数据。重点检查服务器上是否有大量内网同步如rsync NFS、备份、日志上报、容器镜像拉取等产生流量的作业。使用iftop或nethogs在流量高峰时段进行实时分析定位具体的流量来源。6.4 发现未知或可疑进程占用大量流量这是安全排查的典型场景。定位进程使用nethogs或ss -tunap找到高流量进程的PID和命令。检查进程信息ps aux | grep PID # 查看进程详细信息、启动命令、用户 ls -la /proc/PID/exe # 查看进程的可执行文件真实路径 cat /proc/PID/cmdline # 查看进程的完整命令行参数检查网络连接使用ss -tunap | grep PID查看它建立了哪些连接特别是连接到外部陌生IP和端口的连接。检查进程行为如果进程可疑可以使用strace或lsof进一步分析。sudo strace -p PID -e tracenetwork # 跟踪进程的网络系统调用 sudo lsof -p PID # 查看进程打开的所有文件、网络连接等收集证据并处置如果确认是恶意进程如挖矿木马、后门记录下所有信息PID 可执行文件路径 连接IP 启动命令然后果断终止进程删除文件并排查入侵途径弱口令、漏洞等。6.5 vnstat 数据丢失或重置数据库损坏极端情况下/var/lib/vnstat/下的数据库文件可能损坏。可以尝试停止vnstat服务删除对应网卡的.db文件如eth0.db然后用vnstat -i eth0 --create重建。网卡名变更如果服务器网卡名改变了例如从eth0变成了ens192vnstat会认为这是一个新接口。需要手动迁移或重新初始化。系统时间跳变如果系统时间发生大幅回拨或跳跃vnstat的日志可能会混乱。保持NTP服务正常运行很重要。7. 可视化与高级集成对于需要长期、集中监控多台服务器的场景命令行工具就不够用了。我们需要将数据集中起来并可视化。7.1 使用 Prometheus Grafana 监控网络流量这是云原生时代的标准监控栈。数据采集ExportersNode Exporter采集主机指标其中包含node_network_receive_bytes_total和node_network_transmit_bytes_total两个关键指标这是网卡级别的流量。自定义Exporter要采集进程级别的流量目前没有完美的标准Exporter。可以使用cAdvisor它能为容器提供进程级实际上是容器级的丰富指标包括网络。自己编写Exporter用Python或Go调用bcc库或解析/proc将进程流量数据以Prometheus格式暴露出来。这是一个高级任务。使用ebpf_exporter或prometheus-process-exporter这些社区项目尝试暴露进程级指标但网络流量部分可能不完整或需要配置。配置Prometheus在prometheus.yml中配置抓取这些Exporter的job。Grafana仪表盘导入社区中现成的“Node Exporter Full”仪表盘里面通常有网络流量面板。针对进程流量需要自己创建面板查询语句可能类似rate(process_network_receive_bytes_total{jobcustom-exporter}[5m])前提是你的自定义Exporter提供了这个指标。7.2 使用 NetData 进行全方面实时监控NetData是一个开源的、功能极其强大的实时监控工具安装简单开箱即用。# 一键安装脚本 bash (curl -Ss https://my-netdata.io/kickstart.sh)安装后访问http://你的服务器IP:19999即可看到炫酷的仪表盘。在“Network”部分它不仅能展示每个网卡的实时流量、错误包、丢包等还能通过“Apps”子菜单展示按进程分组的网络带宽使用情况这几乎是零配置实现进程级网络监控的最快途径。NetData底层也使用了eBPF等高效技术数据采集粒度细但历史数据保留时间较短默认适合实时监控和故障排查不适合做长期的趋势分析虽然它也支持后端数据库。7.3 商业/开源APM与NPM解决方案如果预算允许或规模庞大可以考虑更专业的方案APM (Application Performance Monitoring)如Datadog APM, New Relic, SkyWalking, Pinpoint。它们通过代码插桩或系统代理可以追踪到应用内部方法调用的耗时同时也通常能关联到该请求产生的网络流量尤其是对外部服务的调用。NPM (Network Performance Monitoring)如SolarWinds NPM, ManageEngine OpManager, 开源的有ntopng, Zabbix配合自定义监控项。它们专注于网络层能提供更精细的流量分析、协议识别和拓扑发现。这些方案功能强大但部署和配置复杂成本也更高。对于中小型团队或个人项目vnstatnethogsNetData的组合已经足够强大和高效。