用户说“怎么还没好”，我需要知道它是在排队、下载、转码，还是正在推理。只有一条 failed 日志不够用。
要解决什么
从一个 task_id 找到这次执行的过程，并区分业务失败、节点故障和模型耗时。
有哪些方案
可以先搭一整套监控平台，也可以继续靠各进程的自由文本日志。我先统一结构化事件和时间边界，再接可视化工具。OpenTelemetry 的日志、指标和追踪可作为后续接入约定。OpenTelemetry Signals
第一版怎样做
每条事件至少带 task_id、step_id、attempt_id、node_id、阶段、事件名和错误码。没有某字段时留空，不拿用户邮箱当关联键。
把时间拆开：服务端记入队和领取时间，Worker 用单调时钟测下载、模型加载、预处理、推理、上传耗时，服务端再记结果提交。不同机器的墙上时间可能偏移，不能直接相减当成精确耗时。
日志里记录文件 ID，不记录密码、token、完整签名 URL 或默认输出完整转写内容。错误码先做少量稳定分类，详细堆栈留在内部日志。前端显示能采取行动的信息，例如“下载超时，可重试”。
先统计队列最老等待时间、各步骤耗时、重试次数、租约过期数和节点可用槽位。不要把每个 task_id 放进指标标签；按步骤类型、模型、后端等有限维度聚合，单任务信息放日志和 trace。
接入追踪时，消息携带 trace 上下文，每次重试建立新的执行 span，并关联原步骤。长时间排队单独记录，不让一条覆盖数小时的 HTTP span 代替整个异步流程。
源码落点是两个 Worker 的 process、任务服务的领取与完成路径、outbox 发送循环。前端先补阶段和最后更新时间；没有真实进度就显示阶段，不造一个百分比。
怎么验收
故意让文件下载变慢，再让推理变慢。两次都能从同一组字段看出时间花在哪里，不能只看到“总耗时增加”。模拟节点离线，检查租约过期事件是否对应新的 attempt。
第一份交付是一个任务的时间明细表。下一步再配仪表盘和 trace 页面，避免先有漂亮图表、后补数据含义。