frankenphp 崩溃恢复需 docker 自动重启、caddy 健康检查与 prometheus 告警协同：启用 caddy metrics 采集 frankenphp_worker_crashes_total 等指标，配置 docker healthcheck 探测 /health 端点，并在 prometheus 中设置崩溃突增和线程失活告警。
FrankenPHP 进程崩溃后自动重启，不能只靠“重启”本身，关键是要及时发现崩溃 + 触发恢复 + 防止反复失败。它本身不提供进程守护能力，需结合 Docker、Caddy 管理机制和 Prometheus 监控告警三者协同。
启用 FrankenPHP 内置指标采集
FrankenPHP 的崩溃相关指标（如 frankenphp_worker_crashes_total、frankenphp_worker_restarts_total）只有在 Caddy 开启 metrics 时才生效。
确保 Caddyfile 包含全局 metrics 指令：
{
admin localhost:2019
metrics
}
localhost {
route {
php {
root /var/www/html
}
}
}
启动后，访问 http://localhost:2019/metrics 可看到类似指标：
-
frankenphp_worker_crashes_total{script="/path/to/worker.php"}—— 每个 Worker 脚本的累计崩溃次数 -
frankenphp_worker_restarts_total{script="/path/to/worker.php"}—— 主动重启次数（比如配置了max_requests触发的优雅重启） -
frankenphp_busy_threads突降至 0 且长时间无恢复，也可能是整体线程池卡死或崩溃
这些指标是判断“是否真崩溃”而非“假活”的核心依据。
配置 Docker 自动重启与健康检查
FrankenPHP 通常以容器方式部署，Docker 层面的防护是第一道防线：
- 使用
restart: unless-stopped确保进程退出后自动拉起 - 添加
healthcheck主动探测服务可用性，避免容器“活着但 PHP 不响应”：
php-app:
image: dunglas/frankenphp
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 40s
其中 /health 是你应用中返回 200 OK 的轻量端点（例如简单输出 {"status":"ok"}），比仅检查进程更可靠。
基于 Prometheus 设置崩溃告警规则
在 Prometheus 中添加如下告警规则（针对 Worker 崩溃突增）：
- alert: FrankenPHPWorkerCrashSpikes
expr: |
increase(frankenphp_worker_crashes_total[15m]) > 3
for: 2m
labels:
severity: critical
annotations:
summary: "FrankenPHP Worker {{ $labels.script }} crashed repeatedly"
description: "Crash count increased by {{ $value }} in last 15 minutes"
同时可加一条辅助规则监测线程池失活：
- alert: FrankenPHPNoActiveThreads
expr: frankenphp_busy_threads == 0 and frankenphp_total_threads > 0
for: 60s
labels:
severity: warning
annotations:
summary: "FrankenPHP has zero busy threads but threads exist"
触发告警后，可通过 Alertmanager 推送至企业微信、钉钉或邮件，并联动脚本执行 docker restart 或通知运维介入。
补充：日志与崩溃现场捕获
FrankenPHP 默认将错误输出到 stderr，务必在容器中保留并集中收集：
- 启动时加上
--log-level debug查看 PHP 初始化失败细节 - 在 Caddyfile 中配置
log指令，记录请求级异常：
log {
output file /var/log/frankenphp/access.log
format json
}
当 worker_crashes_total 上升时，立即查对应时间点的 error log，常见原因包括：
- PHP 扩展兼容性问题（如未适配 PHP 8.3 的 xdebug）
- Worker 脚本中未捕获的致命错误（
Fatal error: Allowed memory size exhausted） -
opcache配置不当导致 JIT 编译崩溃
监控不是终点，而是定位根因的起点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
