2. 带宽容量治理核心指标

带宽容量治理的第一步不是扩容，而是把"网络到底够不够用"这件事量化。很多团队在收到业务方"网络慢"的反馈后，第一反应是升级实例规格或提高带宽上限，但真正的问题可能出在丢包、连接数耗尽或突发流量被限速。要避免这种盲目扩容，必须先建立一套可观测的指标体系，并基于 CloudWatch 数据形成稳定的性能基线。

一、六个核心指标的定义与区别

带宽（Bandwidth）是链路的理论最大传输能力，是一个容量上限，例如某 EC2 实例的基准带宽为 1.25 Gbps、突发带宽可达 5 Gbps。带宽是"管道有多粗"，它本身不随时间波动，只由实例类型、网络接口或链路规格决定。

吞吐量（Throughput）是单位时间内实际成功传输的数据量，通常以 Mbps 或 MB/s 表示。吞吐量永远小于等于带宽，它才是业务真正感受到的"速度"。当吞吐量长期贴近带宽上限时，说明链路已经饱和。

延迟（Latency）是数据包从源到目的地的往返时间（RTT），单位毫秒。延迟受物理距离、路由跳数、排队拥塞影响。跨可用区通常增加 1～2 ms，跨区域可能达到几十毫秒。延迟升高往往先于吞吐量下降出现，是拥塞的早期信号。

丢包率（Packet Loss）是发送但未成功到达的数据包比例。TCP 遇到丢包会触发重传和拥塞窗口收缩，导致吞吐量骤降。即使丢包率只有 1%，在高带宽链路上也可能造成明显的有效吞吐损失。丢包率是判断"链路是否健康"的关键指标。

连接数（Connections）包括活跃连接数（Active Connections）和新建连接数（New Connections）。NAT 网关、负载均衡器、代理层都有连接数上限，连接耗尽会直接表现为新请求失败，而带宽和吞吐量看起来却很正常。

突发容量（Burst Capacity）是实例或链路在短时间内超出基准带宽的额外传输能力，通常通过信用积分（CPU/网络信用）机制实现。突发额度耗尽后，性能会回落到基准带宽，表现为"平时很快、持续传输后突然变慢"。

二、CloudWatch 网络指标采集

AWS 将网络指标自动发布到 CloudWatch，无需额外安装代理。EC2 实例维度常用指标包括：NetworkIn、NetworkOut（字节数，需换算为 Mbps）、NetworkPacketsIn、NetworkPacketsOut。NAT 网关提供 ActiveConnectionCount、ConnectionAttemptCount、BytesInFromSource 等。ELB 提供 TargetResponseTime、SurgeQueueLength、RejectedConnectionCount。

采集时需要注意三点：第一，NetworkIn/Out 默认是 5 分钟粒度，若需精细分析可启用详细监控（1 分钟粒度），但会增加费用；第二，这些指标是字节累计值，需用 (后值 - 前值) × 8 / 时间间隔 换算为 Mbps；第三，CloudWatch 指标是采样统计，短时突发可能被平均掉，必要时结合 VPC Flow Logs 做包级分析。

# 将 NetworkOut 字节数换算为 Mbps（周期 300 秒）
Mbps = (NetworkOut_t2 - NetworkOut_t1) * 8 / 300 / 1_000_000

# 示例：t1=1,000,000,000 字节，t2=1,150,000,000 字节
Mbps = (150,000,000 * 8) / 300 / 1_000_000 = 4.0 Mbps

三、建立性能基线的实操方法

基线是"正常状态下指标应该落在什么范围"的参考线。没有基线，就无法判断当前数值是异常还是正常波动。建立基线建议按以下流程执行：

1. 选择观测窗口：至少覆盖一个完整业务周期，通常取 2～4 周，包含工作日高峰、周末低谷和一次大促或发布事件。
2. 提取统计量：对每个指标计算 P50、P95、P99 和最大值。P50 代表常态，P95/P99 代表高峰，最大值用于识别极端突发。
3. 设定阈值：以 P95 作为告警下限参考，以带宽上限的 70%～80% 作为容量预警线。例如基准带宽 1.25 Gbps，则吞吐量持续超过 1 Gbps 即应关注。
4. 标注事件：把发布、扩容、故障等事件标注在时间轴上，区分"业务增长导致的上升"和"异常导致的尖刺"。
5. 定期复核：业务量变化后基线会漂移，建议每月复核一次，避免用过时的基线误判。

下面这张图展示了从原始 CloudWatch 指标到基线判定，再到治理动作的完整信号链，帮助理解各指标之间的因果关系与判断路径。

四、从指标到判断：一个示例场景

假设某 EC2 实例基准带宽 1.25 Gbps，CloudWatch 显示 NetworkOut 在业务高峰持续达到 1.1 Gbps，同时 TargetResponseTime 从 80 ms 升至 220 ms，VPC Flow Logs 显示重传率约 0.8%。此时可以判断：吞吐量已接近基准带宽的 88%，延迟和丢包同步上升，说明链路接近饱和并出现排队。治理动作应优先考虑横向扩展（增加实例分摊流量）或升级到更高基准带宽的实例类型，而不是单纯调大应用超时时间。

反之，如果吞吐量只有 300 Mbps、延迟正常，但 ActiveConnectionCount 达到 NAT 网关上限的 90%，那么瓶颈在连接数而非带宽，扩容带宽无效，应优化连接复用或增加 NAT 网关。

五、基线维护清单