Langfuse错误追踪:AI应用故障诊断
2026-02-04 04:01:25作者:袁立春Spencer
痛点:AI应用故障排查的困境
你是否曾遇到过这样的场景?深夜接到报警,AI应用出现异常,却无法快速定位问题根源。传统的日志系统分散在各个服务中,LLM(Large Language Model,大语言模型)调用链复杂,错误信息碎片化,导致故障诊断如同大海捞针。
读完本文,你将获得:
- Langfuse错误追踪的核心机制解析
- 实战代码示例:从异常捕获到可视化展示
- 错误级别分类与智能诊断策略
- 生产环境故障排查最佳实践
- 多维度错误分析与统计方法
Langfuse错误追踪架构解析
核心错误处理机制
Langfuse采用分层错误追踪架构,通过OpenTelemetry标准实现分布式错误追踪:
graph TB
A[应用层异常] --> B[traceException捕获]
B --> C[OpenTelemetry Span记录]
C --> D[错误属性标准化]
D --> E[Datadog集成]
D --> F[CloudWatch监控]
D --> G[Langfuse可视化界面]
subgraph "错误信息标准化"
H[错误类型] --> I[错误消息]
J[堆栈跟踪] --> K[错误代码]
end
E --> L[实时告警]
F --> M[指标聚合]
G --> N[可视化分析]
错误追踪核心代码实现
Langfuse的traceException函数是错误处理的核心:
export const traceException = (
ex: unknown,
span?: opentelemetry.Span,
code?: string,
) => {
const activeSpan = span ?? getCurrentSpan();
if (!activeSpan) return;
const exception = {
code: code,
message: ex instanceof Error ? ex.message : JSON.stringify(ex),
name: ex instanceof Error ? ex.name : "Error",
stack: ex instanceof Error ? JSON.stringify(ex.stack) : undefined,
};
// OpenTelemetry异常记录
activeSpan.recordException(exception);
// Datadog错误追踪标签
activeSpan.setAttributes({
"error.stack": exception.stack,
"error.message": exception.message,
"error.type": exception.name,
});
activeSpan.setStatus({
code: opentelemetry.SpanStatusCode.ERROR,
message: exception.message,
});
};
错误级别分类体系
Langfuse采用四级错误分类标准,便于优先级排序和故障处理:
| 错误级别 | 标识 | 颜色 | 严重程度 | 处理策略 |
|---|---|---|---|---|
| DEBUG | 🔍 | 灰色 | 低 | 开发调试信息 |
| WARNING | ⚠️ | 黄色 | 中 | 需要关注但非阻塞 |
| ERROR | 🚨 | 红色 | 高 | 立即处理的生产问题 |
| DEFAULT | ℹ️ | 蓝色 | 信息 | 常规运行状态 |
错误级别可视化实现
export const LevelColors = {
DEFAULT: { text: "", bg: "" },
DEBUG: { text: "text-muted-foreground", bg: "bg-primary-foreground" },
WARNING: { text: "text-dark-yellow", bg: "bg-light-yellow" },
ERROR: { text: "text-dark-red", bg: "bg-light-red" },
};
export const LevelSymbols = {
DEFAULT: "ℹ️",
DEBUG: "🔍",
WARNING: "⚠️",
ERROR: "🚨",
};
实战:LLM应用错误追踪集成
基础错误追踪配置
from langfuse import observe
from langfuse.openai import openai
import os
# 环境变量配置
os.environ["LANGFUSE_SECRET_KEY"] = "sk-lf-..."
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-lf-..."
os.environ["LANGFUSE_HOST"] = "https://cloud.langfuse.com"
@observe()
def ai_chat_completion(user_query: str):
try:
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": user_query}],
temperature=0.7
)
return response.choices[0].message.content
except Exception as e:
# 自动被Langfuse捕获并记录错误
raise
# 复杂场景:嵌套追踪与错误传播
@observe()
def process_user_request(user_input: str):
try:
# 数据预处理
processed_input = preprocess_input(user_input)
# LLM调用
response = ai_chat_completion(processed_input)
# 后处理
return postprocess_response(response)
except ValueError as e:
# 输入验证错误
logger.warning(f"Input validation failed: {e}")
raise
except openai.APIConnectionError as e:
# 网络连接错误
logger.error(f"API connection error: {e}")
raise
except openai.RateLimitError as e:
# 速率限制错误
logger.error(f"Rate limit exceeded: {e}")
raise
高级错误处理策略
from langfuse.decorators import observe
from tenacity import retry, stop_after_attempt, wait_exponential
class AIServiceWithRetry:
def __init__(self):
self.llm_client = openai
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=4, max=10)
)
@observe()
def call_llm_with_retry(self, messages, model="gpt-4o"):
"""
带重试机制的LLM调用,自动错误追踪
"""
try:
response = self.llm_client.chat.completions.create(
model=model,
messages=messages,
timeout=30 # 30秒超时
)
return response.choices[0].message.content
except openai.APITimeoutError as e:
logger.error(f"LLM API timeout: {e}")
raise
except openai.APIError as e:
logger.error(f"LLM API error: {e}")
raise
except Exception as e:
logger.error(f"Unexpected error in LLM call: {e}")
raise
# 使用示例
ai_service = AIServiceWithRetry()
try:
result = ai_service.call_llm_with_retry(
messages=[{"role": "user", "content": "Explain quantum computing"}]
)
except Exception as e:
# 所有错误都会被Langfuse自动追踪
logger.error("Failed to get LLM response", exc_info=True)
错误诊断与可视化分析
错误仪表板配置
Langfuse提供丰富的错误可视化功能,包括:
- 错误趋势图表:按时间维度展示错误发生频率
- 错误类型分布:统计不同错误类型的占比
- 影响范围分析:显示受影响的用户和业务功能
- 根因分析:通过Trace链定位问题根源
错误查询与过滤
-- 查询最近24小时内的ERROR级别异常
SELECT
trace_id,
observation_name,
error_message,
error_stack,
timestamp,
user_id
FROM observations
WHERE level = 'ERROR'
AND timestamp >= NOW() - INTERVAL '24 HOURS'
ORDER BY timestamp DESC
LIMIT 100;
生产环境最佳实践
错误监控告警策略
| 监控指标 | 阈值 | 告警级别 | 响应时间 |
|---|---|---|---|
| ERROR级别错误率 | > 1% | P0 | 15分钟内 |
| WARNING级别错误数 | > 10/分钟 | P1 | 1小时内 |
| LLM API失败率 | > 5% | P0 | 立即处理 |
| 响应时间P95 | > 5秒 | P2 | 4小时内 |
错误处理清单
✅ 错误信息标准化
- 统一的错误消息格式
- 包含足够上下文信息
- 避免敏感信息泄露
✅ 错误分类策略
- 按业务影响程度分类
- 按技术根因分类
- 按发生频率分类
✅ 告警集成
- Slack/Teams实时通知
- 邮件摘要报告
- PagerDuty紧急呼叫
✅ 事后分析
- 错误根本原因分析(RCA)
- 预防措施制定
- 知识库文档更新
故障排查实战案例
案例1:LLM API速率限制错误
症状:突然出现大量429 Too Many Requests错误
诊断步骤:
- 在Langfuse中过滤ERROR级别异常
- 查看错误消息包含"rate limit"或"429"
- 分析发生时间段的请求量趋势
- 检查LLM供应商的配额使用情况
解决方案:
@observe()
def adaptive_llm_call(messages, model="gpt-4o"):
"""
自适应LLM调用,处理速率限制
"""
try:
return openai.chat.completions.create(
model=model,
messages=messages,
max_retries=2,
timeout=15
)
except openai.RateLimitError:
# 自动降级到备用模型
return openai.chat.completions.create(
model="gpt-3.5-turbo", # 备用模型
messages=messages,
timeout=10
)
案例2:内存泄漏导致的服务崩溃
症状:服务周期性重启,错误日志显示OOM(Out of Memory)
诊断步骤:
- 使用Langfuse Trace分析内存使用模式
- 识别内存增长与特定操作的关系
- 检查大对象或未释放的资源
解决方案:
@observe()
def process_large_dataset(dataset):
"""
处理大数据集时进行内存优化
"""
try:
# 分批次处理,避免内存溢出
batch_size = 1000
results = []
for i in range(0, len(dataset), batch_size):
batch = dataset[i:i + batch_size]
processed_batch = process_batch(batch)
results.extend(processed_batch)
# 强制垃圾回收
if i % 5000 == 0:
gc.collect()
return results
except MemoryError as e:
logger.error("Memory exhaustion in dataset processing", exc_info=True)
# 自动触发扩容或告警
trigger_scaling_action()
raise
错误追踪的高级特性
自定义错误指标
from langfuse.metrics import record_counter, record_gauge
@observe()
def business_critical_operation(data):
try:
result = process_data(data)
record_counter("business_operation.success", 1)
return result
except BusinessException as e:
# 记录业务特定错误
record_counter("business_operation.failure", 1, tags={"error_type": "business_rule"})
raise
except TechnicalException as e:
record_counter("business_operation.failure", 1, tags={"error_type": "technical"})
raise
分布式错误追踪
sequenceDiagram
participant Client
participant API Gateway
participant Auth Service
participant LLM Service
participant Database
Client->>API Gateway: 发送请求
API Gateway->>Auth Service: 验证权限
Auth Service-->>API Gateway: 验证成功
API Gateway->>LLM Service: 调用LLM
LLM Service->>Database: 查询上下文
Database-->>LLM Service: 返回数据
LLM Service-->>API Gateway: LLM响应
API Gateway-->>Client: 最终响应
Note over LLM Service, Database: 数据库超时错误
LLM Service->>API Gateway: 返回错误
API Gateway->>Langfuse: 记录分布式Trace
Langfuse-->>运维团队: 发送告警
总结与展望
Langfuse的错误追踪系统为AI应用提供了完整的可观测性解决方案。通过:
- 标准化错误处理:统一的异常捕获和记录机制
- 多维度可视化:丰富的错误分析和展示功能
- 智能诊断:基于Trace的根因分析能力
- 生产就绪:企业级的监控告警集成
未来,随着AI应用的复杂度不断提升,错误追踪将更加注重:
- AI特异性错误的自动诊断
- 预测性错误预防
- 自适应错误恢复机制
- 多模态错误分析(文本、代码、日志联合分析)
通过Langfuse的错误追踪能力,团队可以显著提升AI应用的稳定性和可靠性,确保用户体验和业务连续性。
立即行动:
- 集成Langfuse SDK到你的AI应用
- 配置错误监控告警
- 建立错误处理标准流程
- 定期进行错误复盘和优化
让错误不再是噩梦,而是改进的机会!
登录后查看全文
热门项目推荐
相关项目推荐
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00
GLM-4.7-FlashGLM-4.7-Flash 是一款 30B-A3B MoE 模型。作为 30B 级别中的佼佼者,GLM-4.7-Flash 为追求性能与效率平衡的轻量化部署提供了全新选择。Jinja00
VLOOKVLOOK™ 是优雅好用的 Typora/Markdown 主题包和增强插件。 VLOOK™ is an elegant and practical THEME PACKAGE × ENHANCEMENT PLUGIN for Typora/Markdown.Less00
PaddleOCR-VL-1.5PaddleOCR-VL-1.5 是 PaddleOCR-VL 的新一代进阶模型,在 OmniDocBench v1.5 上实现了 94.5% 的全新 state-of-the-art 准确率。 为了严格评估模型在真实物理畸变下的鲁棒性——包括扫描伪影、倾斜、扭曲、屏幕拍摄和光照变化——我们提出了 Real5-OmniDocBench 基准测试集。实验结果表明,该增强模型在新构建的基准测试集上达到了 SOTA 性能。此外,我们通过整合印章识别和文本检测识别(text spotting)任务扩展了模型的能力,同时保持 0.9B 的超紧凑 VLM 规模,具备高效率特性。Python00
KuiklyUI基于KMP技术的高性能、全平台开发框架,具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意:本仓库为Github仓库镜像,PR或Issue请移步至Github发起,感谢支持!Kotlin07
compass-metrics-modelMetrics model project for the OSS CompassPython00
项目优选
收起
deepin linux kernel
C
27
11
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
525
3.72 K
Ascend Extension for PyTorch
Python
329
391
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
877
578
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
335
162
暂无简介
Dart
764
189
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
12
1
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.33 K
746
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
67
20
React Native鸿蒙化仓库
JavaScript
302
350