导读：本站压力测试篇讲过怎么把带宽跑满，哪吒篇讲过怎么盯CPU和内存，但流量这个维度一直没正面讲——而它恰恰是计量制VPS最容易翻车的地方：套餐写着1TB，用超了按GB计费，或者直接给你停机。这篇把流量统计一次讲透：vnstat的安装和后台机制、日/月/Top10三张报表怎么看、rx和tx谁在吃流量、用量异常时怎么揪出是哪个进程、怎么用cron给自己发流量预警、多台机器的流量怎么汇总到一处。读完这篇，你对自己每月用了多少流量、被什么东西用掉的，心里会有一本明白账。
一、流量为什么必须盯：计量制的隐形成本
VPS的计费模型大体两种：不限流量限带宽（100M不限量），和限流量不限带宽（1TB月流量）。后者现在越来越主流，因为厂商好控制成本，用户看着也直观。但限流量模型有个天然的不对称：带宽你随时能感知——网站卡了就是满了；流量却是沉默的累计，等到厂商发邮件提醒"用量已达90%"，往往离扣费或停机只剩几天。更麻烦的是流量异常的成因经常很隐蔽：被当肉鸡对外攻击、网站图片被盗链、爬虫把你的站当靶场、某个容器的日志在疯狂外发——这些都不会在CPU图上留下痕迹。所以流量和磁盘一样，属于"必须自己主动看"的指标，而看它最省事的工具就是vnstat。
二、vnstat的机制：不抓包的网卡计数搬运工
先说清楚vnstat的工作原理，你就知道它为什么几乎零开销。网卡的收发字节数本来就被内核统计着（/proc/net/dev里那个一直在涨的计数器），vnstat做的事情只是定期把这个数字抄下来存进自己的数据库，然后在抄数之间做差值累加。它不抓包、不过滤、不解析任何流量内容，所以对CPU和内存的占用可以忽略不计——这对本站Swap篇讲过的小内存机器非常友好。代价也很明确：它只知道"用了多少"，不知道"谁用的、用去哪了"。前者靠vnstat，后者靠第五节的实时工具，两套配合才是完整的流量观测。另外抄数的是vnstatd这个守护进程（systemd篇讲过的服务管理方式直接适用），数据库默认在/var/lib/vnstat/，纯文本小文件，进备份清单很便宜。
三、安装与启动：三行命令跑起来
主流发行版仓库里都有，Debian系一行：
apt install vnstat
CentOS系先装EPEL再装：
yum install epel-release && yum install vnstat
装完启用服务并设开机自启（systemd篇的姿势）：
systemctl enable --now vnstat
服务起来后会自动检测网卡，一般eth0或ens3，云厂商机器通常一块主网卡，不用额外配置。装完等五到十分钟让它积累第一批数据，直接敲vnstat就能看到摘要。多网卡机器（比如有内网eth1）用vnstat -i eth1指定网卡，或用vnstat --add把另一块网卡加进监控列表。数据落盘后哪怕服务停了，历史记录也都在，重启不丢——这点比很多监控方案省心。
四、三张报表：日、月、Top10，各有各的用法
vnstat的灵魂是三张报表，对应三个问题。看"最近趋势"用日表：
vnstat -d
每天一行，rx（接收）、tx（发送）分列，最近30天。看"计费周期"用月表：
vnstat -m
月表是计费VPS最重要的一个视图——厂商按自然月或账单月计费，你就按同样的口径看这张表，月初到现在用了多少、按当前速率月底会到多少，一目了然。看"历史极值"用Top10：
vnstat -t
列出有史以来流量最大的十天。这张表的价值是"异常检测"：一个日均几个G的站，Top10里突然冒出一个500G的日子，那一天一定发生了值得调查的事——大概率是被扫描、被盗链或者被打了。三张表都支持--json输出（后面第七节会用到），纯文本数据库+JSON接口，这个朴素的设计让vnstat二十年不过时。
五、实时排查：iftop和nethogs双板斧
月表告诉你"超了"，接下来要回答"谁干的"。实时流量两板斧：iftop看连接，nethogs看进程。
iftop -i eth0 -P
按连接粒度展示实时带宽，两列分别是收发速率，能看到"哪个IP在和你的机器对传、传多快"。看到陌生IP以满速往外发数据，基本就是问题现场——配合ufw篇讲过的防火墙，直接封掉。
nethogs eth0
按进程粒度展示，直接回答"是哪个程序在吃流量"。容器场景尤其好用：宿主机上跑nethogs，哪个容器在疯狂外发一眼可见，再docker stats对照确认。排障口诀：先vnstat确认超了、再iftop找到对端、最后nethogs定位进程，三步之内必有答案。顺带一提，本站压力测试篇跑wrk时开着iftop看压测流量，也是验证机器实际出口带宽的土办法——有些超售机器标称1Gbps，iftop里实际只能跑到100M，看一眼就穿帮。
六、流量预警：cron里的月度预算检查
流量统计不做预警等于白统计。给cron加一条每日检查（cron篇的五行口诀）：
0 8 * * * used=$(vnstat -m --json m 1 | grep -o '"tx": *[0-9]*' | head -1 | grep -o '[0-9]*'); echo "本月已发送: $used MiB"
这行只是演示取数，实用版要加阈值判断：把月流量换算成MiB，用量超过80%就发告警（邮件怎么发、告警渠道怎么配，备份篇讲过用mail命令接告警的思路，直接复用）。阈值线建议设两道：80%提醒、95%强制处理。另外注意rx和tx要分开算——大部分厂商双向都计费，但有些套餐只计出口，看清楚自己的计费条款再设阈值，别按双向算吓自己。预警逻辑虽然土，但它可靠：不依赖任何外部服务，cron+vnstat两件套在任何机器上都跑得起来。
七、多机汇总：JSON输出与集中收集
手握多台小鸡的玩家（哪吒篇的典型读者），流量数据也该集中看。vnstat --json输出结构化数据，每台机器写个小脚本：
vnstat --json m 1 | curl -s -X POST -d @- https://panel.example.com/api/traffic
配合cron每日一推，收数端可以是一个极简的Web接口，也可以直接推到哪吒探针的自定义上报里。更懒的办法：把vnstat -m --oneline的输出append到一个共享的文本文件，人肉看也够用。集中看流量的价值在于发现"结构性的异常"：五台机器里四台每月稳定50G、有一台总是300G，那台要么承载了特殊业务，要么就该用第五节的三板斧查一查。单机数据回答"用了多少"，多机对比回答"用得正常吗"——后者才是流量的健康管理。
八、容器的流量去哪了：一个常见的认知误区
Docker玩家容易有个误区：docker stats里没看到容器流量，以为容器流量不计数。实际上容器共享宿主机内核，所有容器的流量都从宿主机网卡走，vnstat看到的是"宿主机全部流量"——容器一分不少都算在内。所以装了vnstat的机器不需要给每个容器单独装一套，宿主机层面一个数就够；需要按容器拆分时，用nethogs或cgroup的network统计去看。倒是要留意一个反向坑：有些镜像（尤其爬虫类、节点类应用）的流量行为远超你的预期，宿主机月表上莫名的几百G，down下来docker ps逐个排查，十有八九是某个容器的默认配置在偷跑。这也是为什么流量观测要落在宿主机层——它是唯一不会说谎的记账层。
结语
流量管理的完整闭环就三步：vnstat记账（知道用了多少）、iftop/nethogs排查（知道谁在用）、cron预警（超量前知道）。三件工具全部免费、全部轻量、全部开箱即用，加起来十分钟装完，换来的是计量制VPS上最踏实的一份安全感。建议今天就动手：装好vnstat，等它跑满一个月，你会第一次真正看清自己服务器的流量画像——那个数字和你想象的，大概率不一样。
