3月11日,周四,我们经历了~ 2小时停机Grafana云在美国中央地区举办普罗米修斯服务。我们的客户受到这一事件的影响,我们真诚道歉。我们的工作就是为你提供你需要的监视工具,简单地说,当他们不在时,我们让你的生活更加困难。
我们非常重视这个停机。相当多的评论事件后,我们一起把这篇博客来解释发生了什么,我们如何回应它,和我们所做的,以确保它不会再发生。
背景
我们运行~ 15大集群Grafana企业指标(GEM)在世界各地各种Kubernetes集群。这些集群是多租户;他们之间安全地共享许多用户Grafana云使用数据和性能隔离特性的宝石。
特别是,我们限制多少数据任何单一租户可以发送到集群和多快可以发送的数据。这些限制是为了保护其他租户和集群作为一个整体从集群的可能性得到“超载”,如果一个租户过快写道。集群配置/大小根据这些限制,等等。
这一事件
周三,3月10日,我们在一个新客户作为我们的一个租户美国中央宝石集群。我们增加了他们积极系列基于预测的使用限制。第二天,新房客开始发送更多的数据比预期的,不知道他们。这个客户应该保护的配置限制集群。然而,一个错误在限制是如何执行意味着租户能够压倒集群,这不是他们自己的错。
这过载引起的级联故障整个堆栈。我们发现我们的错误处理路径更昂贵(CPU-wise)比我们的成功路径。我们的内部认证网关成为超载和失败的他们的健康检查,随后导致我们的负载平衡器从池中删除它们。
最初我们扩大集群试图应对负载,但随着许多普罗米修斯服务器将数据发送到美国开始恢复,随后一波又一波的负载引起的一系列内存不足错误(OOMs)和其他故障整个堆栈。
然后我们确认客户是导致过载,甚至更严格的限制,客户的使用情况,并继续扩大集群,直到它可以处理恢复负载。一旦新的租户限制被强加,集群自动恢复,没有额外的干预。服务被3月11日23:46 UTC完全恢复。
随后我们确认和固定底层错误3月12日。
我们已经学会了和改善
这是至关重要的,我们从这里学到停机和实施必要的修改,以确保它不会再发生。这些是我们正在采取的具体步骤:
限制处理方式的变化已经恢复并部署(见https://github.com/cortexproject/cortex/pull/3948)。此外,新的限制被介绍给添加多个层的保护(见https://github.com/cortexproject/cortex/pull/3992)。结合在一起,这两个变化将防止个别客户能够压倒集群和任何未来的错误干扰限制的实现。
工程团队改善我们的基本限制管理,引入更严格的限制和更多的自动化管理的限制。我们也改善集群扩展的管理和配置,使过程更加自动化。这应该确保我们永远不会进入一个单一租户可能会压垮一个集群。
我们重建过程中的过载场景在我们的开发环境和调查方法,以确保整个堆栈失败更多的预测(例如,通过拒绝API调用,而不是崩溃)。在不太可能的情况下,一个类似的问题,这将使我们能够恢复得更快。
我们也投资于事件反应训练和自动化来提高我们的响应时间。我们希望这些调查和结果的变化在接下来的六周内应用。
最后,我们在继续与更广泛的社区工作改善的行为普罗米修斯停机后当回放数据。
