如何根据 SLA 得出 Apdex 阈值？

Question

我们有一个可用的 REST API。对于此 API 提供的每个端点，我们都有一个基于内部测试的定义的 SLA。 New Relic 提供了基于每个应用程序定义 Apdex T 分数的选项。考虑如下场景：

• 端点 A：SLA 为 200 毫秒
• 端点 B：SLA 为 800 毫秒

• 平均 SLA：500 毫秒

  案例 1：考虑 Apdex 阈值的平均 SLA 这种方法的问题是，即使我的端点 A 预计将在 200 毫秒内完成，即使端点花费了 SLA 中定义的时间的两倍，它也不会被标记，因为它仍然小于平均值。端点 B 的情况反之亦然，即使它低于 800 毫秒也会被标记。

  案例 2：将所有端点的最大 SLA(800ms) 视为 Apdex T 值 问题再次出现在端点 A 上。即使是实际预期时间的 4 倍，也不会标记来自该端点的任何响应延迟。

那么，在这种情况下，我们如何得出 Apdex 阈值？ 我浏览了 New relic 的以下文章：LINK。当我们将服务视为一个整体时，这是有道理的，但在我们查看每个端点时却不是。

Answer 1

您确定要根据您的 SLA 设置 Apdex 吗？

我建议应用程序的典型性能是更好的指标。假设在过去 7 天内，您的应用程序是否具有平均性能。但是，在“如何设置 Apdex T”中，文章建议使用百分位数来表示您的典型表现。

因此，如果您获得第 90 个百分位数，则通常会产生接近 0.95 的 Apdex 分数。显然 Apdex 为 1 是无用的，因为您没有将帐户保持在足够接近的帐户。所以我会单独询问 Insights

select percentile(duration, 90) from Transaction where appName="AppA" since 7 days ago

select percentile(duration, 90) from Transaction where appName="AppB" since 7 days ago

这将使您获得比 90% 的客户更好的响应时间。因此，对于您的 Apdex T 值，这应该是一个很好的粗略指南。

但是，如果您的目标是在 SLA 为 200 毫秒的应用程序 A 上，并且任何超过该时间的事务都应该是 Apdex 分数的 0 分。那么很简单，您的 Apdex T 应该是 50 毫秒。因为快于 50 毫秒的任何东西都得到 1 分，所以 Apdex T 和 4 x Apdex T 之间的任何东西都得到 0.5 分，但至少仍然得分。任何慢于 4 x Apdex T（在这种情况下为 200 毫秒）的东西都将在 Apdex 上获得 0 分。因此，如果交易违反了 SLA，这会给您标记为 Apdex 受挫的交易。

Apdex 是一门艺术，但您绝对可以使用上述任何一种方法到达您需要的地方。我希望我涵盖了我认为在这种情况下可能出现的两种情况。