一、项目背景

我们的AI网关在流量起来之后，慢请求越来越多，但团队没人能说清慢在哪一跳：是鉴权慢、路由慢、还是后端模型推理慢。我们当时把"网关可观测"当成必须补的课，否则任何延迟优化都是盲打。项目视角很清楚：看不见瓶颈，就谈不上优化瓶颈，可观测是延迟治理的前置条件。

二、落地场景

场景覆盖全链路。一是全链路追踪：每个请求生成唯一链路标识，穿过网关各层打标记。二是各段延迟打点：鉴权、协议转换、路由决策、后端调用分别计时。三是瓶颈告警：某段延迟超基线自动告警并标注嫌疑环节。四是调用拓扑可视：把网关到各模型实例的调用关系画出实时拓扑，一眼看全局，值班人员不用再翻一堆日志。

三、关键技术挑战与解决思路

难点一是打点对性能的影响，全量采样在高并发下成本高，我们用尾部采样加头部全采，慢请求必采、快请求抽采。难点二是跨进程串联，网关和后端模型若用不同追踪体系，链路会断，我们统一了上下文透传头。难点三是瓶颈归因，单看某段延迟会被毛刺误导，用滚动基线加百分位（P95/P99）判定，避免被偶发尖峰带偏。

案例片段（已脱敏）： 一次线上慢请求排查，拓扑图显示某模型实例P99延迟从约一点五秒涨到约六秒，而网关自身各段都在两百毫秒内。我们顺着链路定位到该实例所在可用区的显卡显存打满，临时把流量调走并扩容，瓶颈定位时长从过去的约一小时缩到约十分钟，根因一目了然。

四、效果数据

接入后追踪覆盖率达约九成八；慢请求瓶颈定位平均时长从约一小时降到约十分钟；因延迟引发的误判工单下降约五成；P99延迟异常告警准确率达约九成。拓扑图成为值班人员第一眼看的面板，排查从"翻日志"变成"看图点"。

五、可复用经验总结

网关先可观测，瓶颈可定位，这是优化延迟的前提。采样要分层，性能和保护只能靠尾部采样兼顾。上下文要透传，链路断了就退回猜谜。用百分位看延迟，平均值会掩盖最伤体验的那一跳，P99才是用户的真实体感。

结语

延迟优化最忌讳"全局调优"。我们把可观测铺到位之后才发现，绝大多数慢请求都集中在少数几个实例和某一段处理上，精准下手比全面加压省钱得多。

附：规模化落地的工程取舍

我们把链路追踪从网关单点推广到全栈调用时，采样策略是最直接的成本取舍。全量采样在高并发下打点开销不可接受，我们改尾部采样加头部全采，慢请求必采、快请求抽采，既保住排查能力又压住开销。上下文透传头我们统一了规范，强制所有下游遵守，避免链路断成几截退回猜谜。百分位基线我们用滚动窗口计算，过滤偶发毛刺，避免被尖峰误导去优化错环节。

附：给同行的一些提醒

第一，网关先可观测，瓶颈可定位，这是优化延迟的前提，看不见就别谈优化。第二，采样要分层，性能和保护只能靠尾部采样兼顾，全量或全不采都不可取。第三，上下文要透传，链路断了排查直接退回到翻日志的原始时代。第四，用百分位看延迟，平均值会掩盖最伤体验的那一跳，P99才是用户真实体感。第五，拓扑图要实时，值班同学第一眼看的应该是图而不是日志，可视化能省下大量沟通成本。

附：我们踩过的几个坑

第一坑是全量采样把网关自己拖慢，高并发下打点开销惊人，改尾部采样加头部全采才兼顾。第二坑是链路断裂，网关和后端模型用不同追踪体系，trace 到一半就断了，统一上下文透传头后才连成完整链。第三坑是被毛刺误导，单看某段瞬时延迟去优化，结果改完发现是偶发尖峰，用滚动基线加百分位才定位到真瓶颈。这几坑说明，可观测建设本身也有成本，采样、透传、基线这三件事做不对，可视化反而变成噪声源。

附：回到工程本质

可观测建设最深的体会是：看不见瓶颈，就谈不上优化瓶颈。我们花在打点、透传、基线上的工程，最终都兑现成了排查时长的数量级下降。值班同学从翻几小时日志变成看一眼拓扑图，这件事本身的价值就覆盖了整套系统的成本。

另一点体会是，采样和透传做不对，可视化就会变成噪声源。全量采样拖垮自己，链路断裂退回猜谜，毛刺误导优化方向，这三件事任何一件翻车，可观测就从资产变成负担。细节比架构更决定成败。

附：写在最后

把可观测铺到位之后，我们最大的收获不是少了几张工单，而是团队终于能用同一套语言讨论延迟：不再是谁感觉慢，而是哪一段、超了哪个百分位。这种共识本身，就是稳定性最稀缺的资产。