dify记录工作流日志从mysql切换到aliyun sls

Posted on Views:

目的

发现工作流节点记录数据太大导致表workflow_node_execution数据剧增，官方支持记录这块信息到sls。

env

  • dify + aliyun-sls

1.放开sls配置及core_workflow执行体

## 1.CORE_WORKFLOW_EXECUTION修正
# Repository configuration
# Core workflow execution repository implementation
#CORE_WORKFLOW_EXECUTION_REPOSITORY=core.repositories.sqlalchemy_workflow_execution_repository.SQLAlchemyWorkflowExecutionRepository
CORE_WORKFLOW_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_workflow_execution_repository.LogstoreWorkflowExecutionRepository

# Core workflow node execution repository implementation
#CORE_WORKFLOW_NODE_EXECUTION_REPOSITORY=core.repositories.sqlalchemy_workflow_node_execution_repository.SQLAlchemyWorkflowNodeExecutionRepository
CORE_WORKFLOW_NODE_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_workflow_node_execution_repository.LogstoreWorkflowNodeExecutionRepository

# API workflow node execution repository implementation
#API_WORKFLOW_NODE_EXECUTION_REPOSITORY=repositories.sqlalchemy_api_workflow_node_execution_repository.DifyAPISQLAlchemyWorkflowNodeExecutionRepository
API_WORKFLOW_NODE_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_api_workflow_node_execution_repository.LogstoreAPIWorkflowNodeExecutionRepository

# API workflow run repository implementation
#API_WORKFLOW_RUN_REPOSITORY=repositories.sqlalchemy_api_workflow_run_repository.DifyAPISQLAlchemyWorkflowRunRepository
API_WORKFLOW_RUN_REPOSITORY=extensions.logstore.repositories.logstore_api_workflow_run_repository.LogstoreAPIWorkflowRunRepository

## 2.sls ak
# Aliyun SLS Logstore Configuration
# Aliyun Access Key ID
ALIYUN_SLS_ACCESS_KEY_ID=

# Aliyun Access Key Secret
ALIYUN_SLS_ACCESS_KEY_SECRET=

# Aliyun SLS Endpoint (e.g., cn-hangzhou.log.aliyuncs.com)
ALIYUN_SLS_ENDPOINT=cn-hangzhou-intranet.log.aliyuncs.com   # 内网
#ALIYUN_SLS_ENDPOINT=cn-hangzhou-intranet.log.aliyuncs.com   # 公网

# Aliyun SLS Region (e.g., cn-hangzhou)
ALIYUN_SLS_REGION=cn-hangzhou

# Aliyun SLS Project Name
ALIYUN_SLS_PROJECT_NAME=dify-sls

# Number of days to retain workflow run logs (default: 365 days， 3650 for permanent storage)
ALIYUN_SLS_LOGSTORE_TTL=1

# Enable dual-write to both SLS LogStore and SQL database (default: false)
LOGSTORE_DUAL_WRITE_ENABLED=false

# Enable dual-read fallback to SQL database when LogStore returns no results (default: true)
# Useful for migration scenarios where historical data exists only in SQL database
LOGSTORE_DUAL_READ_ENABLED=false

# Control flag for whether to write the `graph` field to LogStore.
# If LOGSTORE_ENABLE_PUT_GRAPH_FIELD is "true", write the full `graph` field;
# otherwise write an empty {} instead. Defaults to writing the `graph` field.
LOGSTORE_ENABLE_PUT_GRAPH_FIELD=true

2.启动发现有错误日志

这个问题很典型，主要是因为 Dify 的 SLS（阿里云日志服务）初始化逻辑在面对多容器并发启动时，缺乏对“资源已存在”情况的优雅处理。

errorCode=ProjectAlreadyExist

2.1为什么会发生这种情况？

  1. 并发竞争（Race Condition）： 当你执行 docker-compose up 时，dify-api 和 dify-worker 几乎同时启动。它们都会尝试去调用阿里云 API 创建名为 dify-sls-test 的 Project。
  2. 非幂等操作： 阿里云的 create_project 接口在项目已存在时会直接返回 ProjectAlreadyExist 错误。
  3. 异常处理过于严格： 从报错日志看，Dify 的 aliyun_logstore.py 在捕获到这个错误后，没有识别出“已存在”其实也是一种“成功状态”，而是直接抛出异常并导致整个 Logstore 扩展初始化失败。

忽略即可，仅仅第一次有告警。

2.2解决方案

你可以根据你的环境灵活选择以下几种方案：

方案一：手动预启动（最简单，无需改代码）

既然是因为并发创建导致的冲突，我们可以让它们“排队”。

  1. 在阿里云后台手动删除那个已经半途而废的 dify-sls-test 项目（或者保留它也行）。
  2. 先只启动一个容器：
1
docker-compose up -d dify-api
  1. 观察 dify-api 的日志，确认它完成了 SLS 项目、Logstore 和索引的创建。
  2. 再启动其他容器：
1
docker-compose up -d

3.注意点

  • 申请阿里云ak注意sls/log权限管理
  • 默认不要人工创建sls项目日志库

56fef4d546c78b8872e9a8236b8b5623.png