定时任务可观测性需贯穿全生命周期，记录启动、调度、执行、结果、重试、清理等阶段的结构化事件，统一trace_id串联Metrics/Logs/Tracing，并支持离线回溯与横向对比。

定时任务的可观测性，核心在于把“看不见的后台执行”变成“可查、可比、可定位”的完整轨迹。不是只看它跑没跑，而是要看它怎么跑、在哪卡、为什么失败、耗时分布如何。

明确记录哪些关键轨迹点

一次定时任务的生命周期至少包含启动、调度、执行、结果（成功/失败/超时）、重试、清理等阶段。每个阶段都应生成结构化事件：

• 任务触发时间、实际开始执行时间、结束时间、耗时（精确到毫秒）
• 执行上下文：任务ID、计划周期（如 cron 表达式）、所属服务、实例标识
• 状态变更事件：scheduled → running → succeeded / failed / timeout / retried
• 异常详情：错误类型、堆栈片段、重试次数、最终失败原因
• 资源消耗：内存峰值、CPU 占用、外部调用次数及响应时间

统一 trace_id 贯穿全链路

从调度器触发那一刻起，就为该任务分配唯一 trace_id，并透传至所有子任务、工具调用、数据库操作、HTTP 请求中。这样：

• 日志行自动携带 trace_id，便于按 ID 聚合全部相关日志
• 每个 Span（如 db.query、http.call）都关联该 trace_id，可在调用链图中还原完整路径
• 指标（如 task_duration_seconds）也打上 trace_id 标签，支持按任务粒度聚合分析

结合 Metrics + Logs + Tracing 交叉验证

单靠一种数据容易误判，三者联动才能准确定位问题：

• Metrics 告警延迟突增 → 查对应时间段 trace_id 最多的慢任务 → 定位到某次 DB 查询 Span 耗时占比 92%
• Logs 发现 “failed to parse JSON” 错误 → 提取 trace_id → 发现该 trace 中所有 retry 都复现相同错误，确认是输入数据格式缺陷
• Tracing 显示某任务在 “send_notification” 步骤无响应 → 查该 trace_id 的最后几条日志 → 发现下游短信网关返回 503，且无重试逻辑

支持离线回溯与横向对比

定时任务常有周期性规律，可观测性需支持历史比对：

• 保存每次执行的完整 trace 数据（含原始日志、Span、指标快照），保留至少 7 天
• 提供界面按时间范围、任务名、状态筛选，一键加载多个执行记录并叠加曲线（如耗时趋势、重试次数）
• 支持 diff 模式：对比两次执行的 Span 树差异，快速发现新增调用或跳过步骤
• 对失败任务自动标记高频共性特征（如总在凌晨 2:15 失败、总伴随 Redis 连接超时）