webman本身不提供开箱即用的定时监控面板，需组合内置status命令、自定义/metrics指标暴露及prometheus+grafana实现；php start.php status仅显示当前进程连接数、内存、请求数等瞬时快照，无历史趋势、业务指标或http接口，不可直接用于可视化面板。
Webman 本身不提供开箱即用的「定时监控面板」，所谓“集成定时监控面板”实际是组合使用内置进程监控 + 自定义状态暴露 + 外部可视化工具（如 Prometheus + Grafana）实现的。直接访问一个 URL 就看到带图表的监控面板？不存在——必须自己暴露指标、配置采集、搭建展示层。
webman 的 status 命令能看什么，不能看什么
执行 php start.php status 可以立即看到各 Worker 进程的实时快照：连接数、内存占用（mem_usage）、总请求数（total_request）、失败收发次数（send_fail/recv_fail）。这些数据来自 Workerman 底层，Webman 继承并保留了该能力。
但它不记录历史趋势，不聚合统计，不支持 HTTP 接口暴露，也不包含 HTTP 请求耗时、数据库查询次数、缓存命中率等业务层指标。想靠它做“面板”，只能写脚本定期抓取输出再解析——成本高、不可靠、难扩展。
- 进程级指标够用，但仅限当前时刻；
- 无时间序列能力，无法画折线图或做同比环比；
- 输出是终端表格格式，不适合程序解析（尤其含 ANSI 颜色码时）；
- 不支持身份验证或权限控制，不能直接暴露给前端。
如何让 Webman 暴露 Prometheus 可采集的指标
核心是加一层 /metrics 路由，返回符合 Prometheus 文本格式的指标数据。需手动引入客户端库并注册指标：
- 用
composer require prometheus/client_php安装官方客户端； - 在
app/Bootstrap.php或中间件中初始化Prometheus\CollectorRegistry； - 定义关键指标，例如：
Gauge类型的webman_http_request_duration_seconds（按路由统计耗时）、Counter类型的webman_http_requests_total（按状态码计数）； - 在全局中间件（如
app/middleware/RequestLog.php）中，在请求结束前调用observe()或inc()更新指标； - 新增一个 HTTP 控制器（如
app/controller/MetricsController.php），在index方法中调用$registry->render()并返回text/plain; version=0.0.4响应头。
注意：不要在每次请求都 new 一个 CollectorRegistry，必须复用单例；否则指标会重置，Prometheus 抓到的是乱序或重复时间序列。
为什么不能只靠 monitor 进程做“定时监控”
Webman 的 app/process/Monitor.php 是个守护进程，职责非常明确：文件变更检测 + 内存超限自动重启。它的 checkMemory 方法读取 /proc/$pid/status 中的 VmRSS，触发的是 posix_kill($pid, SIGINT)，目标是保活，不是观测。
- 它默认每 60 秒检查一次内存，频率不可用于高频监控；
- 不输出任何结构化日志或 HTTP 接口，无法被外部系统采集；
- 没有暴露连接数、QPS、错误率等可观测性核心维度；
- 若你把它当成“监控服务”去依赖，会发现它既不报警，也不存历史，更不支持自定义指标。
真要“定时监控”，得另起一个独立进程（比如用 think-scheduler 或 crontab 调用 PHP 脚本），主动调用 Webman 的运行时信息（如 Worker::getAllWorkers() 获取连接数），再推送到监控后端。
Grafana 面板里最该盯住的 3 个 Webman 指标
一旦 Prometheus 开始采集，以下三个指标组合最能反映真实负载和潜在风险：
-
webman_http_requests_total{status=~"5.."} > 0：5xx 错误突增，说明业务逻辑或下游服务出问题，不是服务器挂了而是代码崩了； -
rate(webman_http_request_duration_seconds_sum[5m]) / rate(webman_http_request_duration_seconds_count[5m])：平均响应延迟，持续高于 200ms 要查慢 SQL 或阻塞 I/O； -
process_resident_memory_bytes{job="webman"} / 1024 / 1024：实际物理内存占用（MB），配合webman_worker_connections看是否连接数涨但内存不涨——可能是连接泄漏而非内存泄漏。
别迷信“CPU 使用率”，Webman 是事件驱动模型，CPU 低不代表健康；真正危险的是连接堆积、内存缓慢爬升、5xx 比例静默上升——这些信号藏在指标比率和衍生计算里，而不是单个数字上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
