一、项目背景

某平台模型调用链路长，用户反馈回答慢，但研发查不出是网关路由慢、模型推理慢还是下游超时。日志散在各处，一次排障要拉三四个人对半天。我们接手时，团队对链路延迟的认知基本靠猜，优化也无处下手，因为根本不知道瓶颈在哪。有个经典场景：用户说慢，网关说模型慢，模型说网关路由慢，最后谁也没证据，会开完了问题还在。

更被动的是，这种扯皮让优化停滞。没人愿意动自己那环，因为没法证明不是自己的问题，项目就一直带着这个慢病跑。

二、落地场景

我们围绕网关建了全链路可观测。全链路 trace 埋点是基础，从请求进网关到模型返回，每一跳都打同一个 trace id，串成一条完整链路。延迟分布分析放在 trace 之上，把每一段的 P50、P95、P99 都算出来，一眼看出哪段拖后腿。错误率监控按服务维度拆，网关、路由、模型各自独立统计，快速定位是哪一环在报错。依赖拓扑和告警联动兜底，依赖关系可视化，异常自动触发告警并关联到具体链路，值班同学点开告警就能看到是哪一段慢。

案例片段（已脱敏）： 网关全链路 trace 与监控面板配置片段（示意）：observability:  trace:    propagate: true    span_per_hop: true  metrics:    latency_percentiles: [p50, p95, p99]    error_rate_by: [gateway, router, model]  alert:    p99_threshold_ms: 800    on_breach: page_oncall接入后一次典型慢请求被定位到路由层某模型实例 P99 约 1.2 秒，而网关自身仅约 30 毫秒。排障时长从平均约半天压到约 20 分钟，P99 链路延迟从约 1.5 秒优化到约 600 毫秒。

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

第一个坑是 trace 断链。早期只在网关打点，调模型时换了协议，trace id 没往下传，链路断成两截。我们统一了上下文传播，不管走 REST 还是 gRPC，trace id 必须透传，断链的点补上后，链路才完整。这个坑看似小，但它意味着你永远看不到全貌，排障只能靠猜。

第二个难点是数据量。全链路埋点产生的 span 很多，直接存全文成本爆炸。我们做了采样，正常流量采百分之十，慢请求和错误请求全采，既控成本又保住排障需要的样本。这里有个取舍，采样会丢一部分正常链路，但我们认为排障主要看异常，正常链路十采一足够了。

第三个点是告警噪声。一开始告警太敏感，波动就报，oncall 被烦到无视。我们设了持续时长和基线偏离双条件，只有真正异常才 page，告警准确率从约五成提到约九成。告警这东西，准比多重要，天天误报大家就当没看见，真出了事反而漏。

四、效果数据

接入后排障时长从平均约半天压到约 20 分钟，P99 链路延迟从约 1.5 秒优化到约 600 毫秒，错误率定位准确率约 95%，告警准确率从约五成提到约九成。研发第一次能指着面板说瓶颈就在这，而不是互相甩锅。我们统计过，接入后链路相关的故障平均恢复时间也跟着降了下来，因为定位快了。（数据均为脱敏示意值）

除了排障，这套可观测还顺带解决了容量规划的问题。过去扩容靠拍脑袋，现在看板上有各段的长期延迟趋势和资源水位，我们能在拐点到来前就把实例扩上去，而不是等告警炸了才动。trace 数据我们也沉淀下来做复盘，每次大促前的压测都拿历史 trace 做参照，知道哪段最容易先红。我们还把慢链路的样本单独存了一份案例库，新人入职看几个典型案例就能搞懂链路长什么样，比看文档快得多。 可观测的价值，慢慢从救火变成了日常的工程基础设施，值班同学碰到慢请求第一反应不再是猜，而是点开面板。告警和工单系统打通后，异常会自动开单并指派给对应服务的 owner，责任清晰，不再出现以前那种互相踢皮球。我们后来把监控阈值和告警策略也沉淀成模板，新接入一条链路直接套用，接入成本几乎为零。可以说体系建好之后，整个团队的排障文化和协作方式都变了，从靠人盯变成了靠系统盯，这比单次排障提速更有长期价值。

我们把链路监控的覆盖也延伸到了模型推理内部。除了网关到模型的整段链路，我们还在模型服务里埋了推理各阶段的耗时，比如分词、检索、生成各占多少，这样模型自身慢在哪里也能看清。这个粒度在排查大模型特有的长尾延迟时特别有用，因为慢往往慢在某一个内部阶段而不是整条链路。内部可观测补全之后，模型侧的优化终于也有了抓手，不再是只能在外围调来调去。

五、可复用经验总结

不可观测的系统就是盲盒，链路 trace 要在一开始就埋，等出了问题再补埋点，那次事故你已经扛下来了。trace 传播必须统一透传，断链会让排障回到靠猜。采样要聪明，正常流量采少量、异常全采，成本和数据都不丢。告警别太敏感，噪声多了 oncall 就麻木，反而漏真问题。我后来认为，可观测不是锦上添花，是排障的命根子。很多团队等到故障频发才想起建监控，其实那时候最该有的是早就铺好的 trace。