定时任务可观测性需贯穿全生命周期，记录启动、调度、执行、结果、重试、清理等阶段的结构化事件，统一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 连接超时）
