如何选择Apdex T:最后的单词

许多公司依赖应用性能监控(APM)工具，在应用出现可能影响客户体验的错误时发出警报。但要使这些警报有效，它们必须准确;也就是说，他们只需要注意对用户和业务有实际影响的真正性能问题。

如果将警报阈值设置得太低，将会出现大量错误警报，导致ops团队对警报系统失去信心。如果将警报阈值设置得太高，IT ops可能会忽略相关的性能降低，从而导致糟糕的用户体验。

在New Relic，我们用Apdex来解决这个复杂的警报问题。Apdex是衡量用户对应用程序或服务响应时间满意度的行业标准。与平均响应时间等传统指标相比，Apdex通过一个名为Apdex T的阈值来衡量应用程序的响应时间，从而更好地了解用户的满意度。

Apdex是如何工作的?

Apdex方法在0到1的统一尺度上将多个测量值转换为一个数字(0 =没有用户满意，1 =所有用户满意)。最终的Apdex分数是用户对企业应用程序性能满意度的一个数值度量。该指标可用于报告已定义了性能目标的最终用户性能度量的任何来源。

Apdex T是apdex的中心值——它是事务“可容忍”的响应时间。您可以为每个应用程序定义Apdex T值，分别为应用服务器和终端用户浏览器性能定义值。您还可以为关键事务定义单独的Apdex T阈值。

为什么需要覆盖默认的T阈值?

设置一个好的T值可以让你的Apdex分数更逼真，这样当性能变化时，分数也会相应变化。这对于检测性能概要文件中可能对用户体验产生正面或负面影响的更改非常重要。我只想说，有一个信号不是1或0的Apdex图表是很有帮助的。

当应用程序第一次开始报告数据时，New Relic为大多数代理选择500毫秒的默认T值(Python使用100毫秒)。但这并不是一个放之四海而皆准的值。默认值仅为20%的应用程序生成一个良好范围的分数。其余的需要覆盖默认值以获得一个好的分数。

我应该让T等于什么?

如果你有一个已经在稳定状态运行了一段时间的应用程序，你觉得你有一个良好的可接受的性能基线，你可以开始设置你的Apdex阈值，给你一个基线Apdex分数为0.95。因此，您需要获得第90百分位值并将其设置为Apdex T。

下面是实现此目的的NRQL查询:

select perentile (duration, 90) from Transaction where appId=NNNNN since 24 hours ago

0。95已经很高了。想要显示出更多的改进空间?试着把目标分数设为0.92或0.90。使用该表中与您想要的分数相对应的百分位数值。

我们是怎么得出这些值的

我们希望找到一个很好的“经验法则”来设置Apdex T，而不需要进行反复试验，不断调整值直到得分看起来正确为止。一旦应用程序运行了一段时间，它就会生成可用于估计T阈值的摘要统计信息。

我们发现的最精确的方法是建立一个HDR(高动态范围)直方图的历史数据，并执行一个简单的搜索，使用一个阈值范围优化目标分数和实际分数之间的误差。这是一个复杂的计算，手动去做，所以我们想找到一个更简单的方法。

很久以前我们写过用均值作为T值。但是如果你想要一个稳定的分数，使用平均值是无效的。均值可能会被异常值严重扭曲，导致T值的范围很宽，分数的可预测性更低。百分位数似乎更有活力。但事实确实如此吗?您应该使用哪一个呢?我们开始调查。

使用响应时间模型分布

我们决定使用模型分布来表示web事务的典型概率密度。有许多不同的分布形成了响应时间分布的理论拟合。日志正常是一个很有用的分布，因为计算很简单。但我们想要的是准确性，而不是简单性，所以Erlang分布给出了一个基于有a的排队网络的系统的较好近似泊松到达过程。我们将使用R函数来计算gamma分布的概率和分位数，它定义了形状值为正时的Erlang分布。

下面是一个分布示例:

模型分布图表

对于web事务的直方图，这是一个很好的近似。

计算Apdex评分

首先，我们创建了一个函数来计算Apdex分数和bucket计数。桶的值是标准化的，所以N = 1，而N通常是请求的数量。

apdex <- function(t, shape, scale) {buckets <- pgamma(c(t, 4*t)， shape=shape, scale=scale) # Score: list(Score =buckets[1] + (0.5 * (buckets[2] - buckets[1]))， s=buckets[1]， t=buckets[2] - buckets[1]， f=1 - buckets[2])}}

使用这个函数，我们可以创建模拟响应时间分布的图表，在柱状图/rug plot组合中显示结果分数。