利用Composer库构建可观测性的Prometheus指标采集器-composer-PHP中文网

composer install 无法直接集成 prometheus，因其不加载项目 autoloader 且为一次性进程；需通过 shell 脚本捕获 --profile 输出、解析耗时，并由长期运行的 php http 服务暴露 /metrics 端点。

利用composer库构建可观测性的prometheus指标采集器

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 服务暴露出去。这不是“集成”，而是“桥接”。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

写一个包装脚本 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 输出的稳定性。