必须启用dify原生全链路追踪日志（log_level=debug、otel_exporter_otlp_endpoint、otel_service_name），再通过x-trace-id聚合日志，结合调试api或cli命令捕获执行快照，最后按trace_id筛选tool-fail日志并分析duration_ms与时间戳差值定位瓶颈。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当Dify Agent在生产环境响应变慢、工具调用频繁超时或工作流中途卡死，你需要的不是重启服务，而是看清每一次调用在哪个环节耗时异常、哪条分支未执行、哪个工具返回了空响应——这要求监控必须深入到Agent内部执行上下文与跨服务调用链路中。
启用Dify原生全链路追踪日志
在Dify部署目录的.env文件中添加三行配置，无需修改代码或重启服务即可生效（v0.13+版本默认支持）：
LOG_LEVEL=DEBUG
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=dify-agent-executor
这一步必须放在所有Agent启动前完成，否则首次请求无法携带trace_id。配置后，每个Workflow Run返回头中将自动注入X-Trace-ID字段，它是后续所有日志聚合的唯一锚点。
实时捕获Agent执行快照
方法一：通过调试API抓取运行时状态
向/api/v1/workflows/{workflow_id}/runs/{run_id}/messages?limit=50发送GET请求，检查返回JSON中每个message对象的status字段是否为pending或failed。
方法二：使用CLI命令动态注入诊断Hook
Dify 3.9.2更新重点增强系统安全性，引入 Chainguard 安全基础镜像并同步社区版 CVE 修复，同时优化 OpenSearch 向量存储兼容性、插件参数传输机制及 Helm 部署配置。新增工作流模型节点缓存能力，可减少重复凭证查询，显著提升复杂工作流初始化速度，为企业级 AI 应用提供更稳定、高效的运行体验。
在项目根目录执行：
【dify-cli trace --workflow "sales-forecast-v3" --depth 3 --timeout 15s】
该命令会实时注入PreAgentHook和PostToolCallHook，捕获agent_id、input_keys、memory_len、tool_name、response keys等关键现场信息，输出结构化trace ID树。
注意：CLI命令仅对当前运行实例生效，不持久化，适合紧急排查。
定位工具调用性能瓶颈
第一步：从日志系统（如Loki或ELK）中按trace_id检索完整日志流
第二步：筛选含"TOOL-FAIL"前缀的日志行，重点关注duration_ms > 3000且status_code != 200的记录
第三步：比对同一trace_id下相邻工具调用的created_at时间戳差值，若>30秒，说明上游工具阻塞导致下游等待超时
例如：日志中出现"[TOOL-FAIL]db_query|504|4280ms | keys:[]"，直接指向数据库网关超时，而非Agent逻辑问题。
