Celery任务健康需关注task_duration_seconds分布、task_failures_total按任务名聚合、worker收发任务差值及Redis Streams/List结构指标，而非仅依赖redis-cli ping。
看 Celery 任务延迟和失败率，别只盯 Redis 连通性
Redis 连通只是基础，真正决定异步任务是否健康的是 Celery 层面的执行表现。很多团队用 redis-cli ping 返回 PONG 就以为万事大吉，结果工作流 P95 延迟飙到 12s 还找不到原因。
-
task_duration_seconds直方图必须采集——比如dify_task_duration_seconds{task_name="run_workflow"}超过 3s 的比例持续 >5%，说明节点或下游 API 已拖垮链路 -
dify_task_failures_total按task_name维度聚合，若llm_invoke失败陡增但knowledge_retrieval正常，问题大概率在模型网关而非队列本身 - 别忽略
celery_worker_tasks_received_total和celery_worker_tasks_succeeded_total的差值：积压任务数持续增长，往往意味着 worker 并发不足或单任务卡死（比如没设timeout的 HTTP 调用）
检查 Redis INFO 中的 key-level 指标，不是只看内存用量
光看 used_memory 或 mem_fragmentation_ratio 容易误判。Dify 异步任务重度依赖 Streams（如 task-stream）或 List（Celery 默认 backend），得盯住实际承载任务数据的结构指标。
- 对 Streams 场景，执行
redis-cli XINFO GROUPS task-stream，确认pending数不持续上涨；若idle时间超 30s，说明消费者（worker）已假死或阻塞 - 对 List 队列（
celery默认用celerykey），用redis-cli LLEN celery查长度，但更要结合redis-cli INFO commandstats看cmdstat_lpush和cmdstat_rpop的调用量比——若前者远高于后者，就是消费端掉队了 -
instantaneous_ops_per_sec长期低于 100 且rejected_connections上升，大概率是连接池耗尽，不是 Redis 本身慢
用 BLOCK + COUNT 模拟真实消费行为，别信空跑 benchmark
很多团队用 amqp-declare-queue 测 RabbitMQ，却忘了 Dify v1.4+ 默认走 Redis Streams，而 Streams 的消费延迟受 BLOCK 参数和消费者组状态强影响。
- 手动模拟 worker 行为：
redis-cli XREADGROUP GROUP email-workers worker-1 COUNT 1 BLOCK 5000 STREAMS task-stream >，如果响应时间波动剧烈（比如忽快忽慢），说明存在竞争或网络抖动 - 对比
BLOCK 0和BLOCK 5000的平均延迟：前者接近 0ms 但空轮询压 CPU，后者稳定但可能掩盖短时积压；生产环境建议固定BLOCK 1000并监控idle字段 - 注意
XINFO CONSUMERS task-stream email-workers中每个 consumer 的pending数——若某个 worker 占了 90% pending，说明负载不均，需检查其进程是否被 GC 或 I/O 卡住
查日志要带上下文，重点抓 “task-received” 到 “task-started” 的 gap
Celery 日志里最骗人的就是 “Task received”，它只代表消息从 Redis 取出，不代表开始执行。这个 gap 才是定位线程池瓶颈的关键窗口。
- 启用
--loglevel=DEBUG后，在日志中搜Task .* received和紧随其后的Task .* started，计算两者时间差；若普遍 >500ms，基本坐实ThreadPoolExecutor配置问题（如max_workers=1） - 配合
ps aux | grep celery看实际 worker 进程数，再对比配置中的worker_concurrency——若进程数远少于预期，可能是启动脚本漏传参数或 OOM 被系统 kill - 别跳过
task_postrun回调里的sender.runtime：它反映纯执行耗时，和前面的 gap 相减，就能拆出“排队等待” vs “真正在跑”的时间占比
真实压测中发现，87% 的“Redis 健康但任务卡顿”案例，问题都不在 Redis 本身，而在 Celery worker 的线程调度策略与 Dify 节点的 async/await 生命周期错位。查指标时，先看 task_duration 分布，再翻 INFO commandstats，最后才碰 redis-cli ping。
