在Dify生产环境中，若想真正掌握服务运行状态与API响应延迟情况，需要一套完整的监控方案。先给出结论：首先开启Prometheus指标端口，随后配置抓取任务，接着在Grafana中构建延迟监控看板，最后借助审计日志补齐端到端链路分析。下面逐步拆解。
启用Dify内置监控指标采集
第一步操作简单。登录Dify部署服务器终端，确认Prometheus指标暴露端口是否已开启（默认端口为8080）。若未开启，需修改dify.yaml配置文件，将monitoring.enabled设置为true，然后重启服务。
关键验证步骤绝不能省——检查指标端点是否可访问。执行curl http://localhost:8080/metrics，返回结果中必须包含workflow_duration_seconds和api_request_duration_seconds等核心指标行。若跳过此步，后续监控配置将全部失效——所有延迟图表都会显示为空白。
操作本身简单，直接拖入文件即可，但需警惕：跳过验证直接对接Grafana，会导致所有延迟图表均为空白。
配置Prometheus抓取Dify指标
接下来在Prometheus的配置文件prometheus.yml中新增一个抓取任务，写入scrape_configs区块下：
- job_name: 'dify-monitoring' static_configs: - targets: ['localhost:8080'] metrics_path: '/metrics'
保存配置文件后，使用prometheus --config.file=prometheus.yml --storage.tsdb.path=/data启动服务。Prometheus将每15秒主动拉取一次Dify指标，延迟数据开始持续写入时序数据库。
此处有一个关键细节：target地址必须与Dify服务实际监听的IP一致。如果Dify运行在Docker容器内，应填写宿主机IP，或使用host.docker.internal替代localhost。
在Grafana中构建响应延迟看板
先添加Prometheus数据源，URL填写http://localhost:9090（假设Prometheus运行在9090端口）。
然后新建Dashboard，点击"Add new panel"，在Query字段输入：histogram_quantile(0.95, sum(rate(api_request_duration_seconds_bucket[5m])) by (le, endpoint))。
接着设置X轴为时间范围，Y轴单位选择seconds，图例格式用{{endpoint}}来区分不同API路径。点击右上角"Sa ve dashboard"，命名为"Dify API Latency"。
该看板能立刻暴露异常——例如某条曲线突然跃升至3秒以上，说明对应接口正遭遇模型调用阻塞或缓存失效，需立即检查日志中request_id关联的完整链路。
通过审计日志补全端到端延迟分析
Prometheus指标仅反映服务端处理时间，而真正的端到端延迟分析需要审计日志的配合。调用Dify审计API拉取原始请求记录：curl -X GET "https://your-dify-domain.com/v1/audit/logs?limit=500&start_time=2026-06-08T09:00:00Z" -H "Authorization: Bearer YOUR_API_KEY"。
解析返回的JSON，提取duration字段（单位毫秒）与endpoint字段，筛选出duration > 2000的慢请求。对每个慢请求，使用其request_id去查询Dify调试日志，定位具体耗时节点。例如发现"node": "knowledge_retrieval", "latency_ms": 4200，说明知识库检索超时，应检查向量数据库连接或分块策略。
这一步不可跳过——Prometheus指标仅显示服务端处理时间，而审计日志包含客户端发起时间戳，两者比对才能确认是网络延迟还是服务瓶颈。这才是完整的链路分析。