webman无内置web监控面板，其monitor进程仅日志输出和基础指标检查，不提供http接口或ui；真需可视化监控须自建prometheus+grafana或启用workerman原生状态页（仅限开发）。
Webman 没有内置的 Web 界面监控面板，所谓“性能监控面板”是常见误解；它只提供进程级基础指标（如内存、文件变更）和日志能力，不带可视化 UI。真要看到类似 http://localhost:5555 那样的状态页，你得自己搭或换方案。
Webman 自带的 monitor 进程只输出日志，不提供 Web 面板
Webman 的 app/process/Monitor.php 是一个后台常驻进程，它做的事很明确：定时检查文件修改时间、读取 /proc/[pid]/status 中的 VmRSS 值，并在超限时发 SIGINT 重启工作进程。它不会启动 HTTP 服务，也不会暴露任何接口。
- 它的输出全部写入
runtime/log/monitor.log（默认路径），没有 HTML 页面、没有 JSON API - 配置项
enable_file_monitor和enable_memory_monitor控制的是这两项检查是否开启，不是“开启面板” - 如果你在浏览器访问
:5555看到了页面，那其实是底层 Workerman 的WebServer或你额外启的其他服务，和 Webman 的 monitor 无关
想看实时状态？得靠 Workerman 原生状态页或外接 Prometheus
Workerman 本身支持一个极简状态页，但需手动启用且仅限开发环境使用——它不安全、无认证、不建议上线。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 在
start.php中调用Worker::$statistics = true;启用统计 - 添加一个
WebServer实例，监听端口（比如 5555），路由返回Worker::getStatistics()的结果 - 该页面只显示连接数、请求量、发送/接收字节数等基础维度，不含 SQL 耗时、中间件耗时、Trace 链路等应用层指标
- 生产环境必须禁用，否则会暴露进程 PID、内存地址等敏感信息
Log::enable() + Trace::enable() 不等于监控面板，只是埋点基础
很多教程说调用 Log::enable() 和 Trace::enable() 就算“接入监控”，这容易误导。它们只是打开了日志记录和请求耗时打点开关，后续仍需你自行消费这些数据。
-
Trace::enable()会在每个请求结束时写一条结构化日志到runtime/log/trace.log，含 URL、耗时、内存增量、SQL 查询数等字段 - 但 Webman 不提供解析器、不提供聚合视图、不提供搜索界面——你得用
grep、awk或 ELK、Grafana Loki 才能查 - 若想按路由分组看 P95 耗时，或对比不同版本的错误率，必须自己写脚本清洗日志或对接指标系统
真正可用的监控组合：Prometheus + 自定义 Exporter 是目前最稳路径
Webman 没官方 exporter，但你可以用几行代码把关键指标暴露给 Prometheus，再配 Grafana 看板。这是当前生产环境最可行的方案。
- 创建一个
app/process/PrometheusExporter.php，用workerman/webman的HttpServer启一个 /metrics 接口 - 从
Worker::getStatistics()、memory_get_usage()、自定义计数器中采集数据，用promphp/client_php格式输出 - 在
config/process.php中注册该进程，确保它随主服务一起启动 - 注意避免在高并发下频繁调用
/proc或反射获取类名，否则 exporter 本身成瓶颈
最容易被忽略的一点：Webman 的 trace 日志默认按天轮转，但没自动压缩。如果开了 trace 又没配 logrotate，几天后 trace.log 就会涨到 GB 级，反而拖慢磁盘 IO 和日志写入——监控本身成了性能杀手。
