为什么要监控进程流量
很多运维人员都有过这样的经历：服务器带宽突然跑满，网站访问变慢，但用iftop或nethogs一看，只能看到某个IP在狂发数据，却不知道是哪个程序在作祟。我遇到的真实案例是，一台Centos 7服务器上部署了多个Java应用，其中某个微服务因为日志输出过于频繁，导致网卡出方向飙升到200Mbps，排查时花了大半天才定位到具体进程。从那以后，我就把进程级流量监控列入了日常巡检清单。
进程流量监控的意义在于，它能告诉你“谁在吃掉带宽”。相比于传统的网卡流量监控，进程级别的数据能直接定位到PID和程序名称，省去了根据端口反查进程的绕路操作。对于运行着几十个容器的生产环境，这个能力尤其宝贵。
nethogs能不能直接看出进程名
nethogs是我最先接触的工具，它的安装非常简单，yum install nethogs就能搞定。启动后界面会实时刷新，每一行显示一个进程的发送和接收速度，进程名和PID一目了然。我在测试机上跑nethogs eth0，能清楚看到nginx、sshd和java各自的流量走向。
但要注意一个坑：nethogs依赖libpcap抓包，在流量特别大的场景下，它自身就会消耗不少CPU。我在一台跑着视频转码服务的机器上测试过，当网卡流量超过500Mbps时，nethogs的CPU占用率突破了15%。另外，它只能显示有网络活动的进程，如果一个进程只是在本地读写文件，它是不会出现的。
对于临时排障centos 进程流量监控，nethogs足够用。如果你需要记录历史数据或者做告警linux环境变量，那就得换其他方案了。
用iftop加参数能不能定位到进程
iftop本身是看主机之间流量的，但它有一个隐藏能力：结合-P参数显示端口号。我在监控一个Web服务时，用iftop -i eth0 -P看到某个443端口上下行流量异常，然后通过lsof -i :443反查，发现是python3启动的一个HTTPS代理进程占用了大量带宽。
这个方法虽然绕了一点，但在没有专用工具的生产环境里非常实用。你可以写一个简单的shell脚本centos 进程流量监控，让iftop每10秒输出一次流量排行，再配合ss -tlnp解析端口对应的PID，就可以拼凑出进程级别的流量报表。我在一个银行客户的审计场景中用过这套组合拳，虽然不够优雅，但能应付合规检查。
当然，iftop的输出格式比较死板，如果你需要做数据可视化，可能需要借助awk和sed做二次处理。
自己写脚本能不能实现更细粒度的监控
当现成工具不能满足需求时，我倾向于用/proc文件系统自己动手。每个进程的网络流量信息藏在/proc/[pid]/net/dev里，但这个文件显示的是所有网卡的汇总。更精确的路径是/proc/[pid]/fd/下的socket文件描述符，配合ss命令能解析出每个连接的流量。
我写过一个小脚本：遍历/proc下所有PID，读取/proc/[pid]/io中的read_bytes和write_bytes，然后计算增量。虽然这个统计的是磁盘I/O而不是网络流量，但如果你把网络设备的字节数换算一下，也能实现类似效果。比较实用的做法是使用tc和iptables的owner模块，按UID或PID做流量统计，然后用conntrack工具导出数据。
这套方案对系统资源消耗极小，适合部署在老旧服务器上。我在一台只有1核1G的Centos 6机器上跑过，连续监控了三个月，没有出现过一次OOM。缺点是需要自己处理数据存储和告警逻辑，对脚本能力有一定要求。
生产环境推荐哪种长期方案
对于7×24小时运行的生产环境，我推荐bmon配合glances的组合拳。bmon可以按进程展示实时流量红帽linux，glances则能输出CSV格式的历史数据。我在公司内部运维平台上部署了glances的Web模式，通过API接口拉取每台机器的进程流量数据，存入时序数据库后用Grafana展示。
如果预算允许，可以考虑商业工具如Datadog或Zabbix的进程级别监控插件。它们内置了进程发现和流量聚合功能，能自动识别Java线程池中的每个工作线程。我帮一家电商公司迁移监控系统时，用Zabbix的进程监控模板直接采集了Nginx Worker进程的流量，省掉了大量脚本开发时间。
但要注意，任何监控方案都有性能开销。我在压测时做过对比，nethogs在千兆环境下CPU增加约3%，而基于eBPF的监控工具（如bcc-tools）的CPU增加不到1%。如果你的Centos内核版本在4.9以上，可以考虑安装bcc工具包中的tcplife和tcpconnect，它们能近乎零开销地追踪每个进程的网络连接和流量。
