问题自查与信息采集
当节点运行失败或结果不符合预期时，请先确认问题能够稳定复现，并记录问题环境、发生时间、操作步骤、期望结果、实际结果和影响范围。如果仍无法解决，再通过所在项目认可的支持渠道提交问题。
排查时应优先使用 DeepFOS Logger 采集复现日志。插件导出的 JSON 已包含接口请求、响应、cURL 和环境版本探测结果，通常不需要再按 F12 手工收集接口信息或单独查询版本。只有涉及组件服务节点时，才建议额外补充组件服务调用日志。
推荐的采集顺序
-
准备最短复现步骤，并记录问题环境、发生时间、问题页面、数据流和节点等基本信息。
-
优先使用 DeepFOS Logger 录制一次完整复现过程，导出 JSON 日志并随工单上传。
-
如果问题涉及组件服务节点，再补充相关节点日志或完整运行日志。
-
只有无法安装、加载或正常使用 DeepFOS Logger 时，才按本文的替代方式手工收集接口信息和版本号。
使用 DeepFOS Logger 采集复现日志（推荐）
开始录制后，按最短步骤复现一次问题，再停止录制并导出 JSON 日志。JSON 是排障交付的首选文件，包含本次会话摘要、扩展版本、环境版本探测结果和接口明细，可以替代手工复制 Payload、Response、cURL 以及单独查询前后端版本等零散操作。
DeepFOS Logger 会采集录制期间浏览器发起的接口请求，帮助研发定位网络错误、接口错误和常见业务错误。它不是录屏工具，不会记录鼠标点击和页面画面；需要展示页面现象时，请另外截图。
安装、录制和导出方法参见问题日志采集（DeepFOS Logger）使用指南。导出后，请将 JSON 文件与问题基本信息一起作为工单附件上传。
导出的 JSON 日志可能包含 Cookie、Authorization、访问令牌、用户标识或业务数据。请将其作为敏感日志处理，仅通过所在项目认可的工单或文件传输渠道提供给授权排查人员。
收集组件服务调用日志（必要时补充）
DeepFOS Logger 主要采集浏览器发起的接口请求。如果组件服务类型的节点报错，或结果与预期不符，还需要查看数据流后端调用其他组件服务时提交的详细数据。此时可以在【设置-PY 设置】的公共脚本中临时加入以下配置：
from deepfos.options import OPTION
OPTION.api.dump_always = True
OPTION.general.log_level = "DEBUG"
具体配置入口参见全局设置。
保存后重新调试相关节点，节点日志会输出调用其他组件服务的详细信息和 cURL。请复制完整节点日志并随工单上传。也可以重新运行整个数据流，然后在运行历史中下载完整日志文件。
DEBUG 日志可能包含请求参数和敏感信息。问题定位完成后，建议移除临时配置或恢复原日志级别，避免长期输出大量详细日志。
无法使用 DeepFOS Logger 时的替代采集
仅当项目环境不允许安装扩展、扩展无法正常加载，或录制、导出功能不可用时，才需要按以下方式手工收集。使用 DeepFOS Logger 并成功导出 JSON 后，可以跳过本节。
收集后端接口信息
以调试失败为例，前端会调用名为 debug 的后端接口。保存数据流时通常会调用 update 接口，发布时通常会调用 deploy 接口，其他操作也可以用相同方法定位对应请求。
-
按
F12打开浏览器开发者工具。 -
切换到
Network页签，并清空已有请求记录。 -
回到数据流页面，重新执行出现问题的操作。
-
在
Network中选择对应请求，分别记录Payload和Response页签内容；建议截图并随工单上传。 -
右键请求，选择“复制”→“复制为 cURL（bash）”，将内容保存为文本附件。
cURL 可能包含 Cookie、Authorization、访问令牌、用户标识或业务数据。向无关人员传递或粘贴到公共渠道前，请先完成脱敏；提供给授权排查人员时，也应遵循所在项目的数据安全要求。
获取版本号
部分问题已在后续版本中修复，因此排查时需要同时提供数据流前端、后端和 deepfos 版本。最准确的版本信息可以由环境运维人员提供；如果项目环境允许，也可以按以下方式自行查看。
后端版本号
-
打开任意数据流元素。
-
删除浏览器地址中第一个问号及其后的查询参数。
-
在地址末尾追加
/git-version。 -
访问该地址。浏览器会直接显示版本信息，或下载包含版本信息的文件。
更多说明参见服务版本号查询。
前端版本号
-
打开任意数据流元素。
-
删除浏览器地址中第一个问号及其后的查询参数。
-
在地址末尾追加
/version.json。 -
访问该地址，浏览器会直接显示前端版本信息。
deepfos 版本号
-
在数据流中添加【PY 代码】节点。
-
输入以下代码并调试该节点：
import deepfos
return deepfos.__version__
-
调试结果即为当前数据流后端环境安装的
deepfos版本。
其他 Python 依赖也可以用相同方式检查，例如 duckdb。
资源异常与 OOM 取证
出现内存告警、Pod 重启、队列长期不推进或疑似 OOM 时，先暂停相关定时计划和批量调用，避免重复提交继续放大负载。然后记录异常实例 ID、精确时间范围、触发方式、启动参数、异常节点以及同一时段的其他运行实例。
建议保留异常前后至少 1 小时的以下信息：
-
容器或 Pod 的内存、CPU、重启次数和 memory request/limit；
-
实例【所有节点】日志、耗时甘特图，以及正常实例作为对照；
-
数据流运行进程 PID、并行父进程 PID 和对应时间，获取方法参见运行历史；
-
应用日志中的
WORKER TIMEOUT、SIGKILL、Started process for run、parent process等关键词； -
Kubernetes 的
OOMKilled、Pod 事件、容器上一次运行日志，或节点操作系统的 OOM killer 记录。
SIGKILL 也可能来自超时或人工终止，不能单独作为 OOM 结论。应使用“实例 ID + 时间窗口 + PID”把实例日志与进程 RSS、容器内存上限和系统事件对应起来。
具备相应权限时，可由运维人员参考以下命令采集；实际 Pod 名称、命名空间和日志位置以项目部署为准：
ps -o pid,ppid,rss,%mem,etime,cmd -p <pid1>,<pid2>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous
如果问题是大量实例处于【队列中】，还应同时提供最早排队时间、队列数量、启动中/进行中/取消中数量和工作进程池配置，并按并发、队列与内存优化区分正常满载与出队、启动链路异常。
提交工单前检查清单
已使用 DeepFOS Logger
-
问题现象、期望结果和实际结果；
-
可重复执行的操作步骤；
-
问题发生时间、数据流名称、节点名称和节点编码；
-
DeepFOS Logger 导出的 JSON 日志；
-
必要的页面截图；
-
涉及组件服务节点时，补充相关节点日志或完整运行日志；
-
问题影响范围，以及是否存在临时绕过方式。
不需要再重复提供 F12 中的 Payload、Response、cURL 或单独查询前后端版本。
无法使用 DeepFOS Logger
除问题基本信息、复现步骤和必要截图外，请补充：
-
对应接口的
Payload、Response和脱敏后的 cURL； -
涉及组件服务节点时，补充相关节点日志或完整运行日志；
-
数据流前端、后端和
deepfos版本号。
回到顶部
咨询热线
400-821-9199
