奇链 奇链
← 文章 / 未分类
signoz 3小时前 · 2026-09-16 16:02:18 · 1 阅读

大语言模型可观测性概述

LLM 可观测性是指从调用大语言模型（LLM）的应用程序中采集追踪（Traces）、指标（Metrics）和日志（Logs），以洞察每次模型调用的具体行为、耗时、Token 消耗量及失败位置。在 LLM 应用中，单个用户请求往往会扇出（fan out）为检索步骤、多次模型调用、工具调用及重试操作。若缺乏相应的插桩（Instrumentation），这些复杂过程将坍缩为一块不透明的延迟数据和账单上的一行记录。

SigNoz 采用 OpenTelemetry 而非专有 Agent 来实现这一目标。应用程序通过标准 OpenTelemetry 库发出 gen_ai.* 的 Span 和指标，经由 OTLP 协议导出，随后 SigNoz 将其与应用程序的其他遥测数据一同存储和查询。下方的集成支持 55 个模型提供商、Agent 框架及网关。

支持的集成

LLM 可观测性涵盖的内容

调用 LLM 本质上是向一个非确定性、按量计费且相对缓慢的服务发起网络请求。这种特性决定了它值得与普通 HTTP 依赖分开进行独立插桩。

调用链中的 Traces 和 Spans。分析单元是完整的请求，而非单次模型调用。检索增强生成（RAG）请求通常会生成 embedding span、向量搜索 span、对话补全 span，以及用于重排序或摘要的第二个补全 span。将这些建模为单一 trace，可以看清实际耗时发生在哪个阶段。在 SigNoz 中，这些 span 与 Web 框架和数据库的 span 一起显示在 Traces 探索器中，使 LLM 调用与提供数据的 SQL 查询处于同一条瀑布流中。

Token 用量。每次调用都会记录输入和输出 token 数量。由于 token 是计费单位，按模型和代码路径归类的 token 计数最接近实时的成本指标。支持提示缓存（prompt caching）的服务商会单独统计缓存输入 token，这很重要，因为它们通常按更低费率计费。

延迟。LLM 延迟呈双峰分布，且受输出长度影响极大，因此平均值几乎毫无参考价值。应追踪百分位值，对于流式响应，需单独记录首个 token 时间（TTFT）与总时长。一个在 300 ms 内开始流式输出并在 8 秒内完成的响应感觉很快；而一个延迟 8 秒后才一次性输出完整答案的响应，尽管总时长相同，体验却截然相反。

错误。限流（HTTP 429）、上下文长度溢出、内容过滤拒绝、上游 5xx 响应以及客户端超时，这些故障的发生机制各不相同，应对方式也需区别对待。为每个 span 记录具体的错误类别，有助于区分“正在被限流”和“模型拒绝了该 prompt”。

成本归因。仅凭 token 数量无法得知是谁在消费。将支出归因到模型、租户、功能或 prompt 版本，能将单一的月度总费用拆解为可执行的优化依据。

模型与 prompt 归因。需要同时记录请求的模型和实际响应的模型，因为服务提供商常在类似 gpt-4 的名称背后别名映射具体版本。记录 prompt 模板名称和版本，便于对比不同修订版的质量与成本。

检索步骤。对于 RAG 应用，检索阶段是回答质量不佳的常见根源。查询延迟、返回文档数量以及空结果集，是区分检索失败与生成失败的关键信号。

Agent 与工具调用可见性。Agent 框架呈循环结构：模型选择工具、工具执行、结果反馈、模型再次决策。将每次工具执行作为独立 span 进行埋点，可暴露失控循环、静默失败的工具以及每次请求的迭代次数。

使用 OpenTelemetry 为 LLM 应用埋点

埋点机制与其他 OpenTelemetry 服务无异。库在运行时 patch LLM 客户端，将每次调用包裹为 span，附加属性信息，并通过 OTLP 将完成的 span 发送至导出器，最后传到 SigNoz。

自动埋点

自动埋点是最主流的方式，覆盖大多数应用场景。安装对应的埋点包后，它会自动 patch 提供商 SDK，使其产生的每次调用都生成 span，而无需修改应用代码。由于几乎所有 LLM 流量都经由少数几个客户端库流转，这种方案通常很有效。

自动埋点主要记录机械性事实：使用哪个模型、消耗多少 token、耗时多久、是否失败。它无法感知应用自身的语义信息，例如发起请求的是哪个租户、或用户属于哪个实验分组。

手动埋点

手动埋点可以填补这个空缺。你可以用 OpenTelemetry API 为应用特有的环节创建 span，比如文档分块步骤或业务层面的“处理工单”操作，也可以给已有的 span 添加自定义属性。实践中，大多数团队会两者并用：自动埋点负责 provider 调用，手动 span 负责包裹其上的应用逻辑。

Instrumentation 库

目前主流的 LLM 专用 instrumentation 主要来自三个社区项目。它们都通过 OTLP 输出标准 OpenTelemetry span，因此都能与 SigNoz 配合使用。

部分 provider 也直接由 OpenTelemetry contrib 仓库维护的 instrumentation 覆盖，比如 opentelemetry-instrumentation-openai-v2。只要存在官方 instrumentation，集成指南都会优先推荐它。

无需厂商 SDK

SigNoz 直接接收 OTLP 数据，没有专门的 LLM agent，也不需要在应用中安装任何 SigNoz SDK。任何能通过 HTTP 或 gRPC 发送 OTLP 的工具都可以上报数据。这带来两点值得明确的好处：你可以自由选择最契合自己技术栈的 instrumentation 库，甚至混用多个；而且由于数据是标准 OpenTelemetry 格式，日后迁移到其他平台只需换个 endpoint，不必重新埋点。

Exporter 配置与其他 OpenTelemetry 服务完全一致：

Copy
OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.<region>.signoz.cloud:443"
OTEL_EXPORTER_OTLP_HEADERS="signoz-ingestion-key=<your-ingestion-key>"<
原始来源： signoz

评论 (0)