stats/bw如何看IPFS带宽？

节点出口突然升高，可能是正常取块、内容提供、DHT活动或异常重试。只看网卡总流量无法区分IPFS内部用途，Kubo stats bw提供了更靠近libp2p的计数与速率。但它仍只是传输层证据，不能单独代表用户内容请求成功。

四个指标分成存量和流量

ipfs stats bw显示TotalIn、TotalOut、RateIn和RateOut，可使用poll与interval连续输出。

TotalIn与TotalOut是累计字节量，适合两个采样点相减；RateIn与RateOut是当前或近期速率，适合观察即时变化。poll与interval可连续输出，采集器要记录真实时间戳，不能假设每行恰好间隔固定秒数。

单位必须从接口原始语义统一到监控系统，再在UI转换。看板标明bytes/s或其他实际单位，避免营销页面常见的bit与byte混用。

peer与proto筛选不能同时使用，可分别定位单个peer或协议的带宽。

peer筛选用于调查单个对端，proto筛选用于观察某类协议。两者不能同时使用，因此需要分别采集，不能声称一次请求获得“某peer在某protocol”的标准交叉结果。需要更细粒度时应使用额外观测工具并说明来源。

日常监控保留全局序列即可，只有异常时针对少量peer或协议临时细查。长期对所有peer高频轮询会产生高基数标签，增加存储与隐私风险。对外工单应隐藏完整peer地址。

TotalIn和TotalOut是累计量，RateIn和RateOut是速率；节点重启或采样窗口变化会改变比较基线。

累计值下降时先检查进程启动时间和采集连续性，不要计算成巨大负流量。时间序列为每次启动分配boot ID，差值只在同一实例内进行；缺采样时标记数据空洞，不用直线插值伪造带宽。

Rate值还可能受平滑窗口和版本变化影响。升级前后保存Kubo与libp2p版本，避免把算法调整解释成真实业务流量变化。容量规划更应使用累计增量复算，而非只对Rate曲线求和。

网络流量测量不能单独证明内容可用性或用户请求成功，应与连接、Bitswap和应用日志联合。

高流量可能是热门内容成功分发，也可能是重复块、无效请求或重试风暴；低流量可能是空闲，也可能是连接断开。联查swarm/peers、bitswap/stat、网关状态码和目标CID读取耗时，才能确定业务意义。

例如RateOut很高且网关成功率也高，可能是正常服务增长；RateOut高但成功率低，需要查响应体、超时与重复传输；RateOut骤降且连接数同步归零，则更像网络层事故。结论必须来自多指标一致。

容量告警比较长期95分位与出口上限；异常告警寻找短期突变和入出不对称；业务告警绑定用户请求失败率。三档分别有不同时间窗口和处置人。不要用“超过100 MB/s”同时承担成本、攻击与可用性判断。

告警通知附当前速率、窗口累计、历史基线、连接数、Bitswap重复量和应用错误。处置后按相同窗口复测，避免只因瞬时曲线回落就关闭事故。

日报保留节点、boot ID、首末累计值、有效采样时长、入出增量、峰值与分位数、主要协议变化和异常解释。成本估算另行结合云厂商计费口径，因为Kubo观察到的协议流量不必等于供应商最终计费字节。

累计量、速率、peer和协议维度应被放进时间序列，再与连接、Bitswap和应用请求联查。只有这样，带宽看板才从漂亮曲线变成排障工具。

文中的接口边界以Kubo CLI stats bw、Kubo RPC stats bw、Measuring the IPFS network公开材料为准。

当前不能越过的事实边界是：速率平滑算法与协议标签会随Kubo/libp2p版本变化，监控需保留版本。

相关背景可继续查看getnettotals、repo/stat、getHealth。接口、客户端与网络状态会随时间变化，本文不构成投资、交易或收益建议。