这是一个专门给LLM应用做遥测的开放标准，帮你把模型调用的耗时、token消耗、成本和错误率等数据统一采集起来。你将学到如何接入OpenTelemetry、对接各类可观测平台和自定义指标采集。适合正在运维大模型应用、想搞清楚每次调用花了多少钱、卡在哪里的工程团队使用，让LLM应用的可观测性不再是个黑盒。

岗位关联

需要学习OpenLLMetry标准化遥测，数据管道与模型训练的衔接需要MLOps能力。本篇涵盖MLOps/LLMOps、模型部署、CI/CD、版本管理，帮助你实现AI工程化交付。

目录
  1. 可视化演示
  2. OpenLLMetry标准定位与OpenTelemetry集成
  3. 遥测数据模型与语义约定
  4. 自动化采集与多框架接入
  5. 多后端对接与厂商中立架构
  6. 自定义指标采集与扩展机制
  7. AI 应用场景
  8. Python 演示
  9. 常见问答
  10. 常见误区
  11. 参考来源

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

OpenLLMetry标准定位与OpenTelemetry集成

OpenLLMetry是LLM应用遥测的开放标准规范，建立在OpenTelemetry之上。它不是另一个监控平台，而是定义了LLM调用数据应该如何采集和格式化，让遥测数据可以导出到任何兼容OpenTelemetry的后端，实现厂商中立。这类似于USB标准接口——不同设备都遵循同一接口规范，可以接入任何兼容的主机系统。

OpenLLMetry定义了LLM调用的Span属性规范，如llm.model（模型名称）、llm.token_count（Token用量）、llm.cost（调用成本）等。这些标准属性确保无论使用哪个LLM框架（OpenAI、Anthropic、LangChain），采集的遥测数据格式都是一致的。目标是让LLM遥测数据与现有可观测性基础设施无缝集成，而非构建独立的监控生态。

OpenLLMetry与LangSmith、Langfuse等平台型产品不构成竞争关系。OpenLLMetry是采集标准，这些平台是存储和分析后端，两者互补——可以用OpenLLMetry标准化采集，再将数据导出到LangSmith或Langfuse进行分析。接入OpenLLMetry不会限制使用任何特定平台，反而通过标准化采集增强了对后端的选择灵活性。

标准规范与平台产品的核心区别在于：标准定义数据格式和采集方式，平台提供存储、分析和可视化能力。OpenLLMetry只负责采集层的标准化，数据导出到外部后端进行存储和分析。这种分层设计使采集和存储完全解耦，更换存储后端不影响采集逻辑，反之亦然。

遥测数据模型与语义约定

OpenLLMetry的核心贡献是定义了LLM遥测的语义约定（semantic conventions）。语义约定规定了LLM调用数据的标准字段名称和格式，类似于快递单的统一格式——不管哪家快递公司都填写相同的字段方便系统对接。这确保了不同框架采集的数据具有一致的字段和格式，便于跨工具分析。

LLM特有的Span属性包括：llm.model记录使用的模型名称（如gpt-4、claude-3）；llm.token_count.prompt和llm.token_count.completion分别记录输入和输出Token用量；llm.cost记录基于模型定价和Token用量计算的调用成本；llm.response记录响应内容。这些属性完整覆盖了LLM调用中需要监控的关键维度。

OpenTelemetry最初为传统微服务设计，其标准Span属性（如http.method、db.statement）不包含LLM特有指标。但OpenTelemetry的语义约定是可扩展的，OpenLLMetry正是在此基础上扩展了LLM特有属性。这些扩展属性遵循OpenTelemetry的命名规范（点分隔命名空间llm.xxx），与标准属性完全兼容，不会破坏已有消费者。

语义约定支持request和response两个维度记录完整的调用上下文。request维度记录用户输入的prompt、模型参数（temperature、max_tokens等）和请求时间戳；response维度记录模型输出的内容、Token用量、延迟和错误信息。两个维度组合形成完整的LLM调用画像，支持从请求到响应的全链路分析。

自动化采集与多框架接入

OpenLLMetry提供自动注入库，支持OpenAI、Anthropic、LangChain等主流框架零代码接入。开发者只需引入库并调用auto_instrument()，即可自动为已导入的LLM框架添加遥测埋点。这大大降低了接入门槛——无需手动在每个LLM调用处添加采集代码，减少了开发者的负担和出错可能。

自动注入通过两种方式实现：Python版本通过monkey-patch在运行时替换LLM框架的原始方法，在方法调用前后插入埋点逻辑；Java版本通过JVM agent在字节码层面自动织入埋点代码。两种方式都不修改应用源代码，对业务逻辑完全透明，开发者可以像往常一样调用LLM API，遥测数据在后台自动采集。

自动采集的数据包括请求参数（prompt、模型参数）、响应内容（生成文本、finish_reason）、Token消耗（input/output token数）和调用延迟（首Token延迟、总延迟）。这些数据自动填充到标准Span属性中，无需开发者手动设置。对于流式响应，自动注入库还能逐帧记录Token推送的时间戳，支持流式生成延迟分析。

自动注入的monkey-patch机制虽然强大，但需注意框架版本兼容性。当LLM框架升级修改了内部方法签名时，自动注入库需要同步更新以匹配新的方法接口。OpenLLMetry社区会跟踪主流框架的版本变化并及时发布兼容更新，开发者应保持自动注入库版本与LLM框架版本的匹配。

多后端对接与厂商中立架构

OpenLLMetry的厂商中立架构通过OTLP（OpenTelemetry Protocol）协议实现。OTLP是OpenTelemetry的标准导出协议，遥测数据通过OTLP发送到任何兼容后端。这类似于使用标准电源插座——更换电器品牌不需要重新布线只需插上即可使用。

OpenLLMetry支持同时导出到多个后端，如Datadog做监控、Jaeger做链路追踪、Prometheus做指标存储。实现方式是配置多个OTLP导出器，每个导出器对接一个后端。多个导出器独立工作，各自发送完整的遥测数据，保证各后端数据的一致性。当需要新增后端时只需添加一个导出器配置，无需修改应用代码。

更换后端只需修改导出器配置（endpoint地址、认证信息等），无需修改应用代码。这彻底解决了厂商锁定问题——团队可以根据需求灵活选择或切换监控工具，采集逻辑与存储分析完全解耦。例如从Datadog迁移到自建Prometheus时，仅需将OTLP导出器的endpoint从Datadog地址改为Prometheus地址。

多后端导出的背压处理通过异步队列和丢弃策略实现。当某个后端响应慢时，导出器将数据放入异步队列避免阻塞采集线程；队列满时按策略丢弃旧数据防止内存溢出。BatchSpanProcessor批量积累Span后统一导出，降低网络请求频率，平衡导出延迟和网络开销。

自定义指标采集与扩展机制

OpenLLMetry不仅提供标准化的遥测字段，还支持扩展自定义属性和指标。开发者可以在标准属性基础上添加业务相关的自定义字段，如user.id（用户标识）、business.tag（业务标签）、custom.quality_score（质量评分）等。这些自定义属性帮助将LLM调用的遥测数据与业务上下文关联，支持按业务维度分析。

自定义属性使用custom.前缀与标准llm.前缀的命名空间隔离，避免命名冲突。扩展机制保持向后兼容——新增自定义字段不影响标准数据格式和已有消费者。后端系统可以忽略不认识的自定义字段，只处理标准字段；需要自定义字段的分析场景则可以按命名空间过滤提取。

OpenLLMetry提供自定义指标采集接口，支持业务特定的评估指标上报。例如可以上报RAG检索准确率、用户满意度评分、幻觉检测置信度等业务指标，这些指标与标准遥测数据关联到同一Span，支持从技术指标下钻到业务指标的联合分析。自定义指标通过metric API上报，与trace数据共享context。

扩展机制的设计哲学是标准与灵活并存：标准属性确保跨工具互操作性，自定义属性适应个性化场景。开发者应优先使用标准属性保证兼容性，仅在标准属性无法覆盖时才添加自定义属性。这种分层设计既满足了标准化需求，又不限制业务特定的监控需求，使OpenLLMetry能够适应多样化的LLM应用场景。

AI 应用场景

OpenLLMetry统一LLM遥测数据采集

阶段：监控运维

解决的问题：LLM可观测性工具厂商锁定严重，遥测数据格式不统一难以跨平台迁移。通过OpenLLMetry标准化采集实现厂商中立的遥测架构。

具体案例：某企业使用OpenLLMetry标准化所有LLM调用的遥测数据，同时对接Datadog和Jaeger两个后端，当需要从Datadog迁移到自建Prometheus时无需修改应用代码，仅更换OTLP导出器配置即可完成迁移。开发团队通过自动注入库零代码接入OpenAI和LangChain框架，自动采集model、token_count、cost等标准属性。同时通过自定义属性添加用户ID和业务标签，实现按业务线分维度的LLM调用分析。新增Grafana看板时仅添加一个OTLP导出器即可，实现了厂商中立的遥测架构。

Python 演示

python52 行
from opentelemetry import tracefrom opentelemetry.sdk.trace import TracerProviderfrom opentelemetry.sdk.trace.export import BatchSpanProcessorfrom opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporterfrom opentelemetry.sdk.resources import Resource # OpenLLMetry 自动注入库from openllmetry import auto_instrument # 1. 配置 TracerProvider（标识服务信息）resource = Resource.create({    "service.name": "llm-inference-service",    "service.version": "1.0.0",})provider = TracerProvider(resource=resource) # 2. 配置 OTLP 导出器（可对接任意 OpenTelemetry 兼容后端）otlp_exporter = OTLPSpanExporter(    endpoint="http://localhost:4317",    insecure=True,)provider.add_span_processor(BatchSpanProcessor(otlp_exporter))trace.set_tracer_provider(provider) # 3. 自动注入 LLM 框架调用埋点auto_instrument() # 4. 调用 OpenAI（遥测数据自动采集）import openairesponse = openai.ChatCompletion.create(    model="gpt-4",    messages=[{"role": "user", "content": "解释OpenLLMetry标准"}],    max_tokens=200,) # 自动采集的 Span 属性:#   llm.model = "gpt-4"#   llm.token_count.prompt = 输入token数#   llm.token_count.completion = 输出token数#   llm.cost = 调用成本#   llm.response = 响应内容 # 5. 自定义属性扩展（业务标签）tracer = trace.get_tracer(__name__)with tracer.start_as_current_span("business_logic") as span:    span.set_attribute("user.id", "user-12345")    span.set_attribute("business.tag", "knowledge_qa")    span.set_attribute("custom.quality_score", 0.92)    result = response.choices[0].message.content print(f"Response: {result[:80]}...")print("Telemetry exported via OTLP")
目的：演示OpenLLMetry的完整使用流程，包括TracerProvider配置、OTLP导出器设置、自动注入LLM框架埋点、标准Span属性自动采集和自定义业务属性扩展。
  1. from openllmetry import auto_instrument导入OpenLLMetry自动注入库，通过monkey-patch自动为LLM框架添加遥测埋点
  2. resource = Resource.create({创建Resource标识服务信息，service.name和version用于后端区分不同服务
  3. "service.name": "llm-inference-service",设置服务名称，所有遥测数据将标记此来源
  4. otlp_exporter = OTLPSpanExporter(创建OTLP导出器，通过gRPC协议将Span数据发送到OpenTelemetry兼容后端
  5. endpoint="http://localhost:4317",OTLP gRPC端点地址，4317是OpenTelemetry Collector的标准端口
  6. provider.add_span_processor(BatchSpanProcessor(otlp_exporter))添加批量Span处理器，自动批量导出Span降低网络开销
  7. trace.set_tracer_provider(provider)设置全局TracerProvider，所有后续trace操作使用此配置
  8. auto_instrument()执行自动注入，对openai等已导入的LLM框架自动添加遥测埋点
  9. response = openai.ChatCompletion.create(调用OpenAI API，OpenLLMetry自动创建Span并采集model/token_count/cost等属性
  10. # llm.model = "gpt-4"自动采集的模型名称属性，记录使用的LLM模型
  11. # llm.token_count.prompt = 输入token数自动采集的输入Token用量，用于成本监控和用量分析
  12. # llm.cost = 调用成本自动采集的调用成本，基于模型定价和Token用量计算
  13. with tracer.start_as_current_span("business_logic") as span:创建自定义Span记录业务逻辑，与LLM调用Span形成调用链
  14. span.set_attribute("user.id", "user-12345")添加自定义用户ID属性，不影响标准属性命名空间
  15. span.set_attribute("custom.quality_score", 0.92)添加自定义质量评分指标，扩展机制保持向后兼容

常见问答

OpenLLMetry和LangSmith、Langfuse等监控平台有什么区别？
OpenLLMetry不是监控平台，而是LLM遥测数据的采集标准规范。它建立在OpenTelemetry之上，定义了LLM调用数据应该如何采集和格式化（如model、token_count、cost等Span属性的语义约定）。遥测数据通过OTLP协议导出到任意OpenTelemetry兼容后端（如Datadog、Jaeger、Prometheus）进行存储和分析。这使得LLM应用的可观测性数据与现有基础设施无缝集成，避免厂商锁定。
OpenLLMetry如何解决厂商锁定问题？
OpenLLMetry通过OTLP协议实现厂商中立架构。遥测数据可以同时配置多个OTLP导出器，每个导出器对接一个后端平台。当需要从Datadog迁移到自建Prometheus时，只需修改导出器的endpoint配置，无需修改任何应用代码。这种架构彻底解决了厂商锁定问题——采集标准和存储分析平台完全解耦，团队可以根据需求灵活切换或同时使用多个后端。
OpenTelemetry能覆盖LLM特有的Token和成本指标吗？
OpenTelemetry最初为传统微服务设计，其标准Span属性（如http.method、db.statement）确实不包含LLM特有指标。但OpenTelemetry的语义约定是可扩展的，OpenLLMetry正是在此基础上扩展了LLM特有的Span属性：llm.model记录模型名称、llm.token_count.prompt和llm.token_count.completion记录输入输出Token用量、llm.cost记录调用成本。这些扩展属性遵循OpenTelemetry的命名规范（点分隔命名空间），与标准属性完全兼容。
OpenLLMetry的自动注入是如何实现的？
OpenLLMetry的自动注入库通过monkey-patch机制在运行时替换LLM框架（如openai、langchain）的原始方法，在方法调用前后自动插入遥测埋点逻辑。开发者只需调用auto_instrument()并配置OTLP导出器，即可自动采集请求参数、响应内容、Token消耗和调用延迟等完整遥测数据，无需手动修改任何业务代码。Java版本通过JVM agent实现字节码级别的自动注入。
如何在OpenLLMetry标准属性之外添加自定义业务指标？
OpenLLMetry在标准属性基础上支持扩展自定义属性。开发者可以通过span.set_attribute()添加业务相关的自定义字段，如user.id、business.tag、custom.quality_score等。自定义属性使用custom.前缀与标准llm.前缀的命名空间隔离，避免命名冲突。扩展机制保持向后兼容——新增自定义字段不影响标准数据格式和已有消费者，既满足标准化需求又适应个性化场景。

常见误区

误区OpenLLMetry是另一个LLM监控平台与LangSmith竞争

正解OpenLLMetry是遥测数据采集标准规范，不是监控平台，数据导出到外部后端进行存储和分析

为何常见：LLM可观测性领域多为平台型产品，容易将标准误认为平台

误区接入OpenLLMetry后就不能用LangSmith或Langfuse了

正解OpenLLMetry是采集标准，与LangSmith等平台互补，可先用OpenLLMetry采集再导出到任意平台

为何常见：容易将标准与平台理解为互斥关系，忽略了标准与平台的互补性

误区OpenTelemetry太通用无法覆盖LLM特有的Token和成本指标

正解OpenLLMetry在OpenTelemetry基础上扩展了LLM特有属性，完整覆盖Token和成本等LLM指标

为何常见：OpenTelemetry最初为传统微服务设计，容易忽略其可扩展性

参考来源