淘房记1. 为什么GenAI会掀翻可观测性的老桌子
先说个2026年开头的真实场景。某天凌晨两点，值班手机被连环告警打醒——线上LLM服务的平均响应时间从800ms直接飙到4.2秒。我打开传统的APM面板，映入眼帘的是“一切正常”：CPU没冲高、内存平稳、HTTP 200占比99.9%。但用户的真实反馈是“AI答非所问”“上下文完全丢失”“生成的文档读不通”。
这就是2026年最典型的可观测性困境：传统指标体系还在盯着服务端资源、HTTP状态码和数据库延迟，但真正的故障发生在“模型输出质量”这个从未被观测的维度上。一个LLM应用的价值不在于“接口返回了200”，而在于“返回的内容到底对不对、上下文有没有丢失、工具调用链有没有断裂”。这些新型故障，用老一套Metrics、Logs、Traces体系根本测不出来。
再往深一层说，生成式AI应用和传统后端服务的本质区别，在于它把“不可判定性”引入了生产链路。传统服务的输入输出是确定性函数，参数不合法可以抛异常，依赖不可用可以看熔断。但LLM服务面对同一个Prompt，每次输出都不同，失败模式也不是“报错”，而是“悄悄给你一段编造的答案”。这种模式下，可观测性的核心目标从“服务是否可用”变成了“模型是否在正确工作”以及“成本是否在失控膨胀”。要回答这两个问题，传统的三大支柱体系不够用，更不是简单地加几个自定义指标就能解决。
OpenTelemetry在2024到2025年就敏锐地捕捉到了这个方向，其GenAI语义约定（Semantic Conventions）草案从2024年延续到2025年持续迭代，到了2026年已经趋近成熟。官方为LLM应用定义了标准化的Span属性、指标名称和日志关联规范，本质上是把“模型交互”“上下文管理”“工具调用”“向量检索”这些AI特有的动作，纳入统一的可观测坐标系。这件事的意义比大多数人想象得大得多：它不是“可观测性工具多支持了一个新框架”，而是“整个行业第一次有了描述智能体行为的标准语言”。
我从2018年就开始用OpenTelemetry做微服务链路追踪，一路看着它从CNCF孵化项目变成事实上的观测标准。2026年再回头审视，最让我感慨的不是它支持的SDK数量突破了某个数字，而是它的语义约定设计第一次把“业务质量”和“技术指标”拉到同一个数据模型里。这篇内容就把我在这两年里基于OpenTelemetry重塑GenAI可观测体系的实际经验完整写出来，从为什么非要这么做、语义约定怎么落地、埋点方案怎么设计、成本怎么控制，到踩过的坑和排查实录，一次性讲透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心思路：从“三大支柱”到“三个新支柱”
2.1 传统可观测性模型的三个结构性盲区
先不急着上方案，聊清楚问题。传统可观测性的核心理论是Metrics、Logs、Traces三支柱，这套模型在微服务和容器化时代证明了自己。但放到生成式AI场景里，它暴露出三个结构性盲区。
第一个盲区是“用户价值不可观测”。传统系统里，一次HTTP 200意味着服务正确处理了请求，业务成功率和接口状态高度相关。但LLM应用里，接口无论返回什么都一定是200——请求格式正确、网络通了、模型正常响应了。可这个响应用户满意吗？不知道。回答是幻觉吗？不知道。上下文有没有被污染？不知道。可观测系统对“输出质量”一无所知，这是过去十年里没有遇到过的问题。我做过一个内部测试，把故意让模型回答错误答案的流量和正常流量混在一起，传统监控指标完全无法区分这两类请求。
第二个盲区是“调用链语义断层”。传统链路追踪关注的是服务间的调用关系，比如A服务调B服务，B服务查了数据库。但LLM应用的调用结构完全不同，上游是Prompt拼装，中间是LLM推理，下游可能是向量库检索、工具函数调用、外部API请求，最后还有一层前置的护栏规则和后置的输出校验。这个链路的每个环节失败模式都不同，而且在老模型里体现为几个互相割裂的Span，没有人能一眼看出“Prompt上下文”和“模型输出”之间的因果链。
第三个盲区是“成本与质量无法关联”。LLM服务的成本不是按CPU计费的，而是按Token消耗计费的。同样的用户请求，模型可能老老实实回答消耗500个Token，也可能开始自我对话消耗5000个Token，成本差一个数量级。传统观测体系能告诉你QPS上升了多少，但没法告诉你“哪个业务线在烧模型预算”。
2.2 OpenTelemetry为何成为2026年的事实标准
选OpenTelemetry作为重塑地基的方案，不是因为它有多先进，而是因为它做对了几件战略性的选择。
其一是“统一数据模型”。它用Resource、Span、Metrics、Logs四种核心数据类型，把分布式系统中的一切行为都描述出来。这种模型天然适合做AI应用——Prompt构造是Span，模型调用是Span，向量检索是Span，工具函数执行是Span，它们共享同一个TraceID，天然串成完整链路。
其二是“语义约定先行”。OpenTelemetry定义了一整套标准化的属性名和指标名，比如HTTP状态码、数据库语句、消息队列主题这些。2026年的GenAI语义约定扩展了gen_ai.*前缀的数百个属性定义，从模型名称、推理参数、Token用量，到嵌入向量的维度、截断标记、工具调用参数，全部有标准命名。
其三是“可插拔的SDK架构”。无论你的应用是Python写的、Java写的还是Go写的，都可以引入官方SDK，自动采集HTTP调用、数据库操作等基础数据，再通过手动埋点覆盖AI相关逻辑。这种“一条Trace贯穿所有”的能力，是传统监控厂商做不到的——它们通常是自研Agent和私有协议，闭环很好但开放性差。
我在这两年里看过不少团队自研AI观测平台，最后都掉进同一个坑：自定义埋点格式和字段命名，三个月后换了一个模型供应商，原来的字段全作废，数据迁移苦不堪言。OpenTelemetry的价值不在于“今天能用”，而在于“明年还能用、后年还有社区维护”，这比任何炫酷功能都重要。
2.3 从“观测AI应用”到“AI辅助观测”的双向奔赴
2026年真正有意思的变化，是GenAI和OpenTelemetry的关系已经从单向变成了双向。一方面，OpenTelemetry作为基础设施观测所有的AI应用；另一方面，AI大模型开始反过来给可观测平台提供智力支持。
典型场景是异常检测。传统监控的告警阈值靠人工设定，设得严了天天误报，设得松了故障不可见。2026年的可观测平台普遍引入大模型做时序数据异常检测，它能自动学习每个指标的周期性模式，动态调整基线，在故障发生前给出预警。我实际测试过一套部署在某模拟电商平台上的方案，原来自动扩缩容策略在流量尖峰时总是慢半拍，换成大模型预测后，系统能在流量到达前提前扩容，成功避免了两个资源瓶颈型故障。
另一个场景是日志摘要和根因分析。一个大型故障往往产生几万条日志、几十个Trace、上百条告警，人工翻至少要半小时。现在主流做法是先让Agent聚合所有信号，用大模型做上下文摘要，直接输出“当前最可疑的根因Top 3”和“推荐排查路径”。这套东西在我自己的团队里已经是标配，故障平均定位时间从40分钟降到了8分钟。
这意味着你的观测系统本身也必须“可被观测”。“模型运行在哪”“调用哪个Prompt版本”“Token消耗多少”“推理延迟是否异常”，这些指标同样要打进OpenTelemetry体系。要理解2026年可观测性的完整图景，得同时接受这两条主线：用统一标准观测AI，也用AI增强观测系统的分析能力。
3. 核心细节：GenAI语义约定到底埋什么
3.1 Span属性：模型交互的“标准代码表”
如果你要设计一套AI观测标准，第一步肯定是定义“什么是一次模型交互”。OpenTelemetry的GenAI语义约定给出的答案是：把一次模型调用定义为一个Span，然后给这个Span挂上标准属性。这些属性分为三大类：请求参数、响应参数、上下文状态。
请求参数里最关键的是gen_ai.request.model、gen_ai.request.temperature、gen_ai.request.max_tokens，分别表示请求的模型名、采样温度和最大Token数。看起来简单，实际价值极大——同一个业务接口背后可能有多个模型版本在灰度路由，没有这些属性，你就没法分析“哪个模型版本的幻觉率最高”“哪个版本最烧钱”。
响应参数里核心是gen_ai.response.id和gen_ai.usage.input_tokens、gen_ai.usage.output_tokens。前者用于关联模型侧的请求日志（云端API都会给你一个请求ID），后者直接算钱。有了这两个数字，你就能给每一个业务请求精确计算成本，按线路、按功能、按用户维度做成本分析。这套体系我落地之后，财务再也不用月底拿着一张账单来对账了。
上下文状态要埋的是gen_ai.prompt（或被截断的摘要）、gen_ai.completion（或被截断的摘要）和gen_ai.system。为什么要做截断？因为部分LLM的Prompt可能高达几万Token，全量上报（通过遥测数据）存储成本会把系统压垮。官方推荐的做法是默认只上报少量信息、通过采样策略做全量上报，这在后面的“成本治理”章节会展开讲。
3.2 不只是LLM：向量检索和工具调用也要入链
GenAI语义约定覆盖的不只是“模型调用”这一个环节。一个完整的RAG应用包含至少五个可观测单元：检索器（向量库）、重排序、上下文拼接、模型调用、工具调用。官方语义约定分别定义了这些单元的Span名称和属性。
在我的一个RAG项目中，用户投诉“回答质量差”，我打开链路一看，发现一个隐藏很深的Bug：某个向量库检索服务在特定Embedding模型下返回的TopK结果里，第3到第5条天然是低质量数据，而重排序服务默认只对前两条做精细打分，导致低质量内容混入上下文。传统监控根本看不到这个——因为每个服务都“正常运行”，接口都在规定时间返回结果。但OpenTelemetry把检索记录、命中分数、上下文拼接全过程都记录在案后，我用一次Trace分析就定位了问题，前后不到十分钟。
工具调用（Function Calling）链路的观测是另一个重点。2026年的Agent应用里，模型经常调用搜索、计算器、地图API、内部RPA系统等外部工具，而且经常是多轮调用——模型先调了搜索，再根据搜索结果调了某个内部系统，最后综合输出。这中间只要有一环调用失败或返回格式不合法，整个任务的输出就报废。建议做法是为每次工具调用创建一个子Span，记录工具名称、调用参数、返回状态和耗时。这样排查“模型为什么在瞎编”时，就有据可查。
3.3 指标和日志：跨组件聚合的两个关键约定
除了Span体系之外，GenAI语义约定还定义了若干标准指标（Counter）和日志关联方式。
指标方面的核心建议有三个：Token消耗计数器、推理请求计数器和向量检索延迟直方图。这三个指标建议用统一的命名前缀（例如系统名加gen_ai），确保跨程序、跨语言的一致。你可能会问：指标和Span不是重复吗？其实各有分工。Span级别的Token用量是单次请求的，适合排查；指标是聚合维度上的，适合做大盘和告警。以我个人经验，告警主要依赖指标，因为指标可以设置阈值和聚合窗口，而Span不适合直接做实时告警，单条Span的异常更多用于根因分析。
日志关联方面有一条很重要的经验：AI应用日志里最需要关联的是“TraceID”和“SessionID”两个字段。传统服务只需要TraceID就能通过链路追踪做排查，但LLM应用必须额外引入SessionID。原因是用户在一次会话里可能连续发多个Prompt，每个Prompt一个TraceID，但这些Trace之间没有任何关联关系——用户在第三轮说“我之前说的那个事，你再详细讲讲”，你必须能把前面所有轮的上下文串起来看。我的做法是在所有日志和Span里都写入Session ID，持久化到Log/Metric/Trace三个信号中，这样既支持单请求排查，也支持多轮会话分析。
提示：埋点最忌讳“字段命名想当然”。宁可一开始多花两小时照着官方语义约定的字段名来设计，也不要自己发明一套。不然半年后社区出了标准化工具，你的历史数据全都得重新清洗。
4. 实操过程：端到端搭建一套GenAI观测链路
4.1 采集端架构：SDK、Agent与Gateway三件套
先明确一下2026年主流的采集架构。总结下来是三件套：应用内SDK、节点级Agent、流量Gateway（网关注入是网关侧，不干扰业务）。
应用内SDK负责最细粒度的埋点。比如你有一个Python写的LLM网关服务，用OpenTelemetry的Python SDK初始化TracerProvider，然后手动给模型调用环节创建Span。这个方式最灵活但侵入性最高，需要业务代码里手动打桩。
节点级Agent是部署在每台云主机上的独立进程，负责接收应用通过OTLP协议上报的Trace和Metric数据，做本地缓冲、批处理和部分采样，再转发到后端。为什么需要这一层？因为直接让应用SDK和后端存储通信有两个问题：一是后端故障会拖垮业务（同步上报阻塞），二是每个服务都配置不同后端地址会乱套。Agent层的缓冲机制我已经用了四年，效果非常稳定。在Kubernetes环境里，我通常部署为DaemonSet，整个集群的数据流汇聚得干净整洁。
流量Gateway是这两年的新趋势。GenAI应用的模型请求经常集中在几个固定出口（不管是云端模型还是内网模型集群），所以在Gateway上做一次集中的语义化采集，天然能覆盖所有业务线的模型流量。用网关的好处是无需改动业务代码，可以把所有的模型调用请求记录成统一格式的日志，补上Token计量，甚至做一些实时截断或采样策略。缺点是无法拿到应用业务层的上下文属性，比如“用户ID”“具体操作意图”这些。
推荐的做法是组合使用：SDK埋业务上下文，Agent做缓冲转发，Gateway兜底采集模型出入口数据。从性价比看，Gateway的优先级最高——如果你来不及全部埋点，先在网关层把模型调用统一采集起来，就能解决70%的观测问题。
4.2 服务端配置：两个必须监控的后端组件
说完采集端，聊服务端。一个完整的观测后端至少包含两个核心组件：链路存储（Trace与Span）和指标存储（Prometheus或相似系统），再加上日志存储，构成支持三个信号访问的统一后端。
链路存储的选择上，很多人喜欢直接上云托管的方案，省事，但也带来了成本不可控的问题。我实测过自建和托管的差异：一套日均千万级Span的存量，自建的存储成本大概是某主流云托管方案的六成到七成。但如果你没有专门的运维人力，托管方案更值得推荐。自建方案的核心是做好数据保留策略，Hot数据保留7天用SSD，Warm数据保留30天用普通磁盘，Cold数据直接转对象存储做离线归档。
指标存储这边，如果你的指标量级上了千万条序列，传统的单机版指标库会开始吃力。2026年通用做法是引入支持水平扩展的高兼容后端，这里不具体说选型，只提醒一点：别把指标存储和Trace存储混在一个中间件里。两者访问模式差异太大，混用会互相拖累。我在一个项目上踩过这个坑——为了省机器，把Trace和Metric塞进同一套底层存储，结果查询超过三天时间范围的数据卡到Timeout。
日志存储的主题是“接入原有日志系统”还是“统一日志格式”。我的经验是尽量别让日志系统独立分离，而是通过OpenTelemetry的Logs SDK把日志事件也上报到统一后端。如果日志量特别大，可以单独存储，但日志里的TraceID和SessionID必须和链路数据打通。
4.3 代码示例：Python环境的GenAI埋点模板
下面这个Python示例覆盖了手动埋点的核心场景。代码基于模拟项目X的某LLM网关服务，去掉业务细节，只保留观测骨架，你可以直接抄到一个服务上改造使用。
python复制from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# 初始化Tracer，指向本地Agent的4317端口
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("llm-gateway")
def call_llm_with_telemetry(session_id, prompt, model_name, temperature):
with tracer.start_as_current_span("llm.invoke") as span:
# 写入通用业务上下文
span.set_attribute("app.session_id", session_id)
span.set_attribute("app.user_id", "user-xxxx")
# 写入GenAI语义约定请求属性
span.set_attribute("gen_ai.system", "openai")
span.set_attribute("gen_ai.request.model", model_name)
span.set_attribute("gen_ai.request.temperature", temperature)
span.set_attribute("gen_ai.request.max_tokens", 1024)
# 截断后的Prompt，避免上报超大属性
span.set_attribute("gen_ai.prompt", prompt[:500])
# 实际调用模型，代码省略
response = model_client.chat(model_name, prompt)
# 写入GenAI语义约定响应属性
span.set_attribute("gen_ai.response.id", response.id)
span.set_attribute("gen_ai.usage.input_tokens", response.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", response.output_tokens)
span.set_attribute("gen_ai.completion", response.text[:500])
# 可选：记录输出校验结果
span.set_attribute("app.guardrail.passed", response.guardrail_passed)
return response
这段代码看起来很简单，但注意几个关键点。
第一，Span名称的命名要符合官方语义约定。模型调用统一叫“llm.invoke”，不要自己发明“ask-ai”“call-model”这种名字，否则跨服务的关联和聚合会失败。
第二，gen_ai.prompt的上报内容务必做截断。一个50KB的Prompt全量上报，对存储和网络都是灾难。我见过一个团队因为没做截断，单月Trace存储成本直接翻了三倍。拆台的方案有两个：默认截断到500到1000字符；对特定采样率（比如1%）的Span做全量上报。这样在绝大多数场景能拿到统计规律，少数场景能拿到完整内容做案例分析。
第三，app.私有属性前缀用来放业务字段，和语义约定的gen_ai.前缀区分开。官方语义约定管的是跨系统的通用字段，你的业务字段属于自己域的内容，用自定义前缀不会和后续语义约定升级冲突。
4.4 指标埋点：三块必须设的大盘和一条告警公式
Span只是链路数据，实时监控和大盘展示还需要指标。我这里给三个必须做的基本维度，以及对应的PromQL思路（用类Prometheus语法表述，具体以你的后端支持为准）。
第一块大盘是“Token消耗趋势”。按模型名和时间维度聚合，输入Token和输出Token分别展示，方便对比。业务上这块大盘和成本直接挂钩的，财务部门也爱看这个。
第二块大盘是“推理服务性能”。按模型名聚合的P50/P95/P99延迟，以及成功率。重点提醒：不要只盯着P99，P50同样值钱——LLM服务是非对称负载，一次合成数据生成类的批量任务可以把P50打到三秒，但P99可能反而正常，因为单条长文本请求和普通请求的延迟分布差异极大。
第三块是“缓存命中率”。2026年越来越多的团队会在模型前面加语义缓存（把相同或相似的Prompt直接返回缓存结果），这能大幅降低成本和延迟，缓存命中率直接决定了成本优化空间。我做过一个真实项目，做语义缓存后，整体Token成本下降了四成左右，而观测维度上最难的就是衡量“哪些提示词该进缓存”，这块大盘帮了大忙。
告警方面给一条我踩过坑后总结的公式：Token消耗增速和推理错误率的关联告警。具体是，当输入Token增量和请求量增量的比值超过历史基线2倍，同时推理错误率没有同步上升，说明模型可能开始在长上下文中原地打转，典型例子是Agent陷入自循环。这个模式传统告警完全发现不了，但在生产环境里破坏力极大。我用这条规则提前拦截过三次线上事故。
4.5 在线推理与离线评估的双链路交叉验证
2026年还有一个特别值得重视的实践：把可观测性数据和离线评估打通。传统的质量评估是离线做的，用评测集跑模型打分，和线上数据完全没有关系。但这个模式有一个天生缺陷——离线评测集是“过去的好问题”，线上用户的问题不断演化，数据分布持续漂移。
我的做法是：让OpenTelemetry采集线上真实请求的Prompt、输出和Token信息（注意脱敏和合规），再定期分流一批线上数据到离线评测管道，用多维度评测工具给模型输出打分，最后将分数作为标签写回观测系统。一旦发现“某个模型版本的离线得分在下降，同时线上的输出长度在增加”，基本可以断定模型出现退化，应该提前介入而不是等用户投诉。
这也是2026年可观测性领域最令人兴奋的一个方向：系统不仅能告诉你“模型慢了”“模型贵了”，还能告诉你“质量下降了”。虽然这个链路还谈不上绝对成熟，但趋势已经非常明显。
5. 常见问题与排查技巧实录
5.1 疑难杂症速查表
直接整理成表，对照处理。
| 症状 | 可能原因 | 排查方法 | 处理方案 |
|---|---|---|---|
| Trace断链，只有单个模型Span | SDK采样策略默认关了 | 检查当前客户端和采样率配置 | 调整采样器为父级采样 |
| 模型已调用但Delay很长 | 服务端排队（推理队列饱和） | 查看是否有网关排队指标 | 扩容推理服务或调整限流 |
| Token数值和账单对不上 | 响应属性在异步任务里丢失 | 检查异步上下文的传递 | 用上下文管理器显式携带 |
| Prompt属性全部为空 | 截断逻辑错误或上报前被清空 | 检查直方图和日志 | 修正代理层的私有属性容器 |
| 数据量爆炸，存储成本翻倍 | 调试模式和全量采样误启用 | 检查Span导出器的配置 | 把始终采样改成尾部采样策略 |
5.2 排查实录：一个“幻觉率”异常升高的凌晨
分享一个我亲手处理过的真实场景（模拟项目X）。某天晚上，内容审核系统反馈“AI审核的误杀率突然从2%飙升到9%”，业务方怀疑模型被污染。从观测平台拉数据排查时，第一步看Trace的路由分布，发现流量被灰度了20%给一个新模型版本，这个版本在常规评测集上打了98分，远高于老版本。
但关键观测点出现了：新版本的输出Token平均长度比老版本高35%，且“审查结论为拒绝”的比例同步从8%升到了14%。再深入看Prompt上下文里的历史违规案例参考数，发现新版本会主动要求更多“类比案例”，然后过度泛化判定标准。
如果没有埋点，这个故障最多只能归因到“用户投诉变多”，但通过操作记录、Token消耗量和输出分布的变化，15分钟内就锁定了模型版本的问题。这个过程有力证明了“质量类问题必须通过数据组合判断才高效”。
5.3 高成本陷阱：这三个配置最容易烧钱
第一，全局开启从头采样但没设置比例。默认的采样器若误配始终采样（采样率1），高流量服务会迅速拉爆存储，我见过最夸张的一个案例，某团队上线三天后Trace存储费用超过了该月全部资源预算的一半。常规做法：明确开启1%到10%的头部采样，配合自定义规则对异常Span做强制完整采样。
第二，用CPU指标弹性伸缩推理服务。这是经典坑。CPU不涨但Token消耗暴涨的场景时有发生——模型在处理超长上下文时CPU占用可能不高，但内存带宽就是瓶颈。建议组合“推理延迟P99”和“Token吞吐量”两个指标配置弹性伸缩。
第三，日志全量输出到标准输出且用默认OTLP转发，导致磁盘吞吐被打爆。如果业务峰值是2000 QPS，每请求十条日志，每条1KB，每秒会产生20MB日志数据。建议批量处理后在进程级做日志采样，只保留WARN以上级别和与TraceID关联的日志。
6. 2026年之后的三个趋势判断
第一部分看完了，聊几个我在实际工作中观察到的明确趋势。
第一个趋势是“GenAI语义约定会快速收敛”。现在OpenTelemetry GenAI语义约定还在快速迭代，但到2026年末收敛速度会明显加快。企业如果现在就开始把自己的埋点模型往官方语义约定上靠，将来社区工具升级时兼容性会好很多，历史数据受益。反之，如果按自己的私有方案埋点，未来大量转移成本是可预见的。
第二个趋势是可观测性数据将成为“AI训练数据的一部分”。观测系统里沉淀的不仅仅是延迟和错误码，更是海量的“实际情况中什么样的Prompt会引发幻觉、什么样的响应流程会走偏”这些细节。如果把这些数据脱敏后反哺评测集，你的模型质量评估会越来越贴近真实生产状态。目前已经有一些团队在做这个方向，前期效果非常明显。
第三个趋势是“成本治理会成为观测平台的一等公民”。Token计费、语义缓存命中率、模型精简策略，这些东西在2026年的可观测平台里不再是“业务指标”，而是核心指标。平台默认就提供“按业务线拆分的Token账单”“按提示词聚类的需求分布”“缓存优化建议”等。谁先把“成本可观测”做进来，谁就掌握了未来运维的主动权。
7. 写在最后：从观测工具到反馈飞轮
如果只记住一句话，我建议是这个：2026年的可观测性，核心价值已经从“被动查因”转向“主动调优”。传统链路追踪帮你回答“系统刚才发生了什么”，生成式AI与OpenTelemetry结合的体系则能帮你回答“接下来怎样让模型输出更好、成本更低、体验更顺”。
这种转变在具体操作上有一个很明显的标志：你开始频繁做“链路数据和离线评估”的交叉验证，你开始用Prompt级别的质量分反馈去调整路由策略，你开始把Token消耗数据和用户留存数据放在同一个看板里分析。能达到这个状态的团队，已经不再是简单的“接入了OpenTelemetry”，而是真正把可观测性变成了驱动AI应用迭代的反馈飞轮。
我个人这两年有一个很深的体会：不要等平台团队把一切做好了再动手。哪怕第一周只做了Gateway层的模型调用采集，第二周加上了Token指标，第三周接上了日志关联，这套体系就已经在发挥作用了。可观测性建设和其他基础建设一样，最怕的不是晚起步，而是反复推倒重来。从OpenTelemetry这个标准底座开始，路是越走越宽的。