composer集成metrics组件不解决服务器监控指标收集问题——它仅提供指标记录接口，采集、传输、存储、展示需额外搭建；require后metrics为空是因为库不自动采集系统指标，需手动实现采集、上报、调度三层逻辑。
直接说结论：用 Composer 集成 Metrics 组件本身不解决服务器监控指标收集问题——它只是帮你把指标“记下来”，但采集、传输、存储、展示全得另外搭。
为什么 composer require 之后 metrics 还是空的？
Metrics 库（比如 prometheus/client_php 或 statsd-php/statsd-php）只提供指标注册、打点、导出接口，不自动采集 CPU、内存、磁盘这些系统指标。你 require 完，$counter = new Counter(...) 创建一个计数器，它不会自己去读 /proc/stat 或调 sys_getloadavg()。
- 它不启动后台采集进程，也不轮询系统文件
- 它不监听网络端口接收外部数据（除非你手动集成 HTTP server 或 StatsD 服务）
- 它默认不持久化——
collect()返回的只是当前内存里的快照，刷新页面就丢
真正要采集服务器指标，得自己补三块拼图
以 Linux + PHP + Prometheus 为例，缺一不可：
-
采集层：写脚本调用
sys_getloadavg()、memory_get_usage()、disk_free_space()，或解析/proc/meminfo、/proc/loadavg；也可用exec('df -B1')但注意权限和超时 -
上报层：把采集结果喂给 Metrics 实例，比如
$gauge->set($used_memory)；再暴露/metrics路由，返回文本格式（PrometheusRenderer），供 Prometheus Server 拉取 -
调度层：不能靠用户请求触发采集（不准、不稳、漏采）。得用
cron每 15 秒跑一次 CLI 脚本更新共享内存/Redis，或者用pcntl_fork启个常驻子进程（慎用，PHP 不适合长时运行）
Counter 和 Gauge 到底该用哪个？
选错类型会导致 Prometheus 查询结果反直觉：
-
Counter只增不减，适合累计值：HTTP 请求总数、队列消费条数；用它记“当前内存使用量”会不断上涨，完全错误 -
Gauge可增可减，适合瞬时值：CPU 使用率、可用磁盘空间、PHP-FPM idle 进程数；必须每次采集后调$gauge->set($value)，不是inc() - 如果指标有标签（如
http_method="POST"），务必在定义时声明['method']，否则$counter->with(['GET'])->inc()会报错或静默失败
最常被忽略的是采集频率与 Prometheus scrape_interval 的对齐——如果 PHP 脚本每 60 秒更新一次内存值，而 Prometheus 每 15 秒拉一次，你会看到连续三个相同的旧值，然后跳变。这不算 bug，是设计使然。
