P99 到底是按请求算还是按 trace 算：同一接口两个团队报出的 P99 能差 3 倍，谁的口径算「对」？

【背景】 我在做指标体系时反复撞上一堵墙：同一个网关接口，业务方看板上的 P99 是 180ms，中间件团队的看板是 520ms，两边数据都「没坏」，但根本对不上。拆开看才发现是口径差异——业务方按「进入网关的单次请求」算分位，中间件按「一条调用链 trace」算分位（一次请求扇出 N 个下游，取整条链的最大耗时）；再加上一个更隐蔽的差异：5xx / 超时请求到底计不计入分母、时间窗是 1 分钟还是 5 分钟、分位数是精确算还是 t-digest 近似算，这些每一项单独看都「合理」，叠在一起就能让两个数字差出好几倍。

【常见分歧 / 几种做法】 我观察到团队里大致分三种流派：

• 按请求（request-scoped）：每个请求一个样本，简单、可加和，适合看容量与 QPS 相关的问题；
• 按 trace（trace-scoped）：一次用户动作一个样本，更贴近「用户体感」，但扇出接口会被下游拖慢放大，且 trace 采样率一变分位就不稳定；
• 按「用户动作 + 业务结果」：把 5xx / 重试 / 兜底合并成一个业务事件再算分位，最贴近业务，但口径维护成本最高，跨团队几乎不可能对齐。

还有个更日常的争点：P50/P99 之外到底要不要强制加 P999？以及「分位数的分母」要不要剔除被限流直接拒掉的请求（429）——限流拒得快，反而会把 P99 拉低，这是不是反而「好看」了？

【我的倾向与理由】 我倾向「对外承诺 SLO 用 trace-scoped + 明确列出剔除规则，对内诊断用 request-scoped」，并且把口径本身写进指标的元数据（谁算的、含不含 5xx、窗口多长），而不是只报一个裸数字。理由：跨团队协作翻车 80% 不是算法错，而是「同一个词两个定义」；口径显式化之后，至少吵架能吵到点子上。

但我也承认 trace-scoped 有个坑：高扇出接口（一次下单扇出 20+ 下游）下，trace 的 P99 基本被「最慢那条腿」主导，等于把单点问题伪装成整体问题，诊断时反而误导。所以场景不同，答案可能真的不一样。

【想听大家怎么选】

1. 你们团队 SLO 是按请求还是按 trace 算的？扇出大的接口怎么处理？
2. 5xx / 429 / 超时到底进不进分母？有没有被「剔除规则」坑过——数字变好看了，问题反而被藏起来了？
3. 分位数用精确算还是 t-digest 近似？采样率 1% 时 P999 还可信吗？你们踩过「采样率一变，P99 跳变」的坑吗？
4. 你们有没有把「口径」做成指标元数据、强制跨团队对齐过？怎么推的、阻力在哪？

欢迎贴你们看板的截图（脱敏）和具体口径定义，咱们把「同一个词两个定义」这件事掰扯清楚。