是否有任何建议的最佳做法来监控容器的颠簸?我们所处的容器可能会尝试升起,并可能崩溃->重新启动数十次而没有任何人注意。但是,如此短暂的容器是“正常的”,因此跟踪此类异常似乎很困难(如果您的工作量真的只有30秒呢?)

我只是想知道是否有任何异常其他任何人都可以采用的“足够好”的警报做法来跟踪不正常的重启与正常的重启?

#1 楼

无论容器是否是临时容器,您都可以考虑以下两件事是不正常的:


非零退出代码
在业务流程层重新启动计数> 0

在编排层,提供程序和监视工具之间,如何警告这些指标将大相径庭。我将继续讨论有关原理:

非零退出代码

这似乎很明显。如果您的临时工作量很小,请确保它干净地退出,并且您将能够监视容器的运行状况。即使您短暂的工作量持续了30秒,并且您启动了数千次工作(小型的短命工人风格),只要一切顺利进行,也不必担心。

在业务流程层重新启动计数

大多数业务流程层都会公开重新启动计数。对于Kubernetes,在描述Pod时,这实际上是``重新启动计数''指标。这些重新启动是业务流程层重新启动容器,因为它本来不应该处于“已停止”状态。临时工作负载由于其本身的性质而不会具有重新启动计数(或者,如果确实如此,则完成工作负载后容器的“最终”关闭将不会导致重新启动)。

您是否要在重新启动次数超过某个阈值时立即发出警报,还是要更聪明地计算速率(大致:重新启动次数/ pod /服务持续时间),取决于您。

评论


您是否知道ECS是否显示了重启计数指标?

– MrDuk
19年5月22日在21:25

不能通过CloudWatch(很遗憾),但是可以,即使需要一点点信息,也可以使用此信息。 ECS中的“服务”和“任务”抽象都为您提供了深刻的信息。服务:事件和失败任务:healthStatus和失败。 docs.aws.amazon.com/AmazonECS/latest/developerguide/…页面为您提供了有关如何流式传输ECS事件的更多信息,以便您可以自动使用它们。对于它的价值,我过去曾经亲自使用过Prometheus ECS Exporter,并且一直在警告它所暴露的指标。

–亚历山大
19年5月23日在0:34