Dify平台可观测最佳实践

对 Dify 平台进行观测的必要性

现在越来越多企业会使用 Dify 来构建 AI 应用，把它作为连接大模型、知识库、工作流、插件工具和业务系统的统一平台。对业务团队来说，Dify 不只是一个开发工具，而是 AI 应用从想法验证到上线运行的重要底座。

正因为 Dify 承载了越来越多 AI 应用开发工作，一旦Dify平台本身不稳定，影响就会被迅速放大。比如页面响应变慢、工作流执行失败、知识库检索异常、插件调用超时、后台任务堆积，都会直接拖慢团队开发、测试和交付 AI 应用的效率。很多时候，业务同学看到的是“AI 应用不好用”，但真正的问题可能出在 Dify 平台本身、底层数据库、缓存、容器资源，或者某个外部依赖服务上。

因此，对 Dify 平台进行可观测建设，可以极大地保障企业 AI 应用开发体系的稳定性和持续交付效率。通过观测云对 Dify 的基础资源、核心服务、调用链路和运行状态进行统一观测，团队可以更快发现问题、定位瓶颈、评估影响范围，让 AI 应用开发从“出了问题再猜”变成“有数据、有链路、有依据地持续优化”。

如何对 Dify 平台进行可观测

推荐架构

Dify 核心服务通过 OTLP gRPC 将 Trace 与 Metrics 上报至本机的观测云 DataKit，由 DataKit 的 OpenTelemetry 采集插件统一接收后，再通过 DataWay 写入观测云，实现对链路、指标、容器、日志和基础设施的统一观测

安装 DataKit

登录观测云工作空间，进入「集成」→「DataKit」，复制对应平台的安装命令。Linux 主机常见命令如下：

DK_DATAWAY="https://openway.guance.com?token=<YOUR_TOKEN>" \
bash -c "$(curl -L https://static.guance.com/datakit-v2/install.sh)"

安装完成后检查服务状态：

systemctl status datakit

启用 DataKit OpenTelemetry 采集插件

进入 DataKit 安装目录，复制 OpenTelemetry 采集器配置：

cd /usr/local/datakit/conf.d/samples/
cp opentelemetry.conf.sample opentelemetry.conf

编辑配置文件，重点关注 gRPC 监听地址：

[[inputs.opentelemetry]]

  [inputs.opentelemetry.http]
    http_status_ok = 200
    trace_api = "/otel/v1/traces"
    metric_api = "/otel/v1/metrics"
    logs_api = "/otel/v1/logs"

  [inputs.opentelemetry.grpc]
    addr = "172.17.0.1:4317"
    max_payload = 16777216

说明：

• 4317 是 OTLP gRPC 常用端口。
• 9529 是 DataKit HTTP API 端口。
• 单机 Docker Compose 场景推荐让 DataKit 监听 Docker bridge 地址，例如 172.17.0.1:4317。
• 如果使用 0.0.0.0:4317，需要配合防火墙限制访问来源，避免 OTLP 端口暴露到公网。

重启 DataKit：

systemctl restart datakit

确认监听：

ss -lntup | grep 4317

部署 Dify

Dify 官方 Docker Compose 部署流程可以简化为：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

生产环境中，请根据实际情况配置数据库、Redis、对象存储、域名、HTTPS、模型供应商 Key 等。本文重点关注可观测相关配置。具体参考Dify官网（ https://docs.dify.ai/en/self-host/deploy/quick-start/docker-compose ）

Dify OpenTelemetry 环境变量

在 ~/dify/docker/.env 中增加以下变量：

ENABLE_OTEL=true
OTEL_EXPORTER_TYPE=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=grpc
OTLP_BASE_ENDPOINT=http://172.17.0.1:4317
OTLP_TRACE_ENDPOINT=http://172.17.0.1:4317
OTLP_METRIC_ENDPOINT=http://172.17.0.1:4317
OTEL_SAMPLING_RATE=1.0
OTEL_METRIC_EXPORT_INTERVAL=10000

变量说明：

修改后重启 Dify：

cd ~/dify/docker
docker compose up -d

在Dify上进行业务操作，触发otel数据上报.

在观测云上验证数据

通过Datakit的图形化调试工具datakit monitor可以很快验证。

datakit monitor

然后进入观测云控制台验证：

• 「基础设施」：查看 Dify 所在主机的 CPU、内存、磁盘、网络。

• 「容器」：查看 Dify 各容器状态、资源使用。

• 「链路」：在「应用性能监测」-「服务」中可以看到 langgenius/dify、redis、dify-api 服务。

Dify平台所产生的请求，可以在「链路」中进行分析。

• 「指标」：检查 OTEL 指标是否持续写入。在「指标」-「指标管理」找到otel_service指标集，这便是opentelemetry采集插件所上报的指标数据。

• 「日志」：Dify各个容器的日志也被DataKit上的container采集器默认采集，在「日志」功能页面可通过「数据来源」搜索各个服务的日志。

注意：Dify 1.15.0 默认将 OTEL service.name 设置为应用名，通常会聚合为 langgenius/dify。API、Worker、Worker Beat 会分别建立到 DataKit 的 OTLP 连接，但在观测云链路服务名上可能聚合展示。依赖服务如 redis、postgresql 通常会以独立服务出现在链路中。

总结

通过 DataKit + OpenTelemetry，可以用较低改造成本为 Dify 平台建立完整可观测能力。推荐实践是：

• DataKit 部署在 Dify 所在主机，负责统一采集和上报。
• Dify 通过 OTLP gRPC 直连 DataKit。
• Docker 场景避免使用 localhost 作为 OTLP 地址，优先使用 Docker bridge 地址或明确的宿主机可达地址。
• 测试期使用 OTEL_SAMPLING_RATE=1.0，生产期根据流量和成本调整。
• 在观测云中联合查看主机、容器、链路、指标和日志，实现从“平台不可用”到“具体哪个服务、哪个依赖、哪段调用慢或失败”的定位能力。

参考资料：

• 观测云 DataKit 主机安装文档
• 观测云 OpenTelemetry 集成文档
• 观测云对接 OpenTelemetry 最佳实践
• Dify 环境变量 OpenTelemetry 配置