大文件下载业务的带宽监控，核心就抓三层指标：链路层的带宽利用率和峰值带宽、业务层的并发连接数和吞吐量、质量层的丢包率和重传率，其中95计费带宽决定成本，并发连接数决定用户体验，二者必须同时盯住。
大文件下载带宽监控指标有哪些？先分清三层监控对象
很多团队一上来就盯着网卡流量看,结果下载业务被投诉慢，自己却一脸懵，大文件下载场景和普通网页浏览不一样，一个用户可能占住几十兆带宽持续几分钟，几百个用户同时下安装包或镜像文件，带宽曲线会拉出很长的平台期，监控指标如果只看平均值，基本等于没看。
链路层：带宽利用率和峰值带宽是最基础指标
带宽利用率就是当前实际使用的带宽除以总可用带宽,这个指标在监控大盘上通常是一条曲线，低于30%说明资源大量闲置，高于80%持续一段时间就要准备扩容或分流，但大文件下载业务有个特点：峰值带宽出现的时间相对集中，比如版本发布后的头两个小时、工作日上午的软件更新窗口，峰值带宽不是坏东西，它代表业务确实在跑，但如果峰值带宽长期顶满物理链路，TCP重传和连接超时就会开始冒头。
查看链路层指标,最直接的方式是在Linux服务器上执行sar -n DEV 1，每秒输出一次网卡收发字节数和包数，或者用vnstat -l看实时速率，这些命令输出的是原始计数器，监控系统需要做差值计算才能得到带宽值，物理网卡带宽可以在ethtool eth0里确认，千兆网卡显示1000Mb/s，万兆显示10000Mb/s，别拿错基准。
业务层：并发下载连接数和吞吐量直接反映用户体验
带宽利用率再高,如果并发连接数很低，可能只是单个大客户在拉文件，体验未必差，反过来，带宽利用率不高但并发连接数激增，每个用户分到的带宽会被摊薄，大文件下载业务的并发连接数需要和文件大小、用户平均下载时长放在一起看，一个2GB的客户端安装包，用户用10MB/s下载大约需要200秒，如果同时有500个这样的连接，理论吞吐量就是500×10MB/s=5GB/s，折合40Gb/s，这已经超出多数单机房出口能力。
吞吐量可以用sar -n DEV里的rxkB/s和txkB/s换算，也可以直接看/proc/net/dev的累计字节数，并发连接数在下载服务器上通常用ss -s查看TCP连接总数，或者ss -tan state established | grep :443 | wc -l统计某个端口的已建立连接，这两个数字要放在同一张图里，才能看出“带宽被谁占着”。
质量层：丢包率、时延和重传率决定下载完成率
大文件下载最怕的不是慢,是下到90%断掉重来，丢包率直接影响TCP重传，重传多了下载速度会被拥塞控制算法腰斩，质量层指标包括网卡丢包数、TCP重传统计、平均时延和抖动，丢包数和重传率可以通过
netstat -s或ss -ti查看，tc -s qdisc show能看到队列丢包情况，这些指标如果出现毛刺，多半是物理链路或交换机端口出了问题，而不是业务本身。
很多监控系统把丢包率阈值设在0.1%，但对大文件下载来说，0.1%的丢包在长连接里会被放大，一个1GB文件分片传输，丢一个包就要重传整个窗口，实际体验可能下降20%以上，所以大文件下载业务的质量监控阈值通常比普通Web业务更严格。
下载业务带宽峰值监控：为什么95计费比平均带宽更关键
带宽平均利用率看起来不高,月底账单却高得吓人，这是大文件下载业务的常见困惑，原因在于IDC和云厂商多数按95计费带宽出账，不是按平均值，所谓95计费，是把一个计费周期内每5分钟采样的带宽值从高到低排序，去掉最高的5%，取剩下的最高值作为计费带宽，也就是说，哪怕只有几小时峰值飙到10G，其他时间都只有1G，只要那5%的采样点覆盖了峰值，账单可能就按接近10G算。
95计费带宽的监控逻辑
监控95计费带宽不能只看实时曲线,要把采样点记录下来，按天或按月统计P95，开源监控里可以用Prometheus的quantile_over_time(0.95, bandwidth_usage[30d])计算，或者把数据导出到ClickHouse里用SQL做百分位统计，关键是采样精度要和云厂商的计费粒度一致，云厂商通常5分钟采样一次，如果你只存1小时平均，算出来的95和账单对不上。
突发流量和峰值带宽的差值要单独监控
大文件下载业务经常出现“尖刺型”流量，比如某个热门资源被大量请求，持续5到10分钟后就回落，这种尖刺对用户体验影响不大，但对95计费影响很大，监控时要把峰值带宽和95计费带宽放在一起对比，如果差值超过总带宽的30%，说明突发流量已经实质性推高成本，这时候应该考虑把大文件分发切到CDN边缘节点，或者用对象存储直连下载，避免回源带宽被尖刺拉高。
大文件下载服务器带宽怎么计算与监控阈值设定
带宽监控指标只有和预期值对比才有意义,算清楚服务器需要多少带宽，才能设对告警阈值。
按文件大小和并发用户数估算基础带宽
假设一个安装包文件大小是1.5GB，目标用户的平均下载速度是8MB/s，下载完成时间大约192秒，如果预期同一时刻有100个并发下载，基础带宽就是100×8MB/s=800MB/s，折合6.4Gb/s，实际还要乘以1.2到1.5的冗余系数，因为TCP慢启动、用户暂停、网络波动都会让实际吞吐低于理论峰值，这个估算方法在IDC托管和自建CDN回源场景都适用。
监控阈值可以基于这个估算值来设：利用率超过估算带宽的70%发提醒，超过85%发告警，超过95%必须介入限流或扩容，下载业务的告警阈值不适合设得太敏感，比如60%就报警，那运维会被夜间版本发布吵醒，时间长了告警就没人看。
分级告警阈值怎样设置才不误报
告警策略要和时间维度绑定,大文件下载有周期性，工作日白天和版本发布日带宽会高，凌晨和节假日会低，如果用一个固定阈值，要么白天频繁误报，要么夜间出问题不响，更合理的方式是按时间分时段设置阈值，比如工作日上午9点到下午6点用一套阈值，其他时间用另一套，突发流量告警可以设置连续3个采样点超标才触发，避免单点抖动。
大文件下载CDN带宽成本优化：监控指标如何落地
很多大文件下载业务会接CDN,监控指标如果还停留在源站带宽，成本优化就是一句空话。
回源带宽和边缘命中率必须同时看
CDN边缘节点缓存命中率直接影响回源带宽,命中率高，用户请求在边缘就被响应，源站带宽消耗低；命中率低，大部分请求回源，源站带宽成本上升，监控时要在CDN控制台看命中率、回源流量、边缘流量三个指标，回源带宽的计费方式和边缘带宽不同，通常回源单价更高，所以回源带宽占总带宽的比例越低越好，如果发现边缘流量很高但回源带宽也高，多半是缓存策略有问题，比如大文件设置了不缓存或缓存时间过短。
分区域带宽监控让成本分摊更清晰
大文件下载业务的用户分布往往不均衡,一线城市和运营商网络带宽成本差异明显，监控时可以按地域和运营商维度拆分带宽，比如华东电信、华南移动、海外区域分别看峰值带宽和95计费带宽，这样做不是为了炫技，而是为了找到成本大头，如果某个区域带宽持续偏高但用户活跃度低，可能是有盗链或异常下载，需要单独拉清单排查。
常见监控工具与指标采集路径对比
监控指标要靠工具采集,不同工具有不同适用场景。
| 采集方式 | 适合场景 | 能拿到的指标 | 常见工具 |
|---|---|---|---|
| SNMP | 交换机和路由器端口流量 | 端口入出带宽、丢包计数 | Zabbix、Cacti |
| NetFlow/sFlow | 流量流向分析 | 源目IP、端口、协议带宽 | ntopng、ElastiFlow |
| 主机API/命令 | 服务器网卡和业务指标 | 并发连接数、TCP重传、吞吐量 | Prometheus、Telegraf |
SNMP、NetFlow和API三种采集方式怎么选
SNMP适合看物理链路和交换机端口,不用登录服务器就能拿到端口带宽，NetFlow适合分析带宽被哪些IP和协议占用，排查异常流量时特别好用，主机API和命令采集最灵活，可以拿到TCP层面的并发连接数、重传率这些业务质量指标，大文件下载业务建议三者搭配：SNMP看链路，NetFlow看流向，主机API看业务质量。
开源工具和商业工具的场景化选择
开源组合如Prometheus+node_exporter+snmp_exporter可以覆盖大部分需求，成本低，但需要自己维护规则和存储，商业监控如Datadog、New Relic、简米云云监控自带大盘和告警模板，开箱即用，但按指标量收费，大文件下载业务如果实例多，成本会上升，中小团队可以从开源开始，先把链路利用率和并发连接数接进来，再逐步补质量层指标。
把监控指标落到告警策略上,才能真正守住大文件下载业务的带宽成本与体验底线，带宽利用率告诉你资源够不够，95计费带宽告诉你账单高不高，并发连接数和重传率告诉你用户会不会骂人。
Q&A：大文件下载带宽监控指标有哪些常见疑问
大文件下载速度慢原因排查该看哪些带宽监控指标？
先看并发连接数和带宽利用率,如果带宽利用率已经接近物理上限，说明出口带宽不足，需要扩容或分流，如果带宽利用率不高但用户仍反馈慢，再看TCP重传率和丢包率，这两个指标能定位是不是链路质量问题，最后看单个连接的平均吞吐，用ss -ti查看每个TCP连接的窗口和RTT，窗口小或RTT高会直接拖慢下载速度。
企业大文件下载带宽监控指标有哪些容易遗漏？
最容易遗漏的是95计费带宽和回源带宽,多数团队只盯着实时带宽利用率和平均带宽，月底看到账单才发现峰值被计了高费，回源带宽在CDN场景下尤其容易被忽略，因为它藏在CDN厂商的后台报表里，不和源站网卡直接对应，另一个遗漏点是TCP重传率，普通监控系统默认不采集，但大文件下载对丢包极其敏感。
下载业务带宽峰值监控和95计费带宽有什么区别？
带宽峰值监控关注的是瞬时最大值,用来判断物理链路是否被打满，属于容量管理范畴，95计费带宽是计费周期内采样值排序后去掉最高5%取的值，用来估算成本，属于成本管理范畴，峰值可能只持续几秒，但95计费带宽取决于5分钟采样点的分布，一个短暂的10G尖刺可能不会显著影响95计费，但连续30分钟的9G流量就会让账单明显上升，两者必须分开监控，不能拿峰值带宽直接推算账单。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/664737.html
