Composer install 无法直接集成 Prometheus，因其不加载项目 autoloader 且为一次性进程；需通过 shell 脚本捕获 --profile 输出、解析耗时，并由长期运行的 PHP HTTP 服务暴露 /metrics 端点。
Composer 本身不产生可观测性指标，composer install 是一次性 CLI 进程，无法被 Prometheus 直接抓取。想用 Composer 生态做指标采集，必须绕过“自动集成”幻觉，靠外部脚本捕获输出、解析耗时、暴露 HTTP 接口。
为什么 composer require prometheus/client_php 对 composer install 完全无效
因为 Composer 在执行自身命令（如 install、update）时，根本不加载 vendor/autoload.php，更不会执行你项目里写的任何 PHP 类或初始化逻辑。你在 post-install-cmd 里 new 一个 Counter，进程一退出，指标就丢了；想在安装过程中调 $counter->inc()，连类名都找不到——autoload 尚未触发。
-
composer install启动的是独立的 Symfony Console 应用，它有自己的 autoloader，和你的项目无关 - 第三方插件（如
hirak/prestissimo）可能干扰--profile输出结构，导致解析失败 - 即使把
--profile输出重定向到文件，Prometheus 也不会读日志——它只认标准/metrics文本格式端点
真正能落地的采集方式：shell 包装 + PHP HTTP server
核心是把 composer install --profile -v 的 stdout 解析成数值，再由一个长期运行的 PHP HTTP 服务暴露出去。这不是“集成”，而是“桥接”。
- 写一个包装脚本
bin/composer-monitor，用time composer install --profile -v --no-plugins 2>&1捕获完整输出 - 从输出中提取
Time:行和各阶段耗时（如Resolving dependencies），转成 JSON 写入tmp/composer-last-run.json - 用
php -S localhost:8081 -t public/启一个最小 HTTP server，在public/index.php中读该 JSON，用Prometheus\CollectorRegistry注册Gauge并set()耗时值 -
/metrics路由必须只读 JSON、不做任何业务逻辑，否则并发抓取会出错
prometheus.yml 配置要点与易错项
Prometheus 抓取这个自建 exporter 时，配置稍有偏差就会 404 或空指标。关键不是“加 job”，而是“对得上”。
-
scrape_interval必须设为 ≥60s——composer install不是高频事件，频繁拉取只会重复旧数据 -
targets填localhost:8081时，要确认容器网络模型：Docker Compose 下应填服务名（如composer-exporter:8081） - 务必加
relabel_configs清洗标签，例如把job="composer"改成job="php-composer-install"，避免和其它 job 冲突 - 别在
static_configs里写http://localhost:8081/metrics——容器内localhost指向自己，不是宿主机
最常被忽略的是环境一致性：composer install 必须在干净、无缓存、固定 PHP 版本的环境中运行，否则耗时波动大，指标失去对比意义。CI 环境里还要注意 COMPOSER_CACHE_DIR 是否清空、是否启用 --no-interaction，这些都会影响 --profile 输出的稳定性。
