云 / 系统
只设一条积分余额过低告警，还不足以看清 EFS 的运行情况。它能提醒余量快用完了，却解释不了余额为什么下降、还能支撑多久，以及用户是否已经受到影响。
有用的 EFS 仪表盘，要把剩余容量、实际需求和应用表现放在一起看。
建立判断依据的五个指标
BurstCreditBalance表示突发吞吐量模式下，文件系统剩余的突发积分。MeteredIOBytes表示 EFS 用于吞吐量计量的数值。PermittedThroughput表示文件系统当前允许使用的吞吐量。TotalIOBytes以及读取、写入和元数据指标，可以看出实际执行了哪些操作。PercentIOLimit表示通用性能模式下，I/O 限制的使用情况。
最有价值的往往不是某一张图，而是图与图之间的关系。计量吞吐量反复接近允许上限，同时积分余额持续下降，说明负载正在消耗临时余量。
分层构建仪表板
第一层：余量还能维持多久
绘制 BurstCreditBalance 的至少 30 天趋势。时间太短，就容易看不见缓慢的消耗。使用 Minimum 统计值，查看每个周期的最低余额，再补一个跨度更长的趋势视图。
第二层：需求与允许上限
绘制 MeteredIOBytes 和 PermittedThroughput 并采用一致的周期和单位。AWS 文档指出，计量吞吐量等于允许吞吐量时，文件系统已用满当前可用的吞吐量。
第三层：负载由什么组成
把读取、写入与元数据操作分开看。即使总字节数相近，以小型元数据操作为主的负载，与顺序传输大文件的表现也可能很不一样。
第四层：应用受到什么影响
加入请求延迟、超时率、工作线程饱和度和主机 I/O 等待。基础设施指标只有与用户感受到的变化联系起来，才更容易指导行动。
不要等余额归零，先看趋势
固定的低余额告警仍有价值，但更适合作为最后一道防线。想尽早发现问题，可以设置多级阈值，并结合持续消耗趋势，例如：
- 余额低于本环境设定的可支撑时间阈值时，发出预警。
- 多个评估周期内持续下降时，提高告警级别。
- 计量吞吐量持续接近允许上限时，触发告警。
- 结合延迟和超时变化，判断是潜在容量风险，还是已经影响服务的故障。
没有适用于所有环境的积分阈值，关键在于消耗速度。高负载下，看似很大的余额也许只能撑几小时；较低的余额在安静的系统里反而可能长期稳定。
让告警能够支持运维决策
操作手册应帮助值班人员判断：需求只是短期增加吗？Standard 存储量是否减少？某次部署是否带来了异常的元数据请求？不可预测的负载是否更适合弹性吞吐量？稳定的持续需求是否值得采用预置吞吐量？
没有这些背景，告警只是把仪表盘上的不确定性交给值班工程师。好的可观测性，应在呼叫值班人员之前，就让容量问题有迹可循。