html如何使用 CloudWatch 监控 EFS 爆发积分 — Bernd Kuhlen
BK BERND KUHLEN所有笔记 ↗
← 返回实地笔记

如何使用 CloudWatch 监控 EFS 突发积分

单个低余额警报不足以很好地监控 EFS 文件系统。它可以警告跑道尽头已近,但它不能解释平衡下降的原因,跑道消耗的速度有多快,也无法解释用户是否已经感受到了这种影响。

有用的 EFS 仪表板将容量、需求和应用程序影响联系起来。

建立背景的五个指标

  • BurstCreditBalance 显示了使用突增吞吐量为文件系统预留的剩余突增积分。
  • MeteredIOBytes 表示用于 EFS 吞吐量核算的计量吞吐量。
  • PermittedThroughput 显示文件系统当前允许驱动多少吞吐量。
  • TotalIOBytes,以及读取、写入和元数据指标,显示了实际执行的工作。
  • PercentIOLimit 显示接近通用性能模式的 I/O 限制。

最具启发性的视图通常不是任何单一的图表,而是它们之间的关系。当计量需求反复接近允许的吞吐量而突增积分呈下降趋势时,工作负载会消耗临时余量。

分层构建仪表板

第 1 层:剩余跑道

图表 BurstCreditBalance 至少超过 30 天。较短的时间范围掩盖了缓慢的消耗。使用最小统计数据来显示每个周期内达到的最低余额,并添加第二个范围更长的视图以进行趋势分析。

第 2 层:需求与许可

图表 MeteredIOBytes 和 PermittedThroughput 具有兼容的时间段和单位。AWS 指出,当计量吞吐量等于允许的吞吐量时,文件系统将消耗所有当前可用的吞吐量。

第 3 层:工作负载构成

将数据读取、数据写入和元数据操作分开。即使聚合字节数看起来相似,由小型元数据操作主导的工作负载的行为也可能与顺序数据传输工作负载不同。

第 4 层:服务影响

添加应用程序请求延迟、超时率、工作线程饱和度和主机 I/O 等待时间。当基础设施指标能够与用户可见的效果保持一致时,它们就会变得有用。

对趋势发出警报,不仅是零

固定的低平衡警报器仍然很有价值,但它应该是最后的护栏。较早的检测可以使用多个警告级别和持续耗尽信号。例如:

  1. 当平衡低于特定环境的跑道阈值时发出警告。
  2. 当余额在多个评估期内持续下降时升级。
  3. 当计量吞吐量仍接近允许的吞吐量时发出警报。
  4. 与延迟增加或超时相关联,以区分容量风险和活动事件。

没有全民信贷门槛,因为有意义的价值取决于消费率。在繁重的工作负载下,较大的天平只能代表几个小时,而对于安静的系统,较小的天平可能保持稳定。

将警报变成运营决策

运行手册应列出以下问题:需求是暂时性的吗?标准存储占地面积缩小了吗?部署是否会产生异常的元数据流量?弹性吞吐量能更好地匹配不可预测的工作负载吗?稳定的已知要求是否可以证明预置吞吐量是合理的?

没有这种决策背景的警报只会将不确定性从仪表板传递给待命工程师。良好的可观测性使容量模型在寻呼机启动之前可见。

官方参考文献

BERND KUHLEN · 云工程实地笔记
ZH
EnglishENDeutschDEEspañolES中文ZH