AI 可观测性

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

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

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

什么是 AI 可观测

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

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

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

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

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

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

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

AI 可观测应对的核心挑战

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

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

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

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

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

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

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

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

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

端到端全链路追踪

典型 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 应用性能，确保基础架构面向未来。

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

在 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