Buffalo调度系统无Worker队列概念，其任务堆积体现为WAITING/READY实例长期未执行；需监控task_instance_status_count、upstream_dependency_delay_ms、executor_node_load等指标，并通过直查MySQL元数据表识别真实阻塞原因。

Buffalo调度系统里没有Worker队列这个概念

京东的Buffalo调度系统是基于DAG的任务编排引擎，不是消息队列或工作线程池框架。它不维护“Worker队列”，也没有运行时的worker_queue_size、pending_tasks这类指标。你看到的“Worker”可能是对执行节点（Executor Node）的误称，或是混淆了RabbitMQ、Celery等中间件的术语。

真正要监控的是Task实例的等待与积压状态

Buffalo中任务堆积反映在实例生命周期上：当大量WAITING或READY状态的实例长时间未进入RUNNING，说明资源或依赖阻塞。关键监控点包括：

• task_instance_status_count 按状态分组的实例数（尤其关注WAITING持续超10分钟的实例）
• upstream_dependency_delay_ms 上游任务延迟触发的平均毫秒数（跨天依赖易在此暴露）
• executor_node_load 执行节点当前并发实例数（需对比其max_concurrent_tasks配置）
• 依赖链深度超过15层的DAG，instance_scheduling_latency会显著升高

直接查数据库比调API更可靠

Buffalo未开放实时队列水位API，但其元数据表结构稳定。生产环境建议直连MySQL查：

SELECT status, COUNT(*) c 
FROM task_instance 
WHERE gmt_created > DATE_SUB(NOW(), INTERVAL 1 HOUR) 
GROUP BY status;

重点关注WAITING和READY的突增；若WAITING占比连续5分钟超70%，大概率是上游任务失败未重试，或跨天依赖时间未校准（如dt=20260920被写成dt=20260919）。

别忽略“伪堆积”：依赖未就绪 vs 真实资源不足

同一堆READY实例，原因可能截然不同：

• 若对应task_definition.dependency_type = 'DATA'，检查data_dependency_check_log表里是否有MISSING记录
• 若executor_node.status = 'OFFLINE'或心跳超时，READY实例会卡住不动
• 某些控制节点（如IF、SWITCH）未设置默认分支，会导致下游所有实例挂起

真实资源瓶颈反而少见——Buffalo的Executor Node默认支持动态扩缩容，积压通常源于逻辑阻塞，而非CPU或内存耗尽。