如何汇总SLO服务质量目标
本帖最后由 FYIRH 于 2020-12-4 16:59 编辑为了简化和使数据更可用，我们经常需要汇总原始度量数据。汇总过程应该非常小心。
某些指标的汇总看起来是很简单的，例如每秒服务请求的数量，但是即使这种简单度量也需要在某个度量时间范围内进行汇总。该度量值是应该每秒获取一次，还是每分钟内的平均值?后者可能会掩盖仅仅持续几秒的一次请求峰值。假设某个系统在偶数秒处理200个请求，在其他时间请求为0。该服务与持续每秒处理 100个请求的服务平均负载是一样的，但是在即时负载上却是两倍。同样的，平均请求延迟可能看起来很简单，但是却掩盖了一个重要的细节;很可能大部分请求都是很快的，但是长尾请求速度却很慢。
大部分指标都应该以"分布"，而不是平均值来定义。例如，针对某个延迟 SLI，某些请求可能很快，其他的可能会很慢，有时候会非常慢。简单平均可能会掩盖长尾延迟和其中的变化。图4-1提供了一个例子∶虽然常见请求可以在50ms完成，但5%的请求却慢了20 倍!针对平均值的监控和报警将不会发现任何改变，但是服务的确在长尾延迟上出现了巨大变化（图中最上面的那条线）。
图4-1∶某系统的50%、85%、95%、99%的请求延迟，注意这里的Y轴是指数级分布的。
利用百分位指标可以帮助我们关注该指标的分布性∶高百分位，例如99% 和99.9% 体现了指标的最差情况，而50% 则体现了普遍情况（99%百分位是指在原始数据中99%的数值都满足某种条件。例如请求延迟的99%为100ms指的是，在所有请求中，99%的请求延迟都小于100ms）。响应时间的分布越分散，意味着普通用户受到长尾请求延迟的影响就越明显，这可能预示了负载过高情况下出现的排队问题。用户研究显示，用户通常更喜欢速度较慢的系统，而不是一个请求速度抖动很厉害的系统，所以，某些 SRE 团队只关注长尾部分，因为如果 99.9%的系统行为都正常的话，那 50%部分就肯定也是正常的。
关于统计性谬误一般来说，SRE更倾向于分析一组数据的百分比分布，而非其算术平均值。长尾效应比算术平均值更有特点，使用百分比分布能够更清晰地进行分析。因为计算机系统的本身特质决定，数据是具有特定分布特点的——例如，请求延迟必须大于0，同时如果超时设置为 1000ms，则不可能有成功请求超过这个时间。因此，我们不能假设算术平均值和中位数是相等的——它们甚至可能相差甚远!
我们同时也不会假设数据是平均分配的，一切都必须经过验证。某些常见的直觉感觉和近似方法在这里并不适用。例如，如果分布情况和假设不一致，那么根据这个假设做出的操作就有可能频率过高，或者频率过低（例如根据请求延迟将过高的服务器自动重启）。
页:
[1]