AI可观测性实战：用Phoenix实现LLM调用追踪

Dynatrace 宣布收购 AI 可观测性公司 Arize，这一动作让 AI Observability 这个细分领域又一次成为工程团队讨论的焦点。真正值得关心的不是新闻本身，而是它背后的技术问题：当 LLM 应用进入生产环境，监控应该怎么做。传统监控工具能告诉我们服务延迟、错误率和机器负载，但很难回答更加关键的问题：模型这次回答为什么差、Prompt 是否被注入、Token 成本为什么上涨、Agent 的哪一跳出了问题。Arize 正是补上这一环的评估与追踪工具。下面会先梳理 AI 可观测性到底解决什么，然后通过一个基于 Phoenix 的最小示例，演示如何在本地追踪一次 LLM 调用，最后给出从示例走向生产环境的落地清单。

1. AI 可观测性不是 APM 的改名，而是监控范围的扩展

1.1 传统可观测性的三大支柱还够用吗

传统可观测性通常由 Metrics、Logs、Traces 三大支柱组成。Metrics 回答“系统整体是否健康”，Logs 回答“某个节点当时发生了什么”，Traces 回答“一次请求经过了哪些服务、每段耗时多少”。这套体系在微服务和分布式应用中非常成熟，像 Dynatrace 这类平台已经把 APM、基础设施监控、日志分析和分布式链路追踪整合到了同一个界面里。

但 LLM 应用带来的问题超出了三大支柱的原始范围。传统链路追踪可以记录一个 HTTP 请求从网关到服务再到数据库的完整路径，却无法记录模型输入输出之间的语义差异。比如用户问“帮我总结这封邮件”，模型是否真的像人一样理解邮件内容，传统 Trace 只能看到调用耗时和返回码，看不到生成内容的质量。再比如 Prompt 里被注入了恶意指令，传统监控不会发现这次调用的行为模式有什么异常，但 AI 可观测性需要把这类情况暴露出来。

所以不能简单说“AI 可观测性就是 APM 加一个 LLM 面板”。它是在原有可观测性数据模型里，增加模型调用、评估结果、Token 消耗、推理成本、幻觉风险等新维度。传统三大支柱仍然重要，但已经不够。

1.2 AI 应用里到底需要观测什么

要理解 AI 可观测性的监控范围，可以先从一次 LLM 请求的全过程拆解。

一次 LLM 请求至少包括这几个环节：应用收到用户输入，经过 Prompt 模板拼装或 Agent 路由，传给模型服务，模型返回结果，应用可能再做后处理或二次调用。这个过程中需要观测的数据可以分成四类。

第一类是调用执行数据，包括模型名称、请求延迟、HTTP 状态、Token 输入输出量、模型返回的 finish_reason 等。这类数据最接近传统 APM，但字段更偏模型语义。

第二类是内容数据，包括完整的 Prompt、模型输出、工具调用参数、检索到的上下文片段。这类数据在传统监控中很少会作为核心链路数据保存，但在 AI 可观测性中必须存在，否则无法定位“模型为什么答错”。

第三类是质量评估数据，例如回答是否忠实于上下文、是否包含有害内容、是否出现幻觉、是否满足用户指令。这类数据不能由传统 API 监控得到，需要额外引入评估模型或规则。

第四类是业务与成本数据，比如一次回答对应哪个产品和用户、消耗了多少费用、是否触发了限流。当多个团队共享同一个模型服务时，这部分数据关系到成本分摊和容量规划。

把四类数据放在一起，才能完整描述一次 AI 应用请求发生了什么。传统 APM 基本只覆盖第一类的一部分。

1.3 为什么可观测性平台开始收购 AI 评估工具

Dynatrace 这类平台原本擅长处理海量指标、日志和链路数据，而 Arize 这类 AI 可观测性公司擅长模型评估、漂移检测和 LLM 追踪。前者离基础设施近，后者离模型行为近。

过去两者的工作流是割裂的：应用调用链在 Dynatrace 里看，模型评估结果在 Arize 里看，两套数据没有统一关联。问题出现时，团队要先判断是模型输出质量差，还是上层服务延迟高，再切换工具去排查。收购的目的就是把这套工作流合并：让同一个平台既能看到服务性能，也能看到模型行为和评估结果。

对工程团队来说，这种合并的实际价值在于链路统一。一次 LLM 请求从用户入口到模型服务，再到评估结果，应该是一条完整的 Trace。传统可观测性平台提供 Trace 的骨架，AI 评估工具提供模型语义的实体内容，两者合并后，排查效率会明显提升。

1.4 传统可观测性与 AI 可观测性的差异

可以用一张表快速对齐两类工具关注点的差异。

这个对比不是要否定传统可观测性，而是说明 AI 场景需要在一套既有基础设施上扩展新数据模型。Dynatrace 收购 Arize 的底层逻辑，正是把右侧这些能力并进左侧成熟平台。

2. 收购背后的技术拼图：Dynatrace 的全栈能力与 Arize 的模型评估能力

2.1 Dynatrace 解决的是“系统运行得怎么样”

Dynatrace 是典型的全栈可观测性平台，覆盖应用性能监控、基础设施监控、日志处理、分布式链路追踪、数字体验监控和自动化运维。它的优势在于数据采集范围广、处理链路完整，能够把一个请求从浏览器或移动端一直追踪到后端服务和数据库。

在 AI 应用场景里，Dynatrace 这类平台擅长回答的问题是：模型 API 的调用延迟是否升高、服务端是否出现限流或错误、网络链路是否稳定、关联的数据库和缓存是否正常。如果一次 LLM 调用很慢，平台可以通过 Trace 看到慢在模型服务本身，还是慢在模型调用之前的检索和上下文组装环节。

但它有一个天然边界：Dynatrace 可以记录“这次调用耗时 3 秒”，却很难判断“模型输出的这段内容是否在胡编”。后者需要模型评估，而模型评估需要独立的评估逻辑和数据集，不是简单采集性能指标能实现的。

2.2 Arize 解决的是“模型表现得好不好”

Arize 起家于机器学习模型监控，后来扩展到 LLM 可观测性。它能做模型性能监测、特征漂移检测、数据漂移分析、模型回归对比，也支持 LLM 的 Prompt 追踪、输出评估、RAG 检索质量分析和 Agent 调用链分析。

Arize 解决的核心问题可以拆成三个：第一，模型效果随时间是否下降；第二，某次具体回答为什么出错；第三，生产环境的数据分布和训练环境相比发生了怎样的变化。

例如一个客服机器人的回答准确率在最近几天下降，Arize 可以分析出是因为用户输入的话题分布变了，还是因为最近一次模型版本更新导致在特定场景下回答质量下降。这种判断需要同时看评估指标和数据分布，传统 APM 不会覆盖。

2.3 合并后的技术想象空间：从基础设施到模型行为打通

Dynatrace 收购 Arize 后，比较理想的技术效果是把两类数据打通到同一条端到端链路上。

想象一次线上故障：用户报告智能助手回答错误。如果只有 Dynatrace，团队可以看到这次请求耗时、模型 API 状态、服务日志，但不知道回答内容为什么不符合预期。如果只有 Arize，团队可以看到 Prompt、输出和评估分数，但不知道底层服务是否出现过内存溢出、网络超时或依赖故障。

合并后的理想状态是：一条 Trace 从用户请求开始，经过应用服务、RAG 检索、模型调用，最后带上评估结果和 Token 成本。排障时先判断是基础设施问题、应用逻辑问题还是模型质量问题，再逐层下钻。这也是可观测性平台从“监控应用”走向“监控智能应用”的方向。

需要说明的是，以上只代表收购之后的产品方向。实际功能是否能在两套产品中无缝打通，取决于后续的工程整合和接口开放程度。落地时仍然要以 Dynatrace 和 Arize 官方文档为准。

2.4 两套能力对照

这张表说明两者不是同一赛道的重复建设。Dynatrace 提供的是底座和入口，Arize 提供的是模型语义层。理解这个关系，后续搭建自己的 AI 可观测性体系时才知道哪些能力应该放在平台侧，哪些能力应该放在模型侧。

3. 本地跑通最小示例：Phoenix 追踪一次 OpenAI 调用

3.1 为什么用 Phoenix 做最小示例

在讨论 Dynatrace 和 Arize 这种商业平台时，直接对接完整平台需要账号、权限、SDK 和网络规划，学习成本偏高。Arize 团队开源的 Phoenix 项目则方便很多，它支持本地启动、OpenTelemetry 协议接入，并提供 LLM 追踪、评估和可视化界面。

Phoenix 适合用来说明 AI 可观测性最小闭环：一次 LLM 调用，经过自动埋点，产生 Trace，Token 和延迟数据进入观察端，最后在 UI 上呈现。这个流程和在 Arize、Dynatrace 上做模型追踪的核心逻辑一致，只是规模更小、更容易复现。

需要注意，Phoenix 的 API 更新比较快，不同版本之间可能存在差异。下面示例基于 2024 年至 2025 年常见版本的用法，落地前先根据自己安装的版本查看官方文档和帮助命令。

3.2 环境准备

建议在独立目录中使用 Python 3.10 或 3.11 创建虚拟环境，避免和系统 Python 环境互相污染。

mkdir llm-observability-demo cd llm-observability-demo python -m venv .venv source .venv/bin/activate

Windows 环境下激活命令是：

.venv\Scripts\activate

激活后可以先确认 Python 版本：

python --version

Phoenix 需要比较新的 Python 版本，如果版本偏低，安装依赖时容易遇到二进制包编译问题。

3.3 安装依赖

最小示例需要四个依赖：Phoenix、OpenAI SDK、OpenTelemetry 相关模块以及 OpenInference 的 OpenAI 埋点库。

pip install arize-phoenix openai pip install opentelemetry-sdk opentelemetry-exporter-otlp pip install openinference-instrumentation-openai

不同版本的包可能对 OpenTelemetry 依赖版本有要求。如果安装后出现依赖冲突，优先按 Phoenix 官方文档给出的版本组合安装，不要手工乱升级。

然后配置 OpenAI API Key。最简单的方式是设置环境变量：

export OPENAI_API_KEY="你的密钥"

在 Windows PowerShell 中使用：

$env:OPENAI_API_KEY="你的密钥"

这只是学习环境做法。生产环境不应直接把密钥写进终端或代码仓库，应该使用密钥管理服务或者平台提供的安全变量。

3.4 启动 Phoenix

Phoenix 可以通过 Python API 启动，也可以作为服务启动。学习环境最简单的是在 Python 中调用launch_app。

先创建一个空脚本文件app.py：

import phoenix as px # 启动 Phoenix 观测服务，默认 UI 地址是 http://127.0.0.1:6006 session = px.launch_app() print("Phoenix UI: http://127.0.0.1:6006")

运行后，打开浏览器访问http://127.0.0.1:6006，如果能打开 Phoenix 页面，说明观测端已经就绪。

也可以直接用命令行启动：

python -m phoenix.server.main serve

这个方式适合不想在每次实验脚本里都启动 Phoenix 的场景。启动后保持进程运行，实验脚本只负责发送追踪数据。

3.5 用 OpenInference 追踪一次 OpenAI 调用

接下来写完整的追踪示例。下面是完整脚本app.py，覆盖启动 Phoenix、配置 OpenTelemetry、埋点 OpenAI、发起调用四个步骤。

import phoenix as px from openai import OpenAI from opentelemetry import trace as trace_api from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter from opentelemetry.sdk.resources import Resource from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import SimpleSpanProcessor from openinference.instrumentation.openai import OpenAIInstrumentor # 1. 启动 Phoenix，默认监听 6006 端口 session = px.launch_app() # 2. 创建 OpenTelemetry TracerProvider resource = Resource(attributes={"service.name": "llm-demo-service"}) tracer_provider = TracerProvider(resource=resource) # 3. 把 Span 通过 OTLP HTTP 协议发送到 Phoenix otlp_exporter = OTLPSpanExporter( endpoint="http://127.0.0.1:6006/v1/traces" ) tracer_provider.add_span_processor( SimpleSpanProcessor(otlp_exporter) ) # 4. 设置为全局 TracerProvider trace_api.set_tracer_provider(tracer_provider) # 5. 对 OpenAI SDK 自动埋点 OpenAIInstrumentor().instrument() # 6. 发起一次模型调用 client = OpenAI() response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个技术助手。"}, {"role": "user", "content": "用一句话解释 AI Observability"}, ], ) print(response.choices[0].message.content) print("Token usage:", response.usage)

脚本的关键点在于：先启动 Phoenix，再配置 TracerProvider，并在调用 OpenAI 之前执行instrument()。如果埋点发生在调用之后，那次调用就不会产生追踪数据。

运行：

python app.py

正常时会看到模型返回内容，并输出类似下面的 Token 信息：

Token usage: CompletionUsage(completion_tokens=..., prompt_tokens=..., total_tokens=...)

此时打开 Phoenix UI，应该能看到一条chat.completions.create对应的 Trace。

4. 核心代码拆解：Span、Token、成本是怎么被记录下来的

4.1 追踪链路如何形成

OpenInference 是专为 AI 应用定义的一组语义约定，它把模型调用中的 Prompt、模型名称、Token 数、工具调用等内容规范化成 Span 属性。

当OpenAIInstrumentor().instrument()生效后，SDK 内部会对chat.completions.create这类调用做拦截，自动创建一个 Span，并把模型输入输出写入 Span Attributes。这个 Span 再通过 OpenTelemetry 的 Exporter 发送到 Phoenix。

所以代码中真正重要的不是“手动写日志”，而是建立起“自动埋点 + 统一导出”的通道。生产环境中，同样的一层埋点可以替换成发往 Dynatrace 或 Arize 的 OTLP 端点，只需要修改 Exporter 的 endpoint 配置。

4.2 关键代码逐段说明

第一段是px.launch_app()。它启动 Phoenix 的本地观测后端，同时注册一个可以接收 OTLP 数据的 HTTP 服务。

第二段是TracerProvider的创建。resource里的service.name会作为服务标识出现在追踪列表里。如果同时监控多个服务，这一步不要省略，否则排障时不容易区分来源。

第三段是OTLPSpanExporter的配置。这里的endpoint要和 Phoenix 的地址一致，常见写法是http://127.0.0.1:6006/v1/traces。如果 Phoenix 运行在远程服务器，需要把 IP 和端口替换成实际地址，并保证网络可达。

第四段是OpenAIInstrumentor().instrument()。它会在当前进程里对 OpenAI 客户端进行埋点。对于 LangChain、LlamaIndex 等框架，也有对应的 Instrumentor，实现原理类似。

第五段是实际调用。OpenAI SDK 返回的usage对象包含了prompt_tokens、completion_tokens、total_tokens，这些是成本计算和容量规划的基础数据。

4.3 关键参数速查

在 Phoenix UI 中，这些字段会被格式化展示。如果一个字段为空，通常表示埋点没有捕获到该信息，需要检查 SDK 版本或是否启用了对应 Instrumentor。

4.4 从单一调用扩展到 RAG 与 Agent

上面的最小示例只追踪了一次模型调用。真实 AI 应用往往包含检索、工具调用、多轮对话和 Agent 路由，这些场景需要在应用中创建自定义 Span。

在 Python 中可以这样创建手动 Span：

from opentelemetry import trace tracer = trace.get_tracer(__name__) def search_from_knowledge_base(query: str): with tracer.start_as_current_span("retrieve_context") as span: span.set_attribute("retrieval.query", query) context = do_search(query) span.set_attribute("retrieval.top_k", len(context)) return context

这样，模型调用 Span 和检索 Span 会在同一条 Trace 里串联起来。排查时可以清楚看到是哪一步导致回答质量下降：是没检索到相关文档，还是模型没有正确使用文档。

Spring AI 等 Java 生态也提供了对应的可观测性支持。核心思路一样：把模型调用和检索调用纳入 OpenTelemetry 链路，在统一的观测后端查看。

5. 验证与排错：看不到 Trace 时按这条链路查

5.1 验证结果：先从 UI 确认链路存在

运行示例后，打开 Phoenix UI，左侧菜单通常会有 Traces 或 Projects 等入口。找到刚才的chat.completions.create调用，点击进入详情，应该能看到：

• 模型名称
• Prompt 和 Completion 内容
• Token 用量
• 调用延迟
• finish_reason等属性

如果 UI 中没有数据，不要急着怀疑 Phoenix，先按顺序检查。

5.2 从代码执行顺序和端口开始排查

第一个常见问题是 Phoenix 页面能打开，但实验脚本没有任何 Trace。

此时优先检查 Exporter 的 endpoint 是否指向了 Phoenix 正在监听的端口。px.launch_app()默认监听 6006 端口，但如果你手动调整过配置，或者 Phoenix 跑在其他机器上，endpoint 就会失效。

第二个常见问题是模型调用发生在了instrument()之前。OpenAI Instrumentor 只对当前进程后续创建的客户端和方法调用生效，如果在 instrument 之前已经 init 了 client，或者已经发起过请求，就不会被追踪。

第三个常见问题是只看到根 Span，看不到 OpenAI 内部的 LLM Span。这通常是因为 Instrumentor 版本与 OpenAI SDK 版本不匹配。可以尝试升级或降级 OpenAI SDK 版本，同时核对openinference-instrumentation-openai的说明文档。

排查路径可以按表推进：

5.3 观察异常分支

除了正常运行，还要验证失败调用和截断场景。

可以故意把 model 改成不存在的名称，观察 UI 是否出现红色错误 Span，并记录异常信息。也可以把max_tokens设成很小的值，比如 5，观察finish_reason是否为length。这类字段在排障中非常重要，因为它们能说明“模型没答完”不是网络问题，而是配置或上下文长度限制。

注意：不要只验证程序能启动，还要验证输入、输出、异常分支和日志是否符合预期。AI 可观测性尤其如此，业务结果是否合理才是核心。

6. 生产环境落地：指标、脱敏、采样与平台化集成

6.1 指标不是越多越好

生产环境如果全量采集所有 Token 和内容，会带来存储成本和数据合规风险。建议先明确必须观测的核心指标。

推荐的最低指标集包括：

• 请求层面的模型调用延迟、错误率、吞吐量
• Token 层面的输入 Token、输出 Token、总 Token、截断次数
• 成本层面的单次调用成本、按团队或产品聚合的日成本
• 质量层面的评估分数、幻觉率、检索命中率
• 状态层面的finish_reason分布、限流次数、模型版本分布

这些指标优先级最高。内容级追踪可以只在问题调查时临时开启，或者通过采样保存一部分代表样本。

6.2 隐私与数据脱敏是前置条件

LLM 调用里经常包含用户敏感信息，将完整 Prompt 和模型输出直接写入观测平台，等同于把敏感数据复制了一份。

生产环境至少要做三层处理：

第一层，在 SDK 层过滤敏感字段。OpenInference 的 Span 属性可以在导出前修改或丢弃，避免把完整内容写入后端。

第二层，在存储层设置保留期限。观测平台里的调用内容不应永久保留，通常建议按合规要求设置数据保留策略。

第三层，在评估层做匿名化处理。需要模型评估时，先对用户 ID、姓名、手机号等字段做脱敏，再发送给评估模型。

# 示例：在导出前脱敏 def sanitize_content(content: str) -> str: if not content: return content # 示例规则：替换连续数字 import re return re.sub(r"\d{6,}", "[REDACTED]", content)

是否采用自动脱敏需要结合具体场景。可以把它接入自定义的 Span Processor 中，在导出前统一处理。

6.3 采样策略：在成本和可观测性之间做取舍

全量采集在开发和测试环境没问题，生产环境必须设计采样策略。

常用方案包括：

• 固定比例采样：比如保留 10% 的调用链路。
• 尾采样：等请求结束后，根据结果决定是否保留。错误请求和延迟请求优先保留。
• 分层采样：根据用户、产品线、模型版本分配采样率。

尾采样更适合 LLM 场景，因为它可以保证错误调用和高价值请求一定被记录下来，而正常的低价值请求只保留少量样本。

6.4 与 Dynatrace 等平台集成时需要确认的环节

如果团队最终选择 Dynatrace 或 Arize 商业平台，可以从最小链路开始逐步接入。

先确认平台是否支持 OpenTelemetry 协议。如果支持，现有埋点代码改动较小，核心是把 OTLP Exporter 的 endpoint 从本地 Phoenix 换成平台网关。

再确认内容数据是否会上传到云端。商业平台通常提供数据脱敏和访问控制配置，需要测试几个敏感场景后再放开权限。

最后确认评估能力如何配置。Arize 的模型评估可能需要上传评估数据或在线调用评估模型，要明确哪些数据可以离开本地环境。

6.5 团队落地清单

上线前可以对照这份清单逐项检查：

• 明确定义需要监控的 AI 应用范围和负责人
• 统一服务命名和链路规范
• 配置模型名称、模型版本和部署环境标签
• 接入 LLM 调用追踪和 Token 采集
• 设置成本聚合和告警阈值
• 对敏感字段做脱敏处理
• 制定采样策略和数据保留周期
• 配置模型质量评估流程，包括回归比较
• 验证错误分支和截断场景的追踪数据
• 建立排障文档，记录常见问题和处理方式
• 确认观测平台访问权限和数据隔离方案
• 对核心指标设计告警，避免只存不用

做完这些，才算把 AI 可观测性从一次示例调用变成可依赖的工程能力。

Dynatrace 与 Arize 的收购事件说明，AI 可观测性正在从独立工具走向统一平台。对开发团队来说，最值得投入的方向不是追逐某个品牌，而是掌握 OpenTelemetry、OpenInference、LLM 追踪和模型评估这一整条技术链路。先用 Phoenix 跑通最小示例，再逐步接入商业平台，是成本最低、也最容易验证的学习路径。