分析超越均值的尾延迟离群点

目标

均值恰好掩盖了用户记住的那些请求：数千次 80 毫秒的页面浏览里那笔耗时 4 秒的结账。把原始样本排序并切分位数能揭示痛苦的形状；再把最差的一桶按实例、端点与时间分组，就能区分慢副本、慢查询与定时任务冲突——三者的负责团队与修法完全不同。

步骤要点

1. 从 JSONL 指标里导出“延迟、实例、端点”三元组为 TSV 并按延迟排序。
2. 用 awk 在排序数组上切分位：p50 82ms、p99 1900ms、p999 4200ms，中位数健康而尾巴差二十倍。
3. 取最顶部 1% 样本按实例分组计数：某实例独占大头即是慢副本而非代码问题。
4. 同一桶再按端点分组：某端点主导尾巴则指向具体慢查询或锁竞争。
5. 分析离群点的时间间隔规律：每 60 秒一次的规律性指向 cron 任务或缓存过期，而非随机噪声。

排错提示

样本量撑不起 P99.9 就先降到 P99 或拉长窗口，几百个样本算出的 P99.9 是虚构；尾巴在所有维度上都平摊说明原因是共享且外部的（GC 停顿、磁盘争用），下一步查离群时间点的主机级指标；离群点聚在整数秒附近要怀疑上游固定超时后又有东西在重试。

适用边界

分位数描述分布而不能解释任何单个请求，解释具体离群点仍需调用链追踪；聚合过的均值会永久摧毁尾巴信息，只有原始样本支持这种分析。

代码示例

# Percentiles from raw samples
jq -r '[.latency_ms, .instance, .endpoint] | @tsv' metrics.jsonl | sort -n > samples.tsv
awk -F'\t' '{a[NR]=$1} END {print "p50", a[int(NR*0.5)], \
  "p99", a[int(NR*0.99)], "p999", a[int(NR*0.999)]}' samples.tsv