AI 基础设施的可观测性

AI 可观测性是保障 AI 应用高效、安全、稳定运行的核心能力。通过端到端链路追踪、全栈指标采集与自动化评估，开发者能够精准定位性能瓶颈、控制成本并提升内容质量。

AI 可观测的挑战与应对方案

随着 AI 应用的广泛部署和复杂性提升，深入洞察其内部行为变得尤为重要。AI 可观测性应运而生，通过方法论与工具体系，帮助开发者监控性能、调试问题，并提升内容输出的可用性、安全性与可靠性。

什么是 AI 可观测

AI 可观测性是一系列让工程师全面洞察基于大语言模型（LLM）应用的实践与工具。它不仅追踪系统性能，更深入探究模型“在做什么”以及“为什么这么做”。这种方法对于保障 AI 应用的健康、性能和安全至关重要。

AI 应用具有非确定性，即使相同的提示在不同运行中也可能产生不同输出。如果缺乏可观测能力，遇到幻觉、虚假等问题时难以定位根因。优秀的可观测工具会记录每次提示与响应、追踪使用模式并标记异常，为工程师提供宝贵洞察，便于修复不准确之处、优化性能并消除安全风险。

可观测 vs. 监控：从“是什么”到“为什么”

在 AI 应用中，需区分“可观测性”与“监控”：

• 监控：关注“发生了什么”
  监控聚焦于关键性能指标（KPIs）和系统健康状况，如 API 响应时间、错误率、请求吞吐量和 Token 使用量等。一旦指标异常，监控工具会发出警报，帮助工程师及时响应。

• 可观测性：探究“为什么”
  可观测性不仅采集性能指标，还将其与日志、事件和链路信息（Trace）关联。每次请求都可被追溯，包括调用工具的参数、发送给大模型的提示词、中间步骤及最终输出。这样，遇到错误时可观测工具能提供丰富的排查数据和上下文，帮助定位根因。

监控告诉你“出问题了”，可观测性则帮助理解系统内部发生了什么以及如何修复。两者缺一不可，监控提供预警，可观测性提供深度诊断。

AI 可观测应对的核心挑战

AI 应用面临四大独特挑战：

• 性能与可靠性问题
  大模型资源密集，延迟和瓶颈常见。可观测性将各组件数据关联，便于定位延迟根源，简化复杂系统调试。

• 成本问题
  大模型服务按 Token 计费，若无监控成本易失控。可观测工具追踪每个请求的 Token 数和总用量，异常时及时预警，帮助优化提示或设置限制。

• 质量问题
  大模型输出可能继承偏见或产生幻觉。可观测性通过自动评估工具检测输入输出中的不当、不准确内容，辅助工程师及时干预。

• 新颖失败模式
  LLM 系统以独特方式失败，包括沉默错误（模型返回自信但错误答案）、性能漂移（上下文、数据或微调演变时性能下降）、无限成本（Token 增长和重试意外膨胀支出）、不透明推理（工具调用或路由决策难以审计）、合规差距（缺失血统或 PII 可追溯性阻碍治理）。这些问题在传统监控中难以察觉，需要可观测性揭示未知和根本原因。

AI 可观测解决方案的关键能力

高效的 AI 可观测解决方案应具备以下能力：

• 端到端全链路追踪
  提供日志采集和链路追踪，可视化展示请求在 AI 应用中的执行路径，支持历史对话灵活查询与筛选。

• 全栈可观测
  覆盖应用、AI 网关、推理引擎三大维度，观测响应延迟、吞吐量、Token 消耗、错误率和资源使用等，指标异常时自动告警。

• 自动化评估功能
  引入评估 Agent，对输入输出自动评估，检测幻觉、不一致或答案质量下降等问题，集成评估模板便于快速评估常见质量和安全问题。

• 核心可观测目标
  聚焦可靠性（检测和减少延迟、速率限制和提供者失败）、质量（衡量事实准确性、接地和评估性能）、安全性（实时监控越狱、毒性和 PII 泄露）、成本（跟踪 Token 使用、重试和预算遵守）、治理（确保每个请求可追溯和可审计）。

LLM 可观测性的参考架构

LLM 可观测性从清晰理解每个请求背后的移动部件开始。从用户输入到模型响应，每个跃点生成形成可观测性骨干的数据。

核心组件

• 1. 客户端或应用层
  提示起源的地方——Web 应用、内部工具或 API 消费者。发送上下文（用户、会话、工作空间）到网关以进行跟踪关联。

• 2. AI 网关或代理
  认证、路由、速率限制、缓存和护栏的控制平面。捕获请求元数据、延迟、模型选择和成本。执行策略并将丰富的遥测转发到可观测性堆栈。

• 3. 模型提供者
  任何托管或自管理的 LLM 端点（OpenAI、Anthropic、Azure OpenAI 等）。发出响应级指标：完成延迟、Token 计数、错误代码。

• 4. 工具和函数调用（MCP / 外部 API）
  在 Agent 运行期间执行动作。产生细粒度跟踪：工具延迟、成功率、有效载荷大小、错误。

• 5. 护栏和审核服务
  验证安全性、合规性和内容质量。发出判决（通过/失败）、类别和严重性。

• 6. 评估和评分系统
  批次或在线评估，对事实性、相关性和帮助性进行评分。将持续质量信号反馈到仪表板和路由逻辑。

• 7. 可观测性数据存储和可视化
  中央日志或遥测接收器（OpenTelemetry、ClickHouse、ELK 或自定义）。通过request_id关联跟踪并聚合 KPI。呈现仪表板、警报和审计视图。

数据流

1. 用户请求 → 网关
   捕获元数据：user_id、workspace、提示哈希、输入 Token。

2. 网关 → 护栏
   检查输入安全性；添加判决。

3. 网关 → 模型提供者
   记录检索延迟、文档计数和模型调用持续时间。

4. 模型 → 工具/MCP 调用
   每个调用成为带有工具名称、延迟和成功标志的子跨度。

5. 模型 → 输出护栏 → 客户端
   输出审核和成本计算；响应与完整跟踪 ID 一起返回。

6. 遥测导出器 → 可观测性后端
   发送批次跨度、指标和事件以进行分析和可视化。

好的 LLM 可观测性特征

• 端到端可追溯性：每个请求和子组件在一个时间线中可见。
• 关联维度：模型、用户、工具、工作空间和成本一起连接。
• 统一模式：日志和指标中的通用字段名称。
• 实时可见性：仪表板在请求完成后几秒内更新。
• 治理对齐：审计跟踪包括谁访问了什么数据以及为什么。

LLM 可观测性的遥测模型和模式

每个可观测的 AI 系统依赖于一致的、结构化的数据。统一的遥测模型确保网关、工具、检索和模型的日志可以关联成可靠性、成本和质量的单一视图。

在其核心，LLM 可观测性跟踪三种信号：

• 跟踪——每个请求路径跨越提示、检索、工具和护栏。
• 指标——聚合性能、成本和质量措施。
• 事件——需要审查的安全或治理警报。

所有这些都通过共享跟踪或请求 ID 连接，形成一个关于发生了什么、为什么以及成本多少的连贯记录。

关键遥测类别

• 识别和关联：捕获每个请求和子操作的唯一 ID，以便将用户会话、工具调用和重试链接到同一跟踪。
• 用户和工作空间上下文：记录哪个用户、团队或工作空间触发了请求。这启用每租户仪表板、成本归属和使用审计。
• 模型和提供者详情：包括模型名称、提供者和版本，以测量一致性、性能方差以及升级或路由更改后的回归。
• 提示和上下文元数据：跟踪使用了哪个提示模板或上下文窗口，以及它有多大。这对于分析质量漂移和 Token 使用至关重要。
• 性能指标：测量每个跨度的延迟、重试计数、缓存命中和吞吐量——网关、检索、模型和工具。
• Token 和成本指标：记录输入/输出 Token 计数、总成本和派生比率（每个响应的成本、每个成功或每个 Token）。此数据馈送成本可观测性和预算编制。
• 护栏和安全信号：存储护栏判决、类别（PII、毒性、幻觉）和严重性级别，以监控对安全和政策控制的遵守。
• 工具和 MCP 遥测：跟踪调用了哪些工具、它们花了多长时间、成功率和失败。Agent 可观测性和调试工具链的关键。
• 评估结果：存储评估数据集名称、分数和通过/失败结果，以将可观测性指标与质量基准连接。
• 治理和驻留属性：记录区域、数据处理标签和政策指标，以实现合规性和审计准备。
• 错误和 fallback 信息：包括错误代码、消息和重试原因，以支持事件响应和提供者端责任。

为什么标准化重要

• 启用跨团队仪表板，其中可靠性、成本和安全指标对齐。
• 简化分析，因为每个请求遵循相同模式。
• 提供支持工程、治理和财务用例的单一数据模型，而无重复。
• 使多提供者路由可审计和可解释。

LLM 系统的可观测性 KPI

一旦遥测到位，团队可以将原始数据转化为有意义的性能标准。正确的关键绩效指标 (KPI) 将技术健康、模型质量和业务成果对齐。

LLM 可观测性的 KPI 类别

• 可靠性 KPI
  衡量系统成功响应和一致的能力。包括成功率（2xx 等效响应的百分比）、P95 延迟和方差、速率限制命中频率、提供者正常运行时间和故障转移成功、重试计数每请求。

• 质量 KPI
  衡量模型输出有多准确、接地和有帮助。包括评估通过率（事实性、相关性、正确性）、检索接地成功率、人接受或 QA 分数、模型更新后的回归增量。

• 安全性 KPI
  确保负责任和政策合规的输出。包括护栏通过率、越狱 / PII / 毒性事件频率、审核中假阳性 vs 假阴性比率、检测和解决安全违规的时间。

• 成本 KPI
  跟踪效率和预算遵守。包括每个请求 / 用户 / 工作空间的平均成本、按模型和提供者的 Token 使用、每个成功完成的成本、每月支出 vs 预算阈值。

• 治理 KPI
  将可观测性与审计和合规就绪性链接。包括具有完整跟踪覆盖的请求百分比、标记有数据驻留或政策标签的请求、审计完整性（具有血统和跟踪元数据的请求）、未分类或缺失跟踪事件的数量。

端到端全链路追踪

典型 LLM 应用架构包含用户终端、认证模块、会话管理、对话服务、大模型路由、流程编排等。模型推理应用还可能对接不同大模型服务、外部工具、向量数据库和缓存等。

为应对链路复杂性、保障 SLA 和用户体验，需要具备以下可观测能力：

• 标准化数据语义规范（如 LLM Trace/Metrics 领域化语义，记录 Input、Output、Prompt、Token、TTFT、TPOT 等关键信息）
• 低成本高质量数据采集（如 OpenTelemetry Agent 实现无侵入采集）
• 端到端全链路追踪（基于 OpenTelemetry W3C 协议，实现用户终端到模型推理层的完整链路追踪）

端到端全链路追踪的实现方式

基于 OpenTelemetry 标准，通过 Trace 领域化语义增强、低成本高质量数据采集和标准化协议透传，实现从用户终端到模型推理层的完整调用链路追踪。

• 领域化 Trace 语义
  以会话串联用户交互过程，Trace 承载全链路交互节点，定义 Input、Output、Prompt、Token、TTFT、TPOT 等字段，便于性能和成本分析。

• 多语言兼容
  支持 Python/Java/Go 等多客户端接入，增强领域语义规范与数据采集，提供多种性能诊断数据。

• 标准化协议
  兼容 OpenTelemetry W3C 协议，实现跨语言、跨组件链路透传。

核心技术路径

1. 链路插桩技术

   • Python 探针：采用装饰器和 monkeypatch 实现无侵入埋点，支持主流框架自动采集调用参数、Token 数、TTFT/TPOT 等指标。
   • Java 探针：通过字节码增强拦截模型调用链，支持 Dubbo/RPC 调用与 LLM 调用关联分析。
   • Go 探针：编译时插桩，自动为常用框架埋点，注入可观测数据采集逻辑。
   • 其他语言通过 OpenTelemetry 框架支持。

2. 链路采集与加工

   • 统一数据处理链路，标准化可观测模型和存储，支持 Trace 直连上报和日志转 Trace。
   • 针对流式场景，采用客户端分段采集 + 服务端合并还原，平衡性能与分析易用性。

3. LLM Trace 查询与分析

   • 通过 TraceID 串联用户请求路径，展示 LLM 调用输入/输出、Prompt 模板、模型参数。
   • 支持按状态、耗时、Span 类型筛选，基于大模型实现智能诊断，自动定位瓶颈并提供优化建议。

全栈可观测：应用可观测

上一节介绍了端到端全链路追踪的实现方式和技术路径，为全栈可观测奠定基础。本节从应用、AI 网关、推理引擎三个维度，分享全栈可观测的场景、能力与实践。

AI 原生应用开发的痛点

在智能体与 MCP 应用开发中，常见痛点包括：

• 工具选择盲区：Agent 可能选择不合适的工具，缺乏可视化分析决策过程的手段。
• 错误排查困难：工具调用参数错误难以快速定位根因。
• Token 消耗黑洞：多轮交互易产生大量 Token 消耗，缺乏实时成本监控。
• 循环调用陷阱：Agent 可能陷入循环调用，难以及时发现和中断异常行为。

AI 原生应用可观测能力要求

AI 应用运行过程中接入全链路可观测，应具备以下能力：

• 零代码接入，开箱即用的监控能力。
• 可视化工具选择过程，深度集成 MCP 协议。
• 精准故障定位，通过链路信息快速锁定问题根源。
• Token 成本分析，精确监控 Token 使用量及成本。
• 端到端链路追踪，完整展示调用链路，快速定位异常模式。

场景演示

以智能日志分析助手为例，展示如何监控基于 LangChain 的 Agent 及其调用的 MCP 服务器。

1. 启动 SLS MCP 服务器
   在终端执行命令启动本地 MCP 服务器。

2. 启动 LangChain Agent 程序
   创建 Agent，向其提问，Agent 使用 SLS MCP 服务处理日志分析请求。

3. Agent 观测
   打开可观测平台（如阿里云 ARMS），查看 LangGraph 的 Span 列表，分析调用链路、输入输出、Token 消耗等。

通过 Trace 详情可看到 Agent 的详细执行过程，包括 LLM 和 MCPServer 的调用及输入输出，便于分析 Token 消耗和性能瓶颈。

本节展示了通过常见智能体框架搭建 AI 原生应用时的典型问题，以及如何利用可观测能力实现全流程监控。下一节将介绍 AI 网关的可观测。

全栈可观测：AI 网关可观测

AI 网关作为统一接入与治理中枢，承载模型路由、鉴权、限流、缓存等关键能力。其运行状态直接影响 AI 应用的质量与效率。构建围绕 AI 网关的可观测体系，实现对请求流量、资源消耗、安全风险与治理策略的全面监控，是保障 AI 能力可靠输出的核心基础。

观测场景：AI 组件的多维可观测需求

AI 组件的可观测性涵盖性能、资源、安全、成本、治理等多个层面。以下五个典型场景揭示企业在使用 AI 网关过程中的可观测需求：

1. 性能与稳定性监控
   采集 QPS、请求成功率、响应时间、流式与非流式请求分布等指标，支持实时监控与告警。

2. 资源消耗与成本分析
   统计每个 API、消费者、模型的 Token 消耗，结合缓存命中率评估成本节省效果。

3. 安全与合规审计
   记录内容安全拦截日志、风险类型统计、风险消费者统计，满足合规要求。

4. 治理策略执行追踪
   监控限流、缓存、Fallback 等策略的执行效果，验证治理策略落地。

5. 多租户与权限治理
   记录消费者身份，实现调用者可追溯，支持异常检测与资源配额管理。

观测实践：基于 AI 网关的可观测体系构建

要实现上述场景，需构建完整的可观测实践体系：

• 观测数据采集
  指标采集（如 Prometheus）、日志采集（记录请求上下文、状态码、模型名称等）。

• 可视化监控
  构建多维度、分层级仪表盘，实现从全局到明细的闭环管理。

• 深度分析
  利用日志查询和 SQL 分析，灵活检索和挖掘异常模式。

• 智能告警与自动化响应
  基于关键指标设置告警规则，联动自动化脚本进行初步处置。

• 成本优化与治理闭环
  定期生成资源使用报告，制定优化策略，形成“监控 → 分析 → 优化 → 再监控”的闭环。

AI 网关作为可观测体系的核心载体，正在重新定义企业对 AI 服务的管理方式。

全栈可观测：推理引擎可观测

LLM 推理引擎是 AI 服务基础架构中的关键组件，负责接收提示词并生成响应。以 vLLM 为例，其架构包括 API Server、Engine、GPU Worker，可单进程或分布式部署。

推理引擎需要观测什么

推理引擎包含多个组件，其可观测性对于监控性能、检测问题和优化系统至关重要。常见观测项包括 API Server、模型输入输出、推理过程和引擎状态等。

推理引擎可观测实践

首 Token 时间（TTFT）对用户体验影响较大。TTFT 受提示词长度、并发排队、KV Cache 使用率等多因素影响。优化建议包括：

• 提高 GPU 显存分配，降低 KV Cache 使用率。
• 增加显卡提升并发处理能力。
• 优化提示词长度，提升响应速度。
• 升级推理引擎版本，利用结构和调度器优化。

结合分布式调用链系统，开发者可深入洞察延迟问题，准确定位性能瓶颈，持续优化 AI 应用性能，确保基础架构面向未来。

Agent 可观测性：测量工具、计划和结果

Agent 推理、计划和行动通过多个步骤、工具和子决策。这灵活性使它们强大但也难以监控。单个“API 成功”指标并不捕获 Agent 的计划是否高效、正确或甚至完成。

测量维度

每个 Agent 运行应被视为根跟踪，每个步骤或工具执行作为子跨度。
要包括的属性：

• trace_id：跨整个推理周期共享
• span_name：计划、执行、评估，或工具名称
• iteration：捕获步骤顺序
• latency_ms 和 cost_usd
• status：成功、失败、重试

全栈可观测：向量数据库可观测

在 AI 原生系统中，传统的可观测性（metrics/logs/traces）更多关注系统性能与调用链。但随着 LLM、Embedding 检索、RAG（Retrieval-Augmented Generation） 的兴起，新的可观测维度出现了：

这使得 向量数据库（Vector Database） 成为 AI 可观测性的新核心组件。

向量数据库的作用与核心指标

作用：

• 存储和索引高维向量（Embedding），支持语义级搜索。
• 为 LLM 推理日志、RAG 检索上下文、Agent 记忆等提供底层支撑。
• 支持语义聚类与异常检测，用于 AI Pipeline 质量监控。

关键指标：

典型技术实现

向量数据库通常基于 ANN（Approximate Nearest Neighbor）算法，如 HNSW、IVF、PQ 等，用于加速高维检索。

开源实践与示例

以 Milvus 为例，可以在可观测性系统中嵌入以下指标：

# Milvus performance monitoring example
from pymilvus import connections, utility

connections.connect("default", host="localhost", port="19530")

# 监控 collection 数量与索引状态
collections = utility.list_collections()
for name in collections:
    status = utility.index_build_progress(name)
    print(f"{name} index progress: {status}")

同时，通过 Prometheus + Grafana 集成，可以可视化：

• 查询延迟（Search Latency）
• 索引构建时间（Index Build Time）
• 向量存储大小（Vector Storage Size）

向量可观测性的未来趋势

• Hybrid Observability：融合结构化（metrics）与非结构化（embedding）指标。
• Embedding Drift Detection：监控模型输出语义变化趋势。
• Semantic Trace：在分布式调用链中追踪 embedding 的生命周期。
• AI Native Telemetry Pipeline：未来的 OpenTelemetry 可能扩展支持向量事件格式（如 OTLP for Embeddings）。

总结

AI 可观测性是保障 AI 应用稳定、高效、安全运行的基石。通过端到端链路追踪、全栈指标采集和自动化评估，开发者能够精准定位问题、优化性能、控制成本并提升内容质量。未来，随着 AI 应用规模和复杂度提升，可观测性将持续演进，成为智能运维和治理的核心能力。

参考文献

1. OpenTelemetry 官方文档 - opentelemetry.io
2. vLLM 项目主页 - vllm.ai
3. 阿里云应用实时监控服务 ARMS - aliyun.com
4. How To Master Vector Databases - thenewstack.io
5. The complete guide to LLM observability for 2026 - portkey.ai