做后端性能监控这些年我最大的感受是监控体系的演进从来都是跟着应用形态走的。早期单体应用看看CPU、内存、QPS就够用微服务起来之后分布式追踪成了标配现在大模型和AI智能体AI Agent全面铺开传统APM那一套又开始不够用了。最近半年我深度参与了几个AI应用项目从RAG问答到多步Agent工作流把OpenTelemetry的GenAI语义约定、LangChain回调机制、Dify平台日志这些链路翻了个底朝天也踩了不少坑。今天这篇就纯粹以实操角度聊聊AI智能体可观测的底层原理以及为什么传统APM在大模型业务面前经常失灵。不管你是刚接手AI应用运维的SRE还是正在给Agent应用搭建监控体系的开发这篇都值得仔细看一遍。1. 为什么传统APM管不住大模型业务1.1 传统APM的监控模型建立在请求-响应之上传统APMApplication Performance Monitoring的核心是围绕一次请求来组织数据的。它默认有一个明确的客户端发起请求服务端处理后返回响应整个过程可以量化成三大黄金指标延迟Latency、错误率Error Rate、流量Traffic/Saturation。再往下细化就是数据库查询耗时、外部HTTP调用耗时、GC暂停、线程池排队这些基础设施维度的指标。这套模型在微服务架构下确实非常好用。一次用户请求可以被拆成一棵分布式调用树每一层都有明确的父子Span关系耗时和错误可以逐级下钻。我见过很多团队用Zipkin或者Jaeger把一次下单请求从网关到数据库的完整链路拉出来定位到是某一个第三方支付接口的P99延迟飙高拖垮了整个链路。这种排障体验在传统架构下是很高效的。但问题恰恰出在这套模型的核心假设上请求是短暂的、离散的、可计数的而且系统状态可以由这些离散指标推导出来。大模型业务一上来这几个假设就全被破坏了。这是我后来反复跟团队强调的一个点——不是APM工具本身做得不好而是它的建模前提变了。1.2 大模型业务给监控带去的四个新变量第一个变量是单次请求的耗时量级完全变了。传统HTTP请求毫秒级搞定而一次智能体任务可能包含多轮LLM调用、多次工具调用、向量检索、重试、反思整体耗时几十秒甚至几分钟都是常态。传统APM默认5秒超时的告警规则在这种场景下基本失去意义要么疯狂误报要么因为阈值被调高而彻底失去预警能力。第二个变量是核心资源从CPU、内存变成了Token。Token的消耗直接关联成本、响应速度和生成质量而传统APM根本不采集Token维度自然也就回答不了为什么这次请求花了这么多钱为什么同一个Prompt有时快有时慢这类问题。我见过有的团队在排查LLM调用延迟时竟然还在看容器CPU使用率方向完全跑偏。第三个变量是业务语义和系统指标之间出现了巨大的断层。传统APM关心的是哪个服务慢而大模型业务更关心为什么Agent选择了这个工具哪一步推理逻辑错了上下文是不是快满了Prompt改成什么样能降低幻觉率。这些语义信息——Prompt内容、模型输出、工具选择、上下文窗口利用率——传统APM完全采集不到因为它的Span属性模型里根本没有这些字段。第四个变量是调用状态从无状态变成了强状态。Agent有记忆Memory、有上下文窗口Context Window每一轮对话都在累计状态前面某一步的错误会持续影响后续所有步骤。传统APM的指标模型天然假设请求之间相互独立而这种会话级的状态追踪它压根做不了。这四个变量加在一起结论就很清晰了要在LLM时代做好可观测必须建立一套语义化的观测体系把Token、上下文、工具调用、检索质量这些LLM业务独有的维度纳入监控范围。2. AI智能体可观测的底层原理拆解2.1 核心思路把LLM调用变成一等公民的SpanAI智能体可观测的设计思路业界目前基本收敛到一条路上在OpenTelemetry的Trace模型之上把LLM调用LLM Span、Agent决策Agent Span、工具执行Tool Span、向量检索Retrieval Span都作为一等公民纳入链路同时给这些Span挂上专属的语义属性。所谓一等公民意思是这些Span不再隐藏在通用HTTP Span里的一个URL而是拥有专门的Span名称和属性集合。比如一次LLM调用Span name通常叫chat/completions属性里会详细记录模型名、temperature、max_tokens、Prompt内容、响应内容、Token用量、是否被截断等。这样在追踪系统里就能按模型、按Prompt模板、按Token消耗做多维聚合分析。我把自己在实际项目中使用的Span类型梳理一下这是整个可观测体系的地基LLM Span记录一次LLM API调用的完整信息包含请求参数、Prompt、响应、Token用量、首Token延迟、总延迟、是否触发上下文截断。Agent Span记录一次Agent决策过程包含思考过程、选择了哪个工具、为什么选、执行结果是否被接受、是否进入循环。Tool Span记录工具调用的输入、输出、执行耗时、返回数据大小、是否超时、是否重试。Retrieval Span记录检索的query、召回文档ID、相似度分数、命中数量、是否走重排、向量维度是否一致。这套模型的威力在排查问题时体现得最明显。用户的一次提问可以在追踪系统里展开成一棵完整的语义树。从根节点能看到Agent的全部推理路径从叶子节点能看到每一次工具调用的细节。遇到问题不用靠猜顺着链路逐层下钻就行。这和我们以前排查一个慢SQL的思路本质上是一样的只是下钻的对象变了。2.2 数据采集层埋点思路的三个层次模型设计好了数据怎么采这是目前实践中最有体感的部分。我总结了三个层次按成本和侵入性从低到高排列团队可以根据自己的情况选。第一层是框架自带的回调或日志机制。目前主流框架基本都做了这件事。LangChain和LangGraph有Callback机制可以在每个环节触发事件OpenAI等SDK在响应对象里自带usage信息Dify这类平台带了一套相对完整的日志体系能看到每个节点的输入输出和耗时。如果你项目用的是现成框架这一层的改造成本最低先跑起来再说后面再逐步升级。第二层是OpenTelemetry生态的GenAI Instrumentation库。OpenTelemetry社区正在推进GenAI语义约定GenAI Semantic Conventions目前Python、Node.js等语言已经有一些可以直接使用的库比如opentelemetry-instrumentation-openai、opentelemetry-instrumentation-langchain。装上去之后大部分LLM调用不用改业务代码就能自动生成语义Span。这是我最推荐的起点因为它是行业标准未来换框架、换平台埋点数据不会作废。第三层是自研埋点。如果你们公司在做自研Agent框架或者需要采集框架覆盖不到的细节就得自己在关键调用点手动创建Span并确保Trace上下文能正确传递。这里有一个必须重点提醒的坑手动埋点最怕Context丢失。很多Agent框架用异步任务、线程池、消息队列来执行工具调用如果创建新任务时没有显式把Trace上下文传进去链路就会断成好几截整个追踪树全废了。我们项目早期就吃过这个亏后来统一封装了一个context_propagator工具类所有异步入口强制续接Span才把链路完整性提上来。2.3 关键概念Token、上下文窗口和成本归因大模型可观测里Token是绕不开的核心计量单位。我建议所有做这块的团队先集中精力把Token相关监控做好而不是一上来就堆各种花哨的业务指标。首先要分清几种Token计数口径。请求Tokenprompt_tokens、生成Tokencompletion_tokens、总Tokentotal_tokens三者用途完全不同。请求Token决定了成本上限也直接影响首Token延迟因为模型需要先把整个Prompt处理一遍才能开始生成生成Token直接关联响应长度和总体耗时总Token关联计费。做成本告警的时候我建议按单用户/单会话累计Token来计算而不是只看单次请求否则一次大规模批处理任务就会触发一堆无关告警。其次是上下文窗口利用率。这个指标是我认为除了延迟和错误率之外大模型业务最值得监控的第三根支柱。计算公式是(单会话累计prompt_tokens 预估response_tokens) / 模型上下文窗口大小。当利用率接近上限时会出现两类典型问题一是超出窗口直接报错或被模型静默截断二是离窗口边界太近时模型输出质量肉眼可见地下降。我遇到过一起生产事故RAG场景下每次请求都把完整对话历史和召回文档全塞进上下文结果上下文越滚越大到第30轮对话时接口开始大量报错排查了半天才发现是上下文利用率顶到了100%。这类问题不监控利用率基本发现不了。最后是成本归因。在LLM场景里成本不再只是运维关心的话题而是产品、运营都要看的业务指标。每个功能模块、每个用户、每次Agent执行消耗了多少Token、花了多少钱必须能按维度灵活聚合。这里我强烈建议埋点的时候就把team、feature、user_id、session_id这些业务标签打进Span属性里后面想怎么算成本都行。别把成本计算逻辑写死在日志文件里让可观测系统去聚合才是正确姿势——这也是为什么我们选MetricsTrace双通道的原因。3. 实操搭建一套AI智能体可观测体系3.1 技术选型与架构设计这块直接说结论是我踩过几轮坑之后的推荐组合链路追踪后端用支持OpenTelemetry的分布式追踪系统。中小规模直接上Jaeger或Grafana Tempo生产数据量大了可以基于ClickHouse自建存储或者直接用托管服务。指标存储Prometheus VictoriaMetrics配合Grafana出图。Token消耗、成本、上下文利用率这些聚合指标走Prometheus格式最顺手保留周期短、查询速度快。日志存储Loki或者ELK都行重点是把完整的Prompt和Response落盘保存这是排障时最原始的素材。可视化Grafana一套搞定Metrics和Trace的联动直接通过Grafana的数据源插件实现点一个指标能直接跳到对应的Trace详情体验非常顺。整体架构不用搞太复杂。最简方案就是应用侧埋点 → OTLP Collector → 追踪后端 指标后端。这里有个架构层面的关键点要提醒LLM的Span体积非常大一个Prompt加Completion动辄几十KB如果再加上Agent的多轮调用单条Trace可能上百KB。所以OTLP Collector前面一定要做采样和裁剪否则存储成本会迅速失控。具体怎么做我放到3.4单独讲。3.2 用OpenTelemetry GenAI语义约定做标准化埋点OpenTelemetry社区的GenAI语义约定现在已经比较成型了我建议直接用不要自己发明一套标签体系。未来无论是切换模型供应商、换追踪平台还是接AI Gateway标准化的字段会让你省掉大量迁移成本。核心的几个属性字段是这样的gen_ai.system模型供应商比如openai、anthropic、ollama、deepseek。gen_ai.request.model请求的模型名比如gpt-4o、deepseek-chat。gen_ai.request.temperature / max_tokens请求参数。gen_ai.usage.input_tokens / output_tokensToken用量。gen_ai.response.model实际响应的模型名有的网关会做模型路由请求模型和响应模型可能不一致。gen_ai.prompt / gen_ai.completionPrompt和响应内容。代码层面最简单的接入方式是用官方Instrumentation。以Python为例from opentelemetry.instrumentation.openai import OpenAIInstrumentor OpenAIInstrumentor().instrument()这行代码加上去OpenAI SDK的调用就会自动生成LLM Span带上模型名、Token用量这些属性。LangChain场景可以用对应的instrumentation库或者接它自家的LangSmith但要注意LangSmith的数据格式和OpenTelemetry标准不完全一致后期如果要统一进自建的追踪平台需要做一层转换这个成本要提前评估。自研框架手动埋点的核心模式是这样的from opentelemetry import trace tracer trace.get_tracer(agent.observability) def call_llm(messages, model): with tracer.start_as_current_span(chat/completions) as span: span.set_attribute(gen_ai.system, openai) span.set_attribute(gen_ai.request.model, model) span.set_attribute(gen_ai.request.max_tokens, 2000) response llm_client.chat.completions.create(modelmodel, messagesmessages) span.set_attribute(gen_ai.usage.input_tokens, response.usage.prompt_tokens) span.set_attribute(gen_ai.usage.output_tokens, response.usage.completion_tokens) span.set_attribute(gen_ai.response.model, response.model) span.set_attribute(gen_ai.completion, response.choices[0].message.content) return response注意一个实操细节要不要把Prompt和Completion完整写进Span需要权衡存储、隐私和排障效率。我的建议是生产环境默认只记录Prompt的模板ID或前200字摘要完整内容只在调试模式或者特定采样策略下开启。涉及用户隐私或企业机密的场景必须做脱敏处理否则一旦追踪系统被拖库就是重大安全事故。3.3 核心指标定义与计算逻辑按照可观测的经典三大支柱Metrics、Logs、Traces我针对大模型业务整理了一套可以直接抄走的指标清单维度指标名计算公式或口径告警建议延迟TTFT首Token延迟从请求发出到收到第一个Token的时间 5秒告警延迟TPOT每Token生成耗时LLM响应阶段耗时 / completion_tokens按模型基线设置延迟总响应时长LLM Span的总Duration结合业务场景错误LLM调用错误率错误响应数 / 总调用数按模型聚合 1%关注 5%告警错误截断率被截断的请求数 / 总请求数持续上升即告警资源上下文窗口利用率单会话累计prompt_tokens / 窗口大小 70%预警 90%告警成本单会话Token消耗会话内total_tokens求和按业务设定阈值业务工具调用成功率工具成功执行数 / 工具调用总数自定义业务Agent决策轮次一次任务中Agent的决策次数异常升高警惕死循环TTFT和TPOT这两个延迟指标是LLM场景特有且极其重要的。传统APM看整体耗时但在流式输出的场景下整体耗时会被生成长度严重干扰。一个请求生成200字另一个生成2000字整体耗时差出好几倍但两者可能都是完全正常的。TTFT拆分出模型排队处理Prompt的时间TPOT反映的是逐Token生成的速度这样就不会被输出长度误导。计算上有一个坑需要特别说明TPOT如果用总耗时除以Token数来算一旦请求发生限流或多次重试数值就会虚高。正确做法是直接从LLM Span里取模型响应生成阶段的耗时而不是整条请求的总耗时。我们当时在这上面吃了暗亏算出来的TPOT忽高忽低一度以为是模型不稳定最后才发现是计算口径错了。3.4 采样策略别让Token把存储打爆这一节必须单独拎出来说因为它直接决定整套体系能不能长久跑下去。LLM的Trace体积和传统请求完全不是一个量级——传统HTTP请求的Trace一般几百字节到几KB而一次LLM调用如果带上Prompt和Completion就是几十KB一个Agent任务里十次LLM调用一条Trace就是几百KB。这种体量不做采样任何存储都扛不住而且查询也会越来越慢。我现在生产环境的分级采样策略是这样的默认采样率10%只保留Span基本属性和Token用量不落Prompt内容。对Error Trace强制100%采样完整记录Prompt和Completion这是排障的核心素材。对慢Trace超过P95阈值的强制100%采样用于性能瓶颈分析。对包含关键业务标签的请求比如付费用户、核心功能入口单独路由提高采样率。这套策略背后的逻辑很简单排障最需要的是出问题的那批Trace而不是全部Trace。把采集预算集中花在错误、慢请求、核心业务上性价比最高。另外强调一点采样要在应用侧或OTLP Collector侧做尽量不要在存储层做——数据都存了再删纯属浪费资源。4. 常见问题与排查技巧实录4.1 案例一Agent陷入工具调用死循环现象某个Agent功能频繁超时单次任务耗时从正常的30秒飙到5分钟以上。传统APM面板显示外部HTTP调用数量暴增但完全看不出是哪里出了问题。排查过程打开Agent Span看决策链路发现Agent在连续调用同一个搜索工具而且每次调用前的Thought内容高度相似。这说明模型和工具的返回结果之间形成了无效对话——模型每次尝试解析工具返回结果都失败于是反复重试。再看Tool Span的返回内容定位到根因工具返回的数据格式在某一轮之后变了从标准JSON变成了带Markdown标记的文本模型解析不了就一直在同一个工具上打转。解决第一给工具调用增加最大重试次数和循环检测机制当同一个工具连续调用超过N次且输出相似时强制中断Agent并返回错误第二工具返回层面做统一格式校验解析失败时返回明确的错误描述给模型而不是丢一段脏数据让模型自己去猜。这个案例给我的体会是Agent可观测不能只看调用了几次必须看每次调用的输入输出是什么。没有语义级的Tool Span这类问题排查起来基本只能靠日志捞效率差太多了。4.2 案例二上下文窗口静默截断导致的降智现象用户反馈对话进行到20轮之后AI开始答非所问前后回答自相矛盾。表面上看所有监控都正常延迟没升高、错误率是0、服务也没重启。排查过程先看上下文窗口利用率指标发现20轮左右的会话利用率已经涨到85%以上。再看LLM Span的响应内容发现部分请求的completion开头出现了截断标记说明模型其实是带着不完整的上下文在硬答。解决第一引入上下文压缩策略对早期对话做摘要后再塞回上下文窗口第二对利用率超过80%的会话动态触发建议开启新会话的提示或者自动切换到长上下文模型第三把context_truncated这个属性纳入监控一旦出现就告警而不是等问题反馈到用户那边才知道。这个案例说明了一个很重要的现象大模型业务的很多故障是静默型的系统层面没有任何报错但服务质量在悄悄劣化。这正是传统APM的最大盲区——它只盯报错不盯语义质量。而上下文利用率、截断率这类指标才是提前发现这类问题的关键。4.3 案例三RAG检索命中率为零导致的幻觉现象某个知识库问答场景用户集中投诉回答经常编造内容。排查时发现LLM调用错误率为0延迟也正常几乎所有传统监控指标都健康。排查过程通过Retrieval Span看召回情况发现大量查询的召回文档列表是空的或者召回的相似度分数普遍低于0.2。继续下钻Embedding环节发现一次版本升级把Embedding模型给替换了新旧模型的向量维度不一致导致查询向量和库里存量向量的距离计算全部异常检索结果自然是乱的。解决回滚Embedding模型版本重新构建向量索引。同时在Retrieval Span里加上向量维度、相似度阈值、命中数量这些属性并配置召回为空比例监控指标超过阈值直接告警。这里必须多说一句RAG链路中检索质量是决定LLM输出质量的上游因素。很多团队只盯LLM本身的指标忽略检索环节的监控这是不对的。可观测一定要覆盖到Retrieval这一段包括query内容、召回文档ID、相似度分数、rerank结果。检索出了一次问题后面LLM再怎么调参都是白搭。4.4 排障检查表与避坑清单把这段时间踩过的坑整理成一份快速排查检查表遇到问题可以按这个顺序走先看Agent Span确认Agent决策是否正常有没有重复调用、死循环、异常中断。再看Tool Span与Retrieval Span确认工具返回和检索结果是否正常相似度是否达标格式是否被解析成功。然后看LLM Span确认模型、参数、Token用量、是否截断、TTFT和TPOT是否符合预期。最后看上下文利用率与成本指标确认是否存在累积性问题而不是单次偶发故障。避坑清单每一条都是真金白银换来的别在Span里无脑存完整Prompt存储和隐私双重压力。分级采样才是正确解法。异步任务和线程池里一定要显式传递Trace上下文否则链路断裂排查起来非常痛苦。Token计数口径要统一。有的计费模型统计的是字符数而不是词元数换算不对成本算出来全是错的。上下文窗口利用率必须监控这是最容易出现静默故障的地方。RAG场景必须监控召回质量不能只看LLM本身的错误率。Prompt版本要纳入可观测范围。在Span属性里打上prompt_template_id上线后如果效果变差能快速定位是不是Prompt变更引起的。采样规则要按业务标签区分不要所有流量一视同仁。核心链路和普通流量用同一套采样率要么浪费存储要么关键数据没采到。最后聊几句写到这儿AI智能体可观测的底层原理和实操路径基本讲透了。我个人在实际操作中最大的体会是可观测这件事本质是回答系统为什么变成了现在这个样子的能力。传统APM提供了基础设施级的答案而大模型业务需要的是语义级的答案。工具链——不管你是用OpenTelemetry的GenAI约定、LangSmith还是Dify内置的日志体系——都只是载体核心在于你要建立起Token、上下文、工具调用、检索质量、成本这五个语义维度的观测能力。最后再分享一个小技巧做这一块的团队建议从一次线上事故的完整复盘链路倒推需要哪些可观测数据而不是从工具的功能清单正推。拿一个真实的故障案例走一遍从用户反馈到根因定位的完整流程看每一步需要什么数据支撑然后按这个需求去设计埋点和指标。用这种方式做出来的观测体系一定是最能救命的。