flower 默认仅显示活跃任务和队列积压，需显式配置--broker、--port及--events等参数才能稳定获取失败详情、重试次数与执行时长分布；其不自动读取celeryconfig.py，也不启用认证或持久化，须手动设置--basic_auth、--persistent=true等生产级选项。
Flower 能实时监控 Celery，但默认不启用认证、不暴露在公网、不自动持久化任务历史——直接 flower --broker=redis://localhost:6379 启动后，浏览器打开 http://localhost:5555 看到的只是“当前活跃任务”和“队列积压”，很多关键状态（比如失败任务详情、重试次数、执行时长分布）需要额外配置才能稳定获取。
启动 Flower 时必须显式指定 broker 和端口
Flower 本身不读取 Celery 的 celeryconfig.py 或 CELERY_BROKER_URL 环境变量，必须通过命令行传入 --broker。常见错误是只写 flower，结果报错 No module named 'kombu' 或连接拒绝。
-
flower --broker=redis://localhost:6379/0 --port=5555是最简可用组合 - 若用 RabbitMQ，格式为
amqp://guest:guest@localhost:5672//，密码和 vhost 不能省略 -
--address=0.0.0.0允许外部访问，但必须配合--basic_auth=user:pass，否则裸奔风险极高 - 不加
--port默认是 5555，但若被占用会静默失败，建议始终显式指定
查看失败任务需开启 events 并保持长期运行
Celery 默认不发送 task-failed、task-revoked 等事件，Flower 就只能显示“无数据”。必须让 worker 主动发事件，且 Flower 进程要持续接收并缓存——不是“点开网页才拉一次”。
- 启动 worker 时加
--events参数：celery -A proj worker --loglevel=info --events - Flower 启动后会自动订阅 events，但若 worker 重启或网络中断，events 流会断，需手动刷新或重启 Flower
- 失败任务详情（如 traceback）只保留在内存中，默认最多存 1000 条，可通过
--max-tasks=10000提高上限 - events 占用 Redis 内存，生产环境建议搭配
--persistent=True+ SQLite 文件落地（但会降低实时性）
在 Flask/Django 项目中嵌入 Flower 需绕过路由冲突
Flower 是独立 Tornado 应用，不能直接作为 Flask Blueprint 注册；强行用 app.register_blueprint() 会 404。正确做法是反向代理或子路径挂载。
- Nginx 配置示例：
location /flower/ { proxy_pass http://127.0.0.1:5555/; }，注意末尾斜杠不能少 - Django 中可改用
flower --url_prefix=flower，再配 Nginx 的location /flower/，避免前端路由混乱 - 若必须同端口共存，Flower 不支持 WSGI，只能用
gevent或eventlet启动，但稳定性不如独立进程 - 嵌入后所有静态资源路径（CSS/JS）会带
/flower/前缀，Flower 自动处理，无需修改源码
Flower 的 UI 看似直观，但任务状态依赖 events 流的完整性，而 events 又依赖 worker 的稳定上报和网络低延迟。一旦出现“任务列表为空”或“图表不更新”，优先查 worker 是否带 --events、Redis 是否丢包、Flower 进程是否 OOM 被 kill——而不是调 UI 设置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
