frankenphp_busy_threads长期接近frankenphp_total_threads说明线程池饱和，Symfony Worker常驻占用线程导致HTTP请求排队或超时，应优先检查活跃Worker数量与线程配置。
frankenphp_busy_threads 长期接近 frankenphp_total_threads，说明线程池已饱和，Symfony 请求开始排队或超时——这是最该优先看的信号。
盯住线程池是否被 Symfony Worker 吃光
Symfony 应用在 FrankenPHP 下常启用 symfony:worker 命令（如 Messenger 或 Scheduler），这些 Worker 脚本会常驻 PHP 线程，且永不释放。每个 Worker 实例永久占用 1 个线程。
这意味着：frankenphp_busy_threads 的值 ≈ 运行中 Worker 数 + 正在处理 HTTP 请求的线程数。一旦它持续等于 frankenphp_total_threads，普通 Web 请求就会卡在 frankenphp_queue_depth 里，延迟飙升。
- 检查当前活跃 Worker：用
curl http://localhost:2019/metrics | grep 'frankenphp_worker_status{worker=".*symfony.*"}'看哪些 worker 标签匹配symfony - 确认线程总数：查
frankenphp_total_threads，默认是 CPU 核心数 × 2（Caddy 启动时自动推导） - 避免“Worker 洪水”：不要为每个 Messenger transport 都开一个独立
symfony:messenger:consume进程；改用单进程多 worker（--limit=50）并复用线程
frankenphp_worker_requests_total 和 frankenphp_worker_duration_seconds 要按 worker 名拆开看
Symfony 不同 Worker 承载不同负载：Messenger 消费、Scheduler 触发、自定义长任务等。它们的请求频次和耗时差异极大，混在一起看平均值毫无意义。
立即学习“PHP免费学习笔记（深入）”；
比如 frankenphp_worker_requests_total{worker="messenger_consume_default"} 突增但 frankenphp_worker_duration_seconds_sum{worker="messenger_consume_default"} 同步暴涨，大概率是某条消息触发了 N+1 查询或未设 timeout 的外部调用。
- 必须带
{worker=~".*symfony.*"}标签过滤，否则会被其他 PHP 脚本（如健康检查脚本）稀释 - 重点关注
_sum / _count计算出的平均耗时，Prometheus 中写成：rate(frankenphp_worker_duration_seconds_sum{worker=~".*symfony.*"}[5m]) / rate(frankenphp_worker_requests_total{worker=~".*symfony.*"}[5m]) - 若某 worker 的
frankenphp_worker_crashes_total非零，说明它反复 panic（如内存超限、未捕获异常），需查其 stdout 日志（FrankenPHP 默认不重定向，得在 Caddyfile 中配log）
frankenphp_queue_depth 异常上升？先确认是不是 Symfony CLI 请求混进来了
开发阶段习惯用 symfony console 或 bin/console 触发命令，但如果这些命令被误配进 Caddy 的路由（例如 /console 路由指向了 PHP 处理器），每次调用都会生成一个普通请求，进入线程池队列——而 CLI 命令本身又不走 HTTP 生命周期，极易卡死线程。
- 检查 Caddyfile 中
php指令是否无差别覆盖了所有路径；应显式排除管理路径：route /console* { respond "Forbidden" 403 } -
frankenphp_queue_depth在纯 Worker 场景下应长期为 0；只要它 > 0 且稳定不降，基本可断定有非预期的 HTTP 请求在争抢线程 - 临时验证：停掉所有 Symfony Worker，观察
frankenphp_queue_depth是否归零；若仍不降，说明问题出在 Web 请求侧（如慢 SQL、阻塞 I/O）
Caddy metrics 端点本身不可靠？检查 admin 配置是否被覆盖
FrankenPHP 指标完全依赖 Caddy 的 metrics 指令注册到 admin 端点。但 Caddyfile 中多个 {} 块可能造成配置覆盖——尤其当你把 admin 单独写在另一个配置块里时，FrankenPHP 的指标注册逻辑可能失效。
- 确保
metrics和admin在同一个全局配置块中，例如：{ admin :2019 metrics }，不能拆成两个{} - 验证指标是否注册成功：
curl http://localhost:2019/metrics | grep frankenphp—— 若无输出，说明指标根本没加载，不是监控没配好，而是 FrankenPHP 没拿到 registry - 注意：Docker 部署时，
localhost:2019是容器内地址；从宿主机 curl 需换成http://127.0.0.1:2019/metrics（前提是ports映射了2019:2019）
实际跑 Symfony 时，最容易被忽略的是 Worker 对线程的“永久占位”特性——它不像 FPM 那样按需启停，也不像 Swoole 那样能优雅 reload。线程数不是性能余量，而是硬性上限。盯指标不是为了画图好看，是防止某天凌晨三点因为一个没设 timeout 的 Messenger job，把整个 API 队列拖垮。
