必须将Dify的/metrics端点接入Prometheus并配置Grafana看板：先设ENABLE_METRICS=true启用指标，再通过静态配置或K8s服务发现抓取数据，最后导入企业级看板实现多维监控与告警。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当Dify在生产环境出现响应延迟突增、Token消耗异常或API错误率飙升却无法定位源头时，必须让系统“说出”它的状态——这要求将Dify暴露的/metrics端点指标实时接入Grafana，构建可下钻、可告警、可按应用/模型/LLM provider维度拆分的可视化看板。整个过程不修改Dify源码，仅依赖标准OpenMetrics协议与Prometheus中转。
确认Dify已启用指标暴露
默认Dify镜像（v0.7.0+）内置metrics中间件，但【ENABLE_METRICS=true】必须显式设置，否则/metrics路径返回404，后续所有采集失效。
执行验证命令：curl http://your-dify-api-host:8080/metrics，成功响应应包含# HELP http_request_duration_seconds等OpenMetrics格式文本。若返回空或404，请检查Docker Compose中的environment或K8s Deployment的env配置项。
配置Prometheus抓取Dify指标
方法一：静态配置（适用于单实例或测试环境）
编辑prometheus.yml，在scrape_configs下添加：
- job_name: 'dify-api'
static_configs:
- targets: ['dify-api:8080']
labels:
app: 'dify'
env: 'prod'
注意：target地址必须能被Prometheus网络直连；Docker Compose中用服务名，K8s中必须用Service DNS全称（如dify-api.default.svc.cluster.local）。
方法二：Kubernetes动态发现（推荐用于生产集群）
利用Pod标签自动识别Dify实例，避免手动维护target列表：
- job_name: 'dify-otel'
kubernetes_sd_configs:
- role: pod
selectors:
- matchExpressions:
- key: app.kubernetes.io/name
operator: In
values: [dify-api]
metrics_path: '/metrics'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance]
target_label: instance
- source_labels: [__meta_kubernetes_pod_container_name]
target_label: container
该配置【仅抓取带app.kubernetes.io/name=dify-api标签的Pod】，防止误采其他服务指标。
导入并配置Dify企业级Grafana看板
第一步：访问Grafana Web界面 → 左侧菜单点击「+」→ 「Import」
第二步：粘贴看板JSON模板ID或上传已下载的dify-enterprise-dashboard.json文件（该模板覆盖模型延迟热力图、知识库Chunk加载成功率趋势、Agent调用链追踪等23个核心视图）
第三步：在Import页面选择对应Prometheus数据源（确保该数据源已正确指向你的Prometheus Server地址）
第四步：点击「Import」按钮，看板即刻生成。首次加载可能需等待1–2分钟以拉取历史指标数据。
第五步：进入看板后，点击右上角「时间范围」选择「Last 6 hours」或「Last 24 hours」，观察dify_http_request_duration_seconds_bucket、dify_api_request_total{status=~"5.."}等关键指标是否开始出图。若全部为空，请回溯Prometheus targets页确认dify-api任务状态是否为UP。
