代码之家  ›  专栏  ›  技术社区  ›  Cyril N.

基于自定义Cloudwatch报警的自动缩放规则

  •  0
  • Cyril N.  · 技术社区  · 3 年前

    我有一组自动扩展的EC2服务器,它们运行许多进程。 进程的数量会随着负载的变化而变化,我想根据进程的数量触发一个缩放(向上/向下)。

    我已经成功地设置了一个脚本,可以向Cloudwatch发送每台服务器上每分钟的进程数,我可以在Cloudwatch上看到这些。(我还没有设置维度,以便能够获得所有服务器的值)。

    然后,我创建了一个警报,它使用发送的值的平均值,如果达到某个限制,它会触发“添加新服务器”到自动缩放组,当它停止处于警报状态时,它会触发“删除服务器”。

    我的问题是,当我添加新服务器时,平均值会下降,因为现在又有一台服务器,它会将警报移动到ok状态,删除服务器,然后再次增加平均值,再次触发警报,等等。

    例如,限制设置为平均10个进程。对于3台服务器,如果平均值变为11,我会触发报警状态,添加一台服务器。现在有了新服务器,我在4台服务器上有33个进程(3 x 11):平均8,25个进程,因此触发了“OK”警报。

    我的问题是 :是否可以根据进程的数量设置警报,而不使用新的触发器导致上升下降问题?

    我可以使用其他东西来触发警报,而不是平均值,比如min/max/I-not-know。

    谢谢你的帮助。如有需要,乐意提供任何其他细节。

    1 回复  |  直到 3 年前
        1
  •  1
  •   John Rotenstein    3 年前

    你应该 创建一个报警,当为True时添加实例,当为False时删除实例。这将导致持续的“触发器”情况,而不是试图找到一个稳定的状态。

    您可以让每台服务器定期向Amazon CloudWatch发送一个自定义指标。然后你可以用这个 Target tracking scaling policies for Amazon EC2 Auto Scaling - Amazon EC2 Auto Scaling ,它将计算 平均值 并自动启动/终止实例,将目标值保持在10左右。

    这对于长时间运行的进程(可能是5分钟以上,多个进程同时运行)来说效果很好,但对于短时间的次分钟进程来说效果不佳,因为启动新实例需要时间。

        2
  •  1
  •   Marcin    3 年前

    metric math 。因此,您可以自己使用度量数学计算平均计数,而不是仅基于进程计数度量直接触发报警。你可以用 GroupTotalInstances 来自ASG的度量,或者只发布具有实例数的第二个自定义度量。

    在这两种情况下,警报的度量将使用度量数学将每个评估期的进程数除以ASG的大小。