监控、积压与故障排查
后台任务是否健康，取决于业务动作有没有在允许的时间内完成。Worker 存活、CPU 正常，并不能证明调度仍在推进。
从业务期限看指标
| 指标 | 口径 | 能发现什么 |
|---|---|---|
| 到期待领取数 | 已到可执行时间但尚未领取的任务数 | 调度停滞、Worker 不足 |
| 首次调度延迟 | 首次开始时间减原计划时间 | 扫描和首次排队造成的等待 |
| 单次领取延迟 | 本次开始时间减本次可执行时间 | 当前调度或重试队列的等待 |
| 执行耗时 | 单次尝试结束时间减开始时间 | 处理器或依赖变慢 |
| 端到端延迟 | 业务完成时间减原计划时间 | 重试与排队叠加后的时效 |
| 尝试结果数 | 按成功、重试、跳过、死信分别统计 | 失败与无效任务的变化 |
| 租约回收数 | 过期租约被回收的次数 | 进程退出、长暂停、续租失败 |
| 最老到期任务年龄 | 当前时间减最老未完成到期任务的原计划时间 | 少量任务长期无人处理 |
不要把尚未到期的未来任务算进到期积压。也不要只统计已完成任务的延迟：完全卡住的任务不会进入完成样本，必须同时观察未完成任务年龄。
周期批处理还要记录最后一次成功的时间和处理的数据窗口。Prometheus 的埋点指南将最后成功时间作为批任务的关键指标；具体告警阈值仍由业务周期和允许延迟决定。
一条任务需要哪些上下文
日志与追踪至少能够关联 task_id、任务类型、业务键、尝试次数、领取 token、原计划时间和结果类别。跨消息边界还应保留事件 ID 或关联 ID。
业务键和任务 ID 适合进入受控日志或追踪字段，不适合直接作为指标标签。高基数字段会不断产生新的时间序列；指标标签优先选数量有界的任务类型、状态和错误类别。参见 Prometheus 标签使用建议。
错误信息要脱敏。任务参数可能包含联系方式、访问地址或文件凭据，排查时只记录必要标识，避免把完整 payload 写进每次重试日志。
积压如何增长
如果平均每秒新增任务为 λ，每秒有效完成任务为 μ，在持续负载下：
λ > μ：积压持续增长
μ > λ：才有容量消化历史积压
恢复时间 ≈ 当前积压数 / (μ - λ)例如积压 60,000 条，每秒新增 80 条、有效完成 100 条，在速率稳定且任务耗时相近的假设下，消化积压约需 3,000 秒，即 50 分钟。这里统计业务有效完成量，不能把重试调用也算成完成量。
任务成本不同、优先级不同或下游容量变化时，上式只能提供粗略估计。还要分任务类型观察，避免低成本任务的大吞吐掩盖高价值任务停滞。
排查顺序
| 现象 | 优先检查 | 进一步动作 |
|---|---|---|
| 没有新执行实例 | 计划启用状态、时区、调度器推进记录 | 核对错过的窗口与补跑规则 |
| 数据库有到期任务但无领取 | 查询条件、索引、连接池和领取错误 | 检查状态、尝试上限与数据库时间 |
| 已入队但一直未开始 | 消费者、订阅路由、未确认数量 | 检查消费阻塞与预取设置 |
running 长期不结束 | 外部调用、执行超时、续租和回收器 | 核对是否失联或仍有不可取消操作 |
| 重试数突然上升 | 错误类别、下游限流、重试层数 | 降低重试与消费并发，查明根因 |
| 少数任务特别老 | 固定失败参数、热点业务键、领取饥饿 | 隔离坏任务并保留处置记录 |
| 任务成功但业务结果缺失 | 成功的定义、外部响应与本地事务 | 对账，检查是否过早确认 |
恢复积压时保护下游
增加 Worker 前先看瓶颈。如果数据库连接池、供应商限额或外部接口已经饱和，继续扩容可能降低有效完成量。
恢复策略可以按业务截止时间筛掉无效任务，按任务类型限制并发，并为新任务与历史补偿保留各自的容量。死信重放需要预览影响范围、限速，并保留稳定幂等键。
事件实时触发与兜底扫描可以走同一处理器，但要防止两路同时大量补建任务。唯一业务键能控制重复记录，扫描节流仍然需要单独配置。
告警围绕可操作的结果
“订单关闭检查超过允许延迟”“日报错过约定交付时间”“Outbox 最老待发事件持续变老”都能指向具体处理流程。CPU 和内存告警用于定位资源压力，不能替代业务时效告警。
告警还应附带对应任务类型、影响范围、最老任务时间和排查入口。正常业务跳过与异常失败分别统计，避免正常改期或已支付订单持续触发错误告警。
阿里云客户案例：从执行记录定位耗时与失败
阿里云开发者社区的定时任务链路追踪文章列举了三个独立的匿名客户案例：
- 电商任务执行变慢：从超时执行记录进入调用链，定位耗时占比较高的下游服务。
- 金融账户批量迁移失败：定位失败账户对应的子任务，再查看调用链与具体异常。
- 游戏业务 HTTP 任务：关联调度触发的请求与跨服务调用，区分定时任务流量和普通请求。
文章未披露客户身份或完整数据，不能将这三个案例合并为同一家客户的架构，也不能用于估计自身吞吐容量。
可据此将本文排查路径固定为运行实例、业务分片、尝试、下游请求与结果记录。1000 名会员的一个提醒失败时，能找到该会员阶段对应的尝试；报表一个租户特别慢时，能区分数据库查询、外部调用和等待额度。仅保留每轮“成功或失败”会丢失这些定位信息。
任务重试应产生新的尝试身份，并保留与原运行的关联，避免一次很长的 Trace 混合多次重试。任务参数和联系方式继续按最小范围记录，不能为了可观测性将完整通知内容或外部凭据写入日志。
参考资料
- 阿里云开发者社区：如何通过链路追踪进行定时任务诊
- Prometheus：Instrumentation：离线处理、批任务与标签