Symfony Prometheus Exporter Laravel Package

Technical Evaluation

Package identity — the first finding. tasko-products/symfony-prometheus-exporter is a Symfony bundle, not a Laravel package. It hooks into Symfony's kernel and DI compilation pipeline (Bundle class, extension, compiler passes). Laravel's service container has no equivalent lifecycle, so it will not install-and-go in a Laravel app. The "architecture fit" against our stated stack is therefore near zero as-is; the realistic value is as a reference implementation for a Prometheus exporter (metric registration, storage-adapter wiring, /metrics exposition formatting), not as a dependency.

What the release actually says. 3.0.0 is a major version bump described as "housekeeping" and "nothing special." That combination is the risk signal. A major bump driven by "updated all the project dependencies" almost always carries a raised minimum PHP constraint, a raised Symfony major, and often renamed service IDs, config keys, or constructor signatures from the "legacy code style" pass. PR #16 is the entire changelog — there is no breaking-change section, no migration guide, and no deprecation list. The scope of breakage is unquantified, not zero.

Integration feasibility. Low directly; moderate as a pattern donor. If a Symfony service already exists in our estate (sidecar, internal admin app), this is a clean drop-in there and worth tracking separately.

Technical risk. Concentrated in three places: (1) undocumented breaking changes from a dependency sweep; (2) code-style refactors that can alter class names and DI aliases, silently breaking container bindings at runtime rather than at compile time; (3) low bus factor — small maintainer footprint, thin release notes, so we absorb the diff-reading cost.

Key questions to send back to the maintainer/authors before any adoption decision:

• What is the new minimum PHP and Symfony version? What was it in 2.2.0?
• Were any public service IDs, config keys, or class names renamed in PR #16?
• Is the metrics endpoint path and storage-adapter configuration unchanged?
• Is there a supported Laravel integration path, or is the intent Symfony-only?
• What is the maintenance commitment — release cadence, security response, and is there more than one active maintainer?

Integration Approach

Stack fit. Three viable options, in order of preference for a Laravel codebase:

1. Adopt a Laravel-native exporter (spatie/laravel-prometheus, renoki-co/laravel-prometheus, or promphp/prometheus_client_php wired through a service provider). Lowest ramp-up, correct container lifecycle, no Symfony bridge.
2. Port the exporter pattern from this repo — reuse its metric-collection and exposition-formatting approach inside our own service provider. Zero third-party runtime dependency.
3. Bridge this bundle into Laravel. Technically possible but requires fabricating Symfony container semantics; not worth it.

Option 1 or 2 is the recommendation. This package is not a candidate for composer require in a Laravel app.

Migration path (if 2.2.0 is already in use anywhere). Do not upgrade on release announcement alone. Pin 3.0.0 in a throwaway branch, run composer update --dry-run to capture the transitive diff, execute the full test suite, diff the compiled DI container, and capture the /metrics exposition output before and after and compare byte-for-byte — metric names, label ordering, and HELP/TYPE lines are a de facto contract with Prometheus and with any dashboards or alerts built on it.

Compatibility checks. PHP constraint, Symfony constraint, psr/* and promphp/prometheus_client_php versions, and conflicts against our existing Guzzle/Redis clients in the composer graph. A dependency sweep in the package is exactly where a version conflict with our app surfaces.

Sequencing. Spike in an isolated branch → contract-test the metrics output → decide build-vs-adopt → only then open the dependency PR with the captured before/after evidence. The release existing is not a reason to move; a documented requirement is.

Operational Impact

Maintenance. Single-maintainer, low-activity repository with a one-line changelog on a major release. That is a signal about release discipline, not a disqualifier — but it means we budget engineering time to read diffs ourselves rather than relying on release notes. Treat the package as "vendored pattern" rather than "supported dependency."

Support. No upgrade guide for the major bump. Support path is reading the GitHub diff for PR #16 and the composer constraint changes. If we adopt the Laravel-native alternative, support is community-driven but the surface area is smaller and we control the service provider.

Scaling. The exporter pattern is pull-based and scales with scrape frequency × label cardinality, both of which are our configuration decisions, not the package's. The package's scaling limits are not the constraint; our metric design is. Watch for labels derived from user IDs, request paths, or raw URLs — those blow up cardinality and Prometheus memory faster than any package choice matters.

Failure modes to design against:

• Synchronous /metrics rendering — exposition runs inside a PHP-FPM worker. Under scrape load or a slow storage backend, it consumes workers and can starve real traffic. Serve it from a separate pool or cache the rendered output.
• Silent metric loss — a failed render returns an error page or partial output; Prometheus records the gap and alerting misfires. Instrument the endpoint itself.
• Runtime binding breakage — style refactors renaming DI aliases fail at boot, not at build. Contract tests catch this; static analysis will not.
• Version drift after a "housekeeping" major — an unpinned ^3.0 can pull a transitive update that changes behavior with no changelog entry at all.

Ramp-up. Low for the Laravel-native path (a day for a competent Laravel engineer to wire a service provider and expose /metrics). Medium-to-high for the bridge path — the team would need Symfony DI and bundle-lifecycle familiarity to debug container wiring, which is knowledge we would be acquiring solely to support a package that was not built for our framework. That asymmetry is the deciding factor.