Agentic 時代必備技能：手把手為 Dify 應用構建全鏈路可觀測系統
前言
Dify 是時下熱門的低代碼 LLM 應用開發平臺，其豐富的模型支持、Prompt 編排、RAG 引擎、Workflow/Agent 框架以及插件生態大大便利了 Agentic 應用的開發。
生產級的 Agentic 應用涉及大量動態內容，諸如歷史會話、記憶處理，工具調用、知識庫召回，模型生成，腳本執行和流程控制等環節給 Agentic 應用生成的效果帶來很大不確定性。可觀測性貫穿 Agentic 應用開發調試、運維迭代的全生命周期，并串聯 Agentic 應用執行和上下游系統中的工具、模型和調用方，是支撐 Agentic 應用生產落地的關鍵。
圖片
Dify 可觀測的兩個視角丨開發者 & 運維方
對 Dify 這類低代碼平臺的可觀測性需求，有開發者和平臺運維兩個視角。
Agentic 應用開發者使用 Dify SaaS 或自部署的 Dify 服務開發 Workflow 應用，專注于 Workflow 的構建，觀測的主體是 Dify 平臺上運行的一個個 Workflow 應用。關注點在于 Workflow 整體和其中 RAG、Tool、LLM 等各個步驟的執行，開發者依賴可觀測服務監測大模型應用生成效果和性能，追蹤用戶多輪會話的交互體驗。在 Agentic 應用開發構建和上線后的迭代維護階段可觀測能力都是 Agentic 應用持續優化的關鍵。
Dify 平臺運維方關注 Dify 集群中從基礎設施到各個組件的負載和異常情況，管理 Dify 和上下游的服務和依賴，觀測的主體是 Dify 集群及其上下游依賴。Dify 集群包含執行引擎、插件引擎、任務隊列、沙箱環境和存儲服務等十多個組件；同時還涉及調用方、模型服務、工具訪問、外部知識庫等上下游依賴。請求過程的全鏈路可觀測是線上問題追溯，性能瓶頸定位的關鍵工具。
Dify 可觀測現狀 & 痛點
可觀測性一直是 Dify 社區活躍的議題，目前 Dify 原生支持的可觀測能力由三個方面組成。
其一是 Dify 內置的應用監控能力，數據采自 Dify 執行引擎運行過程中生成的執行明細記錄，存儲在 Dify 數據庫內。其特點是和 Dify 自身的集成度最高，在開發調試階段使用非常方便。
圖片
然而內置的應用監控在分析能力和性能兩個方面存在不足。在分析能力上，Workflow 上線后對其觀測數據需要多維度的聚合分析或二次加工，問題排查也需要關鍵字、時間范圍、模糊匹配、錯誤類型等多維度的檢索能力，但 Dify 自帶的監控只能通過會話 ID 和用戶 ID 等有限方式檢索，不能滿足數據分析和問題排查的需要。在性能上，受限于在 DB 中記錄執行日志的數據存儲方式，內置應用監控在大規模應用的生產環境下性能不佳，日志數據加載較慢甚至大量的執行明細數據會拖慢數據庫整體性能，需要在后臺 Celery 任務中配置清理任務周期性清理日志數據。
其二是 Dify 官方集成的第三方應用追蹤服務，包括云監控 / Langfuse 和 LangSmith 等。數據采自 Dify 特有的 OpsTrace 事件機制和 Dify 引擎生成的執行明細記錄，主要采集 Workflow/Agent 層面的大模型、工具、知識庫召回等節點信息。阿里云云監控從 Dify v1.6.0 起也集成了 Dify 官方可觀測能力，提供全托管免運維的可觀測服務。
圖片
第三方集成的追蹤服務痛點在于數據采集粒度受限且缺少全鏈路追蹤能力。Dify 集成的第三方應用追蹤服務主要關注 Agentic 應用開發者視角下的 Wrokflow 執行情況，更多地用于 Prompt 調優、Wrokflow 優化、數據分析等場景，但對于自建 Dify 集群時平臺運維方的集群監控和上下游全鏈路問題排查能提供的幫助就很有限。同時受限于 Dify 的 OpsTrace 機制，能夠采集的數據粒度在 Workflow 節點層面，其他更細粒度的數據支持起來比較困難。
其三是對 Dify 集群自身的可觀測性，面向 Dify 集群各組件及上下游依賴的全鏈路可觀測。目前 Dify 原生支持 Sentry 和 OpenTelemetry 兩套可觀測方式。兩者主要采集 Flask、HTTP、DB、Redis、Celery 等框架層面的數據，對 Dify 自身的內部執行邏輯未做埋點。Sentry 由于相對封閉，目前社區 issue 主要轉向更開放的 OTel 生態。
原生 OTel 方式的痛點在于采集的數據非常有限，無法串聯上下游實現全鏈路追蹤且無法與 Workflow 執行明細數據聯動。原生的 OTel 只支持對 Dify 執行引擎和 Celery 任務組件埋點，采集的信息并不完整，同時由于 Dify 架構復雜且存在部分自定義協議，缺少全鏈路可觀測以及和 Workflow 執行明細數據聯動的能力。
Dify 全景可觀測——挑戰與方案
針對現有可觀測方案的痛點，云監控上線了 Dify 全組件無侵入探針 + Dify 官方集成的應用追蹤服務組合的 Dify 全景可觀測解決方案，滿足 Dify Agentic 應用開發者和 Dify 平臺維護者兩個視角對可觀測性的需要，實現對執行引擎、插件引擎、沙箱環境、插件運行時以及 Workflow 應用的全方位監控。在這一過程中，因 Dify 架構復雜迭代迅速，全景可觀測的實現面臨多項挑戰：
1. Dify 組件眾多，執行鏈路復雜
Dify 請求經過網關入口、執行引擎、插件引擎、代碼沙箱、插件運行時等多個組件，關聯 Celery 后臺任務隊列，插件運行時受插件引擎的私有協議管理，鏈路復雜。
云監控為執行引擎、插件運行提供 Python 探針，通過函數 Patch 實現零代碼改動的無侵入埋點；為插件引擎和代碼沙箱提供 Go 探針，通過編譯時插樁實現無侵入注入；為 Nginx 和 Celery 任務隊列提供 OTel 探針的解決方案；對于生命周期受插件引擎管控的插件運行時，通過代碼插樁改造插件拉起流程，引入探針掛載邏輯。最終對 Dify 集群內的各個組件，只需配置環境變量并修改啟動命令即可實現無侵入注入。
2. Dify 迭代迅速，代碼變動頻繁
Dify 社區已有 1000+ 貢獻者，經常一周甚至數天發布一個版本。Dify 實現的頻繁變動給無侵入探針的實現帶來很大挑戰，純無侵入方式很難跟上 Dify 的發版節奏。
云監控團隊和社區積極合作，對接官方提供的第三方集成方式，對于 Dify 內部易變的 Workflow 執行邏輯采用官方方式上報，由社區維護版本更迭引起的改動。同時在無侵入探針中對 Dify 內部方法做最小依賴，僅處理框架層面的埋點和上下文傳遞過程中的斷鏈問題。
3. Dify 官方集成的監測和 OTel 生態難以串聯
Dify 官方集成的第三方應用監控服務使用 Dify 自定義的 OpsTrace 機制，采用異步后聚合的方式上報追蹤數據，這和標準的 OTel 實現存在較大差異。現有的集成方如 Langfuse 等都無法實現官方的應用追蹤和全鏈路追蹤結合。
云監控采用 OTel 格式上報數據，在 Dify 引擎掛載探針時將 traceId 信息透傳到后臺的 Celery 任務，通過 Trace Link 方式關聯 Dify 官方集成方式上報的 Workflow 執行明細數據和無侵入探針上報的全鏈路追蹤數據，實現全景可觀測。
云監控可觀測集成
接入速覽
云監控給 Dify 的各個組件都提供了可觀測方案，其中 Workflow 應用無需掛載探針，在 Dify 控制臺上為需要監控的應用開啟追蹤即可。其余組件需要掛載探針實現監控，其中 API 和 Plugin-Daemon 是核心的工作流和插件系統執行引擎，推薦優先掛載。Sandbox、Worker、Nginx 按需可選掛載。
版本要求
Python 探針
使用最新版 Python 探針即可，Dify v1.x 版本都可用，因為只采 HTTP/Flask/Redis/DB 等框架層數據，所以 Python 探針對 Dify 版本無強要求。Dify v1.8.0 以后的版本支持通過 Trace Link 方式串聯 Dify 官方集成上報的 Workflow 執行明細數據。
Go 探針
使用最新版本的 Go 探針即可，Dify v1.x 版本都可用，提供對 dify-plugin-damon 的監控，同時支持對插件生命周期進行監控。
Dify 原生監控
從 Dify v1.6.x 開始集成，更高的版本功能更全，推薦使用較新的版本。更新記錄如下：
圖片
Opentelemetry 插件
推薦首選 Python 探針，阿里云 Python 探針按照 OTel 標準實現，并在探針基座和數據上報上做了增強。Dify 的 Worker、Nginx 可以使用 OTel 方案。Dify 從 v1.3.0 開始支持 OTel 配置，但上報端點存在兼容性問題，從 Dify v1.7.0 以后支持上報到阿里云的云監控2.0/ARMS 后端。
監控 Workflow 應用
使用 Dify 官方集成的云監控可采集 LLM、Tool、RAG 等 Workflow 層面的 Trace 數據，即 Dify 官方集成的監控采集大模型應用數據，一個 Workflow 對應一個大模型應用。
限于 Dify 框架特性，Dify 官方集成的云監控和 Python 探針采集的 Trace 無法直接聯通，但可以通過 Trace Link 方式實現大模型應用和微服務應用的相關關聯，通過 Python 探針和 Dify 原生監控組合實現 API 組件的可觀測。
前提條件
Dify 版本 >= 1.6.0
步驟一：獲取阿里云 Endpoint 和 License Key
方式一）云監控 2.0 且 Dify 版本 >= 1.9.1 的用戶推薦使用云監控 2.0 的上報端點：
1. 登錄云監控 2.0 控制臺，在左側導航欄單擊接入中心。
2. 在應用監控&鏈路追蹤區域單擊 Dify 卡片。
3. 在彈出的接入面板中選擇數據上報地域，點擊獲取 LicenseKey。
4. 記錄生成的 LicenseKey 和 Endpoint。
圖片
方式二）ARMS 用戶或 Dify 版本在 1.6.0～1.9.0 的用戶可以使用 ARMS 的上報端點，數據也會在云監控 2.0 上同步呈現：
1. 登錄 ARMS 控制臺，在左側導航欄單擊接入中心。
2. 在服務端應用區域單擊 OpenTelemetry 卡片。
3. 在彈出的 OpenTelemetry 面板中選擇數據上報地域，上報方式選 gRPC。
4. 記錄生成的 LicenseKey 和 Endpoint，注意 Endpoint 不要帶端口號。
步驟二：配置應用性能追蹤
1. 登錄 Dify 控制臺，并進入需要監控的 Dify 應用。
2. 在左側導航欄單擊監測。
3. 單擊追蹤應用性能，然后在云監控區域單擊配置。
4. 在彈出的對話框中輸入步驟一獲取的 License Key 和 Endpoint，并自定義 App Name（ARMS 控制臺顯示的應用名稱），然后單擊保存并啟用。
圖片
步驟三：查看 Dify 應用監控數據
配置完畢后在 Dify 控制臺或通過 Dify API 發起幾次請求，稍等 1～2 分鐘即可登錄阿里云控制臺查看上報的數據。
方式一：監控 2.0 用戶在應用中心- AI 應用可觀測處查看
方式二：ARMS 用戶在 LLM 應用監控處查看
應用詳情示例：
圖片
調用鏈詳情示例：
LLM 節點會采集系統/用戶提示詞、模型輸出、模型提供商和型號、token 用量等信息。
圖片
Retriever 節點會采集查詢語句、召回片段、關聯文檔元數據、embbeding 評分等信息。
圖片
Tool 節點會采集工具參數和調用結果、工具提供商和描述等信息。
圖片
其他流程節點也都會采集節點的輸入輸出、會話 ID、用戶 ID 等必要數據。
接入可參考文檔[3][4]。
監控執行引擎 API
API 是 Dify 執行引擎。使用 Python 探針可采集 HTTP/Flask/Redis/DB 等框架層面的 Trace 數據，并關聯上下游調用實現全鏈路追蹤，即 Python 探針采集微服務數據，API 組件對應一個微服務應用。
步驟一：安裝 Python 探針
首先需要卸載沖突的 OTel 插件，下載并安裝 Python 探針。
啟動腳本開頭改動
# 確保pip環境
python -m ensurepip --upgrade
# 卸載沖突的OTel插件
pip3 uninstall -y opentelemetry-instrumentation-celery \
opentelemetry-instrumentation-flask \
opentelemetry-instrumentation-redis \
opentelemetry-instrumentation-requests \
opentelemetry-instrumentation-logging \
opentelemetry-instrumentation-wsgi \
opentelemetry-instrumentation-fastapi \
opentelemetry-instrumentation-asgi \
opentelemetry-instrumentation-sqlalchemy
# 安裝Python探針
pip3 config set global.index-url https://mirrors.aliyun.com/pypi/simple/ && pip3 config set install.trusted-host mirrors.aliyun.com
pip3 install aliyun-bootstrap && aliyun-bootstrap -a install提示：
可以通過 Docker 數據卷掛載方式用修改后的啟動腳本替換原腳本（修改源碼并重打鏡像也可以）。即將修改后的腳本作為配置項掛載到容器目錄內，并指定容器從此腳本啟動。例如：
將修改后的腳本 entrypoint.sh 存儲為配置項，并掛載到容器目錄 /app/api/docker。
指定啟動命令：["/bin/bash","/app/api/docker/entrypoint.sh"]
步驟二：修改啟動命令
在啟動腳本最后的應用啟動部分做修改，從 aliyun-instrument 啟動：
啟動腳本末尾改動
# 使用aliyun-instrument啟動
exec aliyun-instrument gunicorn \
--bind "${DIFY_BIND_ADDRESS:-0.0.0.0}:${DIFY_PORT:-5001}" \
--workers ${SERVER_WORKER_AMOUNT:-1} \
--worker-class ${SERVER_WORKER_CLASS:-gevent} \
--worker-connections ${SERVER_WORKER_CONNECTIONS:-10} \
--timeout ${GUNICORN_TIMEOUT:-200} \
app:app同理此步驟也可以通過修改鏡像打包過程或通過掛載 K8S 配置項并替換 Dify 啟動腳本的方式實現。
步驟三：配置環境變量
配置如下環境變量，應用名、地域和 License Key 根據實際情況填寫。
步驟四：部署并查看 API 監控數據
進入應用監控列表可以看到 dify-api 應用，應用詳情示例：
調用鏈會串聯上下游調用信息，示例數據：
可以參考文檔[5]，注意如果直接使用 ack-onepilot 自動注入，會存在 Dify 自帶的 OTel SDK 和 Python 探針沖突的問題，還需要手動改啟動腳本卸載沖突的 OTel 依賴。
監控插件引擎 Dify-Plugin-Daemon
Dify-Plugin-Daemon 是 Dify 的插件管理器，Dify 的 LLM、插件、Agent 策略的執行都依賴 Plugin-Daemon。Go Agent[2]支持監控 Dify-Plugin-Daemon，接入 Go 監控需修改Dockerfile、重新編譯鏡像后配置環境變量開啟。Plugin-Daemon 的 Go 探針同時也會自動為插件運行時掛載 Python 探針。
步驟一：修改 Dockerfile 文件重新編譯對應鏡像
local.dockerfile 修改示例
DockerFile
FROM golang:1.23-alpine AS builder
ARG VERSION=unknown
# copy project
COPY . /app
# set working directory
WORKDIR /app
# using goproxy if you have network issues
# ENV GOPROXY=https://goproxy.cn,direct
# download arms instgo
RUN wget "http://arms-apm-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/instgo/instgo-linux-amd64" -O instgo
RUN chmod 777 instgo
# instgo build
RUN INSTGO_EXTRA_RULES="dify_python" ./instgo go build \
-ldflags "\
-X 'github.com/langgenius/dify-plugin-daemon/internal/manifest.Versinotallow=${VERSION}' \
-X 'github.com/langgenius/dify-plugin-daemon/internal/manifest.BuildTimeX=$(date -u +%Y-%m-%dT%H:%M:%S%z)'" \
-o /app/main cmd/server/main.go
# copy entrypoint.sh
COPY entrypoint.sh /app/entrypoint.sh
RUN chmod +x /app/entrypoint.sh
FROM ubuntu:24.04
WORKDIR /app
# check build args
ARG PLATFORM=local
# Install python3.12if PLATFORM is local
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y curl python3.12 python3.12-venv python3.12-dev python3-pip ffmpeg build-essential \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* \
&& update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.12 1;
# preload tiktoken
ENV TIKTOKEN_CACHE_DIR=/app/.tiktoken
# Install dify_plugin to speedup the environment setup, test uv and preload tiktoken
RUN mv /usr/lib/python3.12/EXTERNALLY-MANAGED /usr/lib/python3.12/EXTERNALLY-MANAGED.bk \
&& python3 -m pip install uv \
&& uv pip install --system dify_plugin \
&& python3 -c "from uv._find_uv import find_uv_bin;print(find_uv_bin());" \
&& python3 -c "import tiktoken; encodings = ['o200k_base', 'cl100k_base', 'p50k_base', 'r50k_base', 'p50k_edit', 'gpt2']; [tiktoken.get_encoding(encoding).special_tokens_set for encoding in encodings]"
ENV UV_PATH=/usr/local/bin/uv
ENV PLATFORM=$PLATFORM
ENV GIN_MODE=release
COPY --from=builder /app/main /app/entrypoint.sh /app/
# run the server, using sh as the entrypoint to avoid process being the root process
# and using bash to recycle resources
CMD ["/bin/bash", "-c", "/app/entrypoint.sh"]注意 INSTGO_EXTRA_RULES 選項會開啟 Plugin 運行時自動監測功能，如果不需要在 Plugin-Daemon 啟動時拉起對 Plugin 探針，可以去除編譯文件中的INSTGO_EXTRA_RULES="dify_python"。
步驟二：配置環境變量
方式一）ECS 環境
方式二）容器化 ack-onepilot 環境
在 dify-plugin-daemon 應用的 YAML 配置中將以下 labels 添加到 spec.template.metadata 層級下。
labels:
aliyun.com/app-language: golang
armsPilotAutoEnable: 'on'
armsPilotCreateAppName: "dify-daemon-plugin"步驟三：部署并查看 dify-plugin-daemon 監控
在應用列表頁面進入 dify-plugin-daemon 應用，監控詳情如下：
調用鏈詳情：
步驟四：查看 Plugin 監控
掛載探針后，Plugin-Daemon 會自動拉起插件運行時的探針。每個插件運行時對應一個可觀測應用，應用名為 {plugin_daemon_name}_plugin_{plugin_name}_{plugin_version}。例如，Plugin-Daemon 配置的應用名為 local-dify-plugin-daemon，安裝了 tongyi 的 version 0.0.53 插件時，會自動生成應用 local-dify-plugin-daemon_plugin_tongyi_0.0.53。
插件監控概覽頁示例：
(可選) 監控代碼沙箱 Sandbox
Sandbox 是 Dify 代碼沙箱引擎，負責執行 Workflow 中的 Python/Node.js 代碼。Go 探針支持監控 Sandbox，需修改 Dockerfile、重新編譯鏡像后配置環境變量開啟。
步驟一：修改 Dockerfile 文件重新編譯對應鏡像
修改 ./build/build_[amd64|arm64].sh 文件。
a. 添加 instgo 下載命令。
下載命令示例如下，其他地域和架構的下載命令請參見下載 instgo。
（https://help.aliyun.com/zh/arms/application-monitoring/developer-reference/instgo-tool-introduction#9b94bbe8a62ra）
wget "http://arms-apm-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/instgo/instgo-linux-amd64" -O instgo
chmod 777 instgob. 在 go build 前添加 instgo 命令。
以 amd64 為例，修改示例如下：
rm -f internal/core/runner/python/python.so
rm -f internal/core/runner/nodejs/nodejs.so
rm -f /tmp/sandbox-python/python.so
rm -f /tmp/sandbox-nodejs/nodejs.so
wget "http://arms-apm-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/instgo/instgo-linux-amd64" -O instgo
chmod 777 instgo
echo "Building Python lib"
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 ./instgo go build -o internal/core/runner/python/python.so -buildmode=c-shared -ldflags="-s -w" cmd/lib/python/main.go &&
echo "Building Nodejs lib" &&
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 ./instgo go build -o internal/core/runner/nodejs/nodejs.so -buildmode=c-shared -ldflags="-s -w" cmd/lib/nodejs/main.go &&
echo "Building main" &&
GOOS=linux GOARCH=amd64 ./instgo go build -o main -ldflags="-s -w" cmd/server/main.go
echo "Building env"
GOOS=linux GOARCH=amd64 ./instgo go build -o env -ldflags="-s -w" cmd/dependencies/init.go步驟二：配置環境變量
方式一）無 ack-onepilot 環境
方式二）容器化 ack-onepilot 環境
在 dify-plugin-daemon 應用的 YAML 配置中將以下 labels 添加到 spec.template.metadata 層級下。
labels:
aliyun.com/app-language: golang
armsPilotAutoEnable: 'on'
armsPilotCreateAppName: "dify-daemon-plugin"步驟三：部署并查看 sandbox 監控
在應用列表頁面進入 dify-sandbox 應用，監控詳情如下：
調用鏈詳情：
參考文檔：
監控 Go 應用
(可選) 監控任務隊列 Worker
Worker 是 Dify 后臺任務組件，知識庫構建和周期性清理任務依賴 Worker 執行。按普通 Python Celery 應用方式接入即可。這里給出使用 Dify 內置的 OTel 插件上報數據的示例：
步驟一：修改 Worker 環境變量
OTel 插件是 Dify 內置功能，直接修改環境變量即可。注意要求 Dify 1.7.0 以上版本。
步驟二：部署并查看 Worker 監控
進入應用監控/ OpenTelemetry 監控頁面查看上報的數據。
Worker 執行的后臺任務 Trace 詳情示例：
(可選) 監控入口網關 Nginx
Nginx 是 Dify 的入口網關，一些超時問題和知識庫/插件/Workflow 的文件上傳問題可能和 Nginx 配置有關。
直接使用 Opentelemetry 方式上報即可，推薦使用預構建的 Nginx-OTel 鏡像方式。
步驟一：下載預構建 Docker 鏡像
前往 Docker 官網，搜索并拉取帶有 -otel 后綴的 Nginx 鏡像（如 nginx:1.29.0-otel），通過標準容器啟動流程部署服務。
步驟二：獲取 gRPC 接入點和鑒權 Token 信息
登錄可觀測鏈路 OpenTelemetry 版控制臺，在接入中心選取 OpenTelemetry 卡片，選擇 gRPC 協議上報數據。
記錄接入點和鑒權 Token 備用。
在開源框架區域單擊，在彈出的 OpenTelemetry 面板中選擇數據需要上報的地域。
步驟三：啟用 Nginx OTel 模塊
修改 Nginx 配置文件 nginx.conf.template：
Nginx 配置文件
load_module modules/ngx_otel_module.so; # 加載 ngx_otel_module
...
http {
...
otel_exporter {
endpoint "${GRPC_ENDPOINT}"; # 前提條件中獲取的 gRPC 接入點
header Authentication "${GRPC_TOKEN}"; # 前提條件中獲取的鑒權 Token
}
otel_trace on; # 開啟鏈路追蹤
otel_service_name ${SERVICE_NAME}; # 應用名
otel_trace_context propagate; # 向下游服務注入Trace上下文
...
}
圖片
可參考文檔[6]接入 Nginx 監控。
實踐指南
關聯 LLM Trace 和微服務 Trace：
Dify 的 Workflow 執行數據通過官方集成方式上報 Trace，而 Dify-api、Dify-Worker、Dify-Plugin-Daemon 等基礎設施通過無侵入探針按 OTel 標準上報 Trace。這兩套割裂的體系無法直接融合，阿里云提供了 Trace Link 能力，將應用層和基礎設施層的兩條 Trace 串聯。
從 LLM Trace 跳轉微服務 Trace：
進入一條 LLM Trace 的詳情，可以看到完整的 Workflow 執行數據，但如何找到基礎設施組件的 span 和上下游串聯數據？
選中一個 span，在 span 右側的附加信息面板選擇 Links 標簽頁，可以看到和此 LLM Trace 相關聯的基礎設施 Trace 的信息。
點擊“查詢關聯的調用鏈”，可以直接跳轉到關聯的基礎設施 Trace：
從 微服務 Trace 跳轉 LLM Trace：
在基礎設施的微服務 Trace 上，可以看到 nginx、dify-api、dify-plugin-daemon、dify-sandbox 等各個組件的 Trace 數據，是否可以將它關聯到 Dify 官方集成的 Trace 數據上？
點擊調用鏈上方的篩選功能，用 span 名稱篩選，找到名稱為 AdvancedChatAppRunner.run 或 WorkflowAppRunner.run 的 span。（取決于 Dify Workflow 的類型，如果調用了子 Workflow 可能會有多個這樣的 span）。
如果對應的 Workflow 開啟了云監控追蹤，在 span 附加信息的 Links 頁簽可以看到關聯的 LLM Trace Id，點擊“查詢關聯的調用鏈”可跳轉到相應 LLM Trace。
分析執行引擎異常根因
工作流層面的異常通常在 LLM Trace 或 Dify 日志追蹤里可以看到直觀的報錯信息，但還有一類錯誤是底層 Dify 引擎的配置不當或內部 bug 引起的。無侵入探針提供了對這類錯誤的定位分析能力。
如圖的示例場景，在 Dify Workflow 的某次執行中發現知識檢索的輸出總是為空，但是 Dify 控制臺上又沒有報錯信息：
圖片
此時，可以根據 Dify 對話 ID、用戶 ID 等信息在云監控上定位對應的 LLM Trace：
進入會話詳情，找到對應 Trace 和相關 Span，首先嘗試在 Span 詳情中查找相關信息：
這個 Case 的問題不在 Wrokflow 層面，所以只能觀察到輸出異常，要定位具體原因，可以通過上一節介紹的 Links 功能，跳轉到對應的 Dify infra 層 Trace：
可以觀察到 Trace 上存在部分錯誤 Span，通過快捷篩選直接定位錯誤 Span：
在錯誤 Span 的 Details 和 Events 中，可以看到錯誤信息和異常堆棧。并定位到根因是 Weaviate 向量存儲配置引起的問題。
定位插件慢調用
Dify 社區提供了豐富的插件生態，但管理插件的 Dify-Plugin-Daemon 和插件運行時卻是難以定位故障的黑盒。在 Dify 控制臺上能清晰地看到各個工作流節點的運行記錄，但對于流程節點之下 Dify infra 設施的故障卻無從分析。一次 Workflow 調用鏈路涉及 Nginx、API、Plugin-Daemon、Plugin 運行時和模型網關等多個組件，阿里云云監控提供的全鏈路追蹤能力可以串聯上下游的完整鏈路，定位插件內的錯慢異常。
如圖示例中“查詢 SLS 日志”是一個 Dify 插件，正常調用只需 200 ms，但在這個 Trace 中卻有 5s 多的慢調用。僅看 LLM Trace 或 Dify 執行日志，無法判斷慢請求是因為 Dify-Api 引擎、Dify-Plugin-Daemon 插件引擎、Dify-Plugin 運行時或者 SLS 日志服務本身導致的。
通過 Links 找到關聯的 Infra 層調用，可以看到 Trace 詳情：
Dify 引擎會做大量 DB 和 Redis 訪問，排查非 DB/Redis 類問題時，可以在組件標簽處點選并濾去 sqlalchemy 和 redis 組件的 Span 以便排查。
可以看到 dify 執行引擎（local-dify-api）發起了對 dify 插件引擎（local-dify-plugin-daemon）的 POST 調用，插件引擎調用插件運行時（local-dify-plugin-daemon_plugin_cms_0.0.1）并轉發請求給 SLS 服務端口。整個鏈路上耗時最長的是 dify_plugin_execute，這是插件運行時內部的入口方法，我們正是在此處注入了故障模擬的慢調用。
歡迎大家加入我們的釘釘群，共同構建更好的 Dify 全鏈路監控能力。
- LoongSuite Python 開源交流群：101925034286
- LoongSuite Go Agent 開源交流群：102565007776
- ARMS 多語言應用監控產品交流群：159215000379
參考：
[1] 獲取 LicenseKeyhttps://help.aliyun.com/zh/arms/application-monitoring/developer-reference/api-arms-2019-08-08-describetracelicensekey-apps
[2] ARMS 應用監控支持的 Go 組件和框架
[3] Dify 官方監控接入
https://help.aliyun.com/zh/arms/tracing-analysis/untitled-document-1750672984680
[4] 集成阿里云云監控
https://docs.dify.ai/zh-hans/guides/monitoring/integrate-external-ops-tools/integrate-aliyun
[5] Dify Python 探針接入
https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/monitor-dify-applications
[6] 使用 OpenTelemetry 對 Nginx 進行鏈路追蹤
