服务上线异常如何排查，如何搭建可观测性架构？

核心回答

服务上线异常时，先判断影响范围和是否需要止损，再沿一次真实请求定位阻塞阶段。用户点击发送后一直转圈，要依次确认请求是否发出、是否到入口、是否排队、是否卡在检索/模型/工具/存储，以及响应是否已结束但前端未正确收尾，不能一开始就认定模型慢。

可观测性架构要把指标、日志、链路和业务质量连起来：指标发现整体异常，日志保留事件细节，分布式追踪还原请求路径，业务评测和审计判断回答及动作是否正确。各层共享必要关联标识、版本信息和错误分类，才便于从告警追到根因。

展开解析

1. 先控制影响，再比较变更

检查异常从何时开始、哪些版本、用户、地区或功能受影响，关注错误率、任务成功率、尾延迟和积压。对严重错误或持续扩大的故障，暂停放量、关闭受影响功能、降级或回滚到已知可用版本，同时保留日志和必要现场。

回滚不是根因分析的替代，也不会自动撤销已发送的消息或已提交的业务动作。先确认接口、状态和配置兼容，再处理遗留任务与副作用；定位时对比代码、配置、模型、提示词、索引与权限变更，避免只查代码发布。

2. 从一次“转圈请求”找关键路径

先看浏览器网络记录：有没有发送、入口是否响应、流有没有事件及结束标记。接着查网关与服务入口的请求标识，再看排队时间、线程/连接池、数据库和外部依赖。

进入 Agent 后，把检索、重排、模型调用、工具执行和结果校验分别计时。并行步骤要看关键路径和重叠区间，不能把所有 Span 耗时简单相加；任务很慢也可能是不断重试或反复调用，而非某次调用特别慢。

若上游已生成内容，前端仍无输出，应检查响应缓冲、流式转发、客户端事件解析和异常收尾；若资源持续耗尽，再结合线程栈、运行时剖析、慢查询和队列数据验证具体瓶颈。

3. 建立相互关联的观测信号

信号	记录内容	作用
指标	请求量、错误、分位延迟、队列、Token、成本	发现异常趋势和影响范围
日志	异常、状态变化、重试原因、发布事件	解释某时刻发生了什么
链路	入口、检索、模型、工具与数据库的 Span	定位关键路径与失败步骤
质量评测	引用支持、任务完成、格式与安全结果	发现接口成功但答案或动作错误
审计	主体、资源、授权、提交参数与回执	追踪真实业务操作及权限

可以用 OpenTelemetry 做统一埋点与上下文传播，经 Collector 或直接导出到后端；指标、日志和链路可选适合现有系统的存储与界面。工具选型不必一开始堆满，先确保关键阶段有数据、能互相跳转。

4. 关联标识与采样比多写日志更重要

会话用 session_id 关联多轮，逻辑任务用 run_id，一次执行链路用 trace_id，具体步骤用 span_id，重试另记尝试标识。模型与工具 Span 保存版本、耗时、错误类型和必要请求标识。异步消息传递追踪上下文，长时间暂停后用稳定任务 ID 和合适的链路关联恢复，避免让 Span 永远不结束。

指标标签保持低基数，不把用户原文、订单号等无限值放进去。敏感内容脱敏、按需受控留存，并设置访问与保留策略；全量请求写完整提示词既贵，也会扩大数据暴露面。关键错误和慢链路适当提高保留比例，同时保留代表性正常样本作对照。

5. 告警与恢复要面向用户结果

不仅监控 CPU 和接口 200，还要看任务完成、错误副作用、长时间运行、取消传播和每成功任务成本。告警按严重度、影响用户和持续性组织，关联具体版本与处理入口，避免同一故障触发大量无法行动的重复提示。

修复后验证真实主路径、失败路径和遗留任务，观察系统在实际负载下是否恢复；把这次缺失的观测和可复现用例补齐。仪表盘存在不等于系统可诊断，要用“能否还原一条失败请求”检验架构。

追问

日志很多，但仍然定位不了，通常缺什么？

常见是缺请求关联、阶段边界、版本信息或统一错误分类，也可能没有区分排队和执行、原始请求和重试。先补这些能回答因果问题的字段，再增加日志量。

Trace 能解释模型内部真实推理吗？

不能。它记录系统实际输入输出和执行步骤，能定位工具和上下文过程，但模型生成的解释不是内部决策的完整证据。业务正确性仍要用资料、规则和结果验证。

对应教程

参考资料