乐动体育安卓版产品视频

Honeycomb SLO特性演练

2020年6月12日

成绩单

丹耶尔·费舍尔[首席设计研究员]

我想演示一下Honeycomb的SLO功能。SLO代表服务水平目标。服务水平目标是描述您对系统可靠性的期望的一种方式。让我们从这个简单的测试数据集开始。它向我们展示了基于web的API服务的使用,并公开了许多不同的端点。对于每个请求,我们都要跟踪它需要多长时间才能得到服务。我们在上面写了一个SLO,它要求99.9%的请求在少于1100毫秒的时间内被解决,每7天。在左上角,我们可以看到我们实际上并没有使用任何接近的东西。我们可以通过查看我们看到的事件总数,并将其乘以我们的预期可靠性,来计算一个错误预算。

在这个数据集中,我们有82%的月预算剩余,所以我们做得很好。由于预算不会很快消耗殆尽,我们预计短期内预算也不会耗尽。但如果它燃烧得很快,右上角显示我们会收到警报,在它烧毁前四小时,足够我们跳进去,试图解决任何问题。从历史上看,我们的运行速度略高于99.98%。这个看起来很好。让我们来看看什么样的事件实际上对燃烧速度有贡献。这个热图视图帮助我们看到每一个符合SLO条件的事件。蓝色表示通过的事件,黄色表示失败的事件。最上面几行,持续时间大于1100毫秒的是这里所有的故障。从那里,我们可以进一步挖掘泡泡屋。 A BubbleUp is Honeycomb’s way of separating out what events are in the good, versus the bad regions and seeing how they’re different. In blue are the events that pass, in yellow are the ones that fail. This can help narrow down on what’s affected, what’s happening, and why.

BubbleUp为数据的每个维度绘制了一个柱状图。我们很快看到失败有一个非常特定的端点形状,它是API v2票据。当然,它们也有,因此,它们也有非常特定的名称和服务名称,因为它们在与失败服务的特定部分对话。现在我们知道发生了什么在这里,一个非常特定的端点花费的时间太长,但其他一切似乎都没有问题。更有趣的是,在用户ID列中,我们可以看到一个特定的用户,20109,体验不好。这很好,我们可以将此部分作为客户服务问题来处理,并与该用户联系。当然,作为工程师,我们还想知道是什么导致了这种情况。幸运的是,这个数据集用跟踪数据进行了注释,因此我们能够查看出什么地方出了问题以及如何出问题的实际跟踪。

下面是一些经历过失败的跟踪id的选择。我要抓取一个,然后进入它的轨迹。在跟踪中,我们可以看到,这个查询花了1.42秒。在下面,原因似乎是这个调用为导出获取票,它花了1.15秒。我们看看是什么占用了它,结果是29个不同的对MYSQL的串行请求,一次一个。现在,这些请求没有一个花了很长时间,但事实是我们做到了很多,这是相当令人惊讶的。这可能会让我们很好地知道在哪里调试,去寻找这个串行调用,并找出为什么它会连续运行这么多次。通过使用这个SLO和BubbleUp,我们可以看到问题有多严重,谁受到了影响,以及我们可以做些什么来修复它。在今天的生产中,Honeycomb使用了许多slo。乐动体育安卓版我想向你们展示一些说明SLO预算工作的不同方式的例子。

这是一个名为Retriever的内部工具的SLO。正如我们所看到的,它是在一个渐进的、缓慢的向下燃烧过程中,在一个稳定的状态下使用了大约三分之二的误差预算。我们可能会选择几个地方进行调查,但总的来说,我们已经超过了目标,而且看起来很舒服。偶尔会发生一些小错误,包括系统运行有点慢。在一个非常不同的模式中,我们一直在试验一个新的构建系统。我们一直在努力跟踪将CI构建时间保持在15分钟以下的频率。这里的曲线表明,几天前我们有过一些糟糕的经历,这些经历消耗了我们所有的预算,然后是一些。但是现在有了这条漂亮的水平线,情况似乎稳定了一点。希望,这意味着随着时间的推移,我们将开始重新设置并重新开始。最后,SLO子系统有自己的SLO。事实上,几天前我们发生了一起事故,我们花掉了很多预算。但现在我们回到了马厩。虽然我们的预算很低,但我们几乎没有超出预期水平。我们的稳态相当平稳,因此这里的警报没有警告我们,或者根本不担心。感谢您加入我的演示。

如果您在本文中看到任何打字错误或有任何问题,请联系marketing@honeycomb.io.

成绩单