带宽利用率计算；3个口径最容易搞混

带宽利用率计算这事儿，十次争吵里有八次不是算错，是口径不一样。运维盯着面板说链路只跑了三成，管预算的翻着账单说带宽眼看要撑爆；同一个网口、同一分钟，三个地方三个答案。谁都没撒谎，只是你算的是哪一层、哪个方向、哪段时间里的平均——这三个变量不定下来，算出来的数字基本只有观赏价值。

带宽利用率计算这三个口径，差在哪

先摆一句大白话：利用率 = 实际流量 ÷ 带宽上限。分母是谁、分子怎么取，就是全部的分歧来源。分母可以是物理口的协商速率，比如 1Gbps；也可以是你花钱买的那段计费带宽，比如 50Mbps。分子可以是 5 分钟平均、可以是当天峰值、也可以是 95 分位。分母一错，结果能差一个数量级：千兆口跑 50M，按物理口算是 5%，按买的带宽算就是满载，你说该报哪个？看你向谁汇报。

瞬时值和平均值，先问采样间隔

监控面板上那条平滑曲线，粒度通常是 5 分钟甚至更粗。突发流量在平均里被抹平了，可用户卡顿偏偏就发生在那一瞬间。想看实时抖动，单机上用 `iftop -i eth0`，或者 `sar -n DEV 1 10` 看秒级数据；反过来做容量规划就该粗粒度，日峰值、周峰值、P95 更扛用。95 计费是按月采样、去掉最高那一小段再取剩下的最大值，各家的采样窗口和算法并不完全一致，以服务商或官方页面说明为准。别拿 95 值去判断用户卡不卡，也别用瞬时峰值去申请扩容，两码事。

出方向和入方向，从来不是一个数

对外服务的站点，出方向才是大头。图片、视频、下载、API 返回全堆在出方向，入方向一般只有请求本身那点东西。云主机的带宽计费往往也盯出方向，入方向很多情况不计或者另有一套规则——这条一定看你手上服务商的说明，别照抄别人的经验贴。但做备份、跑同步、镜像仓库回源的时候会反着来，入方向忽然冲高，把只看单向的人吓一跳。所以看监控先分清 transmit 和 receive 两个计数器，别瞟一眼总量就去跟人对账。

链路带宽和应用层带宽，中间隔着一层开销

千兆跑不满是正常的，这话得说在前头。以太网帧头、IP 头、TCP 头、TLS 握手、ACK、重传，全都要占地方，小包业务天生吃亏。用 `curl -o /dev/null -w ‘%{speed_download}’` 测出来的是应用层速率，跟网卡计数器上的字节数之间差着一截，中间夹的就是协议效率。能跑到链路速率的六七成，已经算健康区间，具体比例跟包大小关系极大。还有些坑跟带宽没关系：网线只通了四芯、双工模式没协商对、中间串了个百兆小交换机，表现都像“带宽不够”，其实链路本身挺冤。

bit 和 Byte，这对老冤家还得提

Mbps 是比特每秒，MB/s 是字节每秒，差 8 倍。云厂商、CDN、交换机统计口径全部用 bit，浏览器下载、`wget`、`scp` 给的是 Byte。千兆口理论峰值 125MB/s，实际跑到七八十 MB/s 就该偷着乐。这条人人都知道，可一到对账还是经常有人拿 100Mbps 去比 100MB/s，然后到处说带宽虚标——冤枉了服务商，也耽误了自己排查。

口径定下来，工具才好选

单机看实时，`iftop`、`nload`、`bmon` 随便挑一个顺手的；看历史趋势，`vnstat -l` 和 `sar -n DEV` 够用，前者按天按月攒数据，后者看分钟级波动。容器里跑 `iftop` 看到的多半是 veth 网卡而不是物理网卡，数字会偏，排查时容易把自己带沟里。集群和云主机上可以用 Prometheus，`rate(node_network_transmit_bytes_total[5m])` 这类表达式拉长时间看斜率。云监控面板确实好用，但采样间隔和统计口径得自己翻文档确认一遍，别默认它是你想要的那个。

我自己的用法：按用途分三套

扩容决策看峰值和 P95，宁可留点余量，不然大促那天就是干瞪眼；成本对账只看计费口径，服务商怎么扣就怎么算，多算一分都是自嗨；长期容量规划看日均和增长斜率，别被某一天的尖刺带偏。这三套数字可以不一样，别硬凑成一个“统一指标”，凑出来的东西往往谁都不认，最后还得重算一遍。

几个容易被忽略的小坑

负载均衡后面挂两台机器，各自的流量计数是分开的，加起来才等于外网口的总量；NAT 会让内外网两侧的计数对不上；监控 agent 自己也要吃流量，虽然不多但确实存在；还有服务器时钟没对齐，跨机器对比曲线基本等于自欺欺人。这几个问题我踩过，排查了小半天才反应过来是两台机器各看各的网卡——那之后再也不敢只看一个数字下结论。

下次再有人拿着两个不一样的利用率来问你，先别急着怀疑工具。先问三句话：分母是物理口还是计费带宽，算的是出方向还是入方向，这段时间是怎么取的。三句问完，争论基本自己就散了。顺手把这三条写进你们的监控说明里，以后新同事上手也少绕一圈。