用于加快 ECS 扩展的 AWS 高分辨率指标

Posted 2023-03-04

【中文标题】用于加快 ECS 扩展的 AWS 高分辨率指标

【英文标题】：AWS High Resolution Metrics for faster ECS scaling

【发布时间】：2020-11-27 16:24:51

【问题描述】：

我在 AWS ECS 中部署了一个复杂的 REST API。相同的自动缩放策略基于 2000 的 RequestCount。

当 RequestCount 以每 60 秒的标准分辨率持续高于 2000 时，将发生横向扩展。这至少需要 2 分钟才能进行缩放。当请求计数增加到 10k 及以上时，这将成为短期请求激增的问题。容器开始拒绝请求（限制）。

如果不是在几秒钟内，我至少需要在一分钟内更快地进行缩放。 AWS CloudWatch 似乎提供了高分辨率指标，但关于以下方面的信息却非常少：

我可以启用高分辨率的特定指标吗？是否可以以 5 秒的高粒度解析请求计数，并以 1 分钟的标准粒度解析 CPUUtilization？

如何在 AWS 指标上启用高分辨率？

AWS CloudWatch Documentation 似乎不足以理解这个过程。

【问题讨论】：

放下 CloudWatch 并服用 Promstack 药丸。 Grafana + Prometheus 用于初学者，Grafana + Prometheus（或 VictoriaMetrics 用于不同的查询语言）+ 远程存储，用于像 Thanos 或 Cortex 这样的规模。

【参考方案1】：

有两种不同的东西可以是“高分辨率”，警报和指标。

高分辨率指标仅表示来源更频繁地推送值。如果您使用 AWS 指标，您将无法控制这一点，而且大多数指标的推送频率不会超过每分钟一次。

高分辨率警报是一种周期小于 60 秒的警报，其计费率高于标准警报。但是，如果您所基于的指标每分钟只推送一次，这在大多数情况下并不是很有用

编辑： 直接回答你的问题

不，我认为 ELB 之类的任何 AWS RequestCount 指标都没有“高分辨率开/关”切换（尽管默认情况下，ELB 的推送频率可能超过 1 分钟，但我不确定） 它基于源将数据点推送到 cloudwatch 的频率。如果 AWS 指标不能满足您的需求，您需要添加类似 CloudWatch 代理（或只是您的实例中的脚本）之类的东西，以更频繁地推送指标。不过，如果您从很多来源高频次执行此操作，请注意 CloudWatch API 调用费用