0

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

  • 端点 A：SLA 为 200ms
  • 端点 B：SLA 为 800ms

  • 平均 SLA：500 毫秒

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

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

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

4

1 回答 1

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 值，这应该是一个很好的粗略指南。

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

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

于 2019-07-24T14:22:17.283 回答