Prometheus Metrics Bundle Laravel Package

Product Decisions This Supports

• Choosing an observability stack for the product, not just the app. Prometheus metrics turn fuzzy goals ("the app feels slow," "adoption is flat") into counters and histograms you can alert on. This package is one implementation option for that decision; the PM decision is what we measure and who owns the SLOs, not which bundle ships the /metrics endpoint.
• SLO/SLA commitments and reliability roadmap prioritization. Request latency histograms and error-rate counters let you set an error budget, then decide whether to spend a sprint on reliability work or on new features. That is a roadmap trade-off a PM owns, and it needs instrumentation. Release 1.9.0 adds status and uri labels here, which turns a single global error rate into error rate by endpoint and by status class — the difference between "we're at 99.5%" and "checkout has been at 97% for three weeks."
• Release gating and progressive rollout. Per-endpoint and per-feature counters let you compare a canary cohort against baseline before widening a rollout — a cheaper alternative to a full feature-flag analytics platform for small teams. The new uri/status labels close the biggest practical gap in the earlier version (endpoint-level comparison), but only if engineering normalizes uri to a route template rather than a raw path.
• Build vs. buy vs. vendor for instrumentation. This package is a thin wiring layer over promphp/prometheus_client_php for Symfony's DI container. The realistic PM options are: (a) adopt a maintained client library directly, (b) fork/vendor this bundle, or (c) pay for a hosted APM. A 1.9.0 release with one line of user-visible change does not change the maturity verdict (zero stars, zero dependents, single release after a multi-year gap) — the defensible decision remains not to adopt as-is; use it as a reference implementation and budget a small amount of engineering time to wire the underlying client yourself.
• Metrics cost and cardinality ownership. The new uri label is a budget-affecting decision, not just a technical one: unnormalized URLs (IDs, slugs, query strings, tenant paths) multiply time series, and metric storage/query cost scales with that. A PM should require a documented allowed label set before this ships, because removing a high-cardinality label later means breaking dashboards and SLO history.
• Usage-based pricing and capacity planning. Counters by tenant/plan tier are the raw input for metered billing tiers and infra forecasting — a product-commercial decision that metrics infrastructure enables.

When to Consider This Package

Adopt (or rather, evaluate) only if all of the following hold:

• The application is Symfony 4 or 5 — this is a Symfony bundle registering services into the container. It is not usable in Laravel; a Laravel codebase would need the underlying promphp/prometheus_client_php library plus a small service provider written in-house. (1.9.0 does not change this.)
• You are on PHP 7.x–8.0-era runtimes and have no near-term PHP upgrade roadmap, or you are prepared to fork. The 1.9.0 notes make no compatibility claim, so assume the same posture until verified on your runtime.
• You need only the basics: a scrape endpoint and counters/gauges/histograms registered through DI. 1.9.0's status/uri labels are a nice-to-have for endpoint-level SLIs but do not represent framework middleware you can point at your route table — confirm in a spike whether the labels come from a request listener (useful) or from manual call sites (you still write the wiring).
• You accept maintenance risk: one release after a multi-year gap is a data point, not a maintenance commitment. There are still no dependents to surface regressions. Budget a named owner and a fork.

Look elsewhere when:

• You are on Laravel — use a maintained Prometheus client plus your own service provider; the effort is measured in hours, not sprints, and you get the status/uri labeling for free from route middleware you control.
• You need PHP 8.2+ / Symfony 6/7 compatibility, typed collectors, Pushgateway support, or configurable route-level middleware — 1.9.0 only begins to address the last of these, and nothing in the notes suggests the others moved.
• You require security patching SLAs or vendor support — an effectively single-maintainer dependency in your request path remains a procurement and audit problem, regardless of version number.
• Your uri label would be high-cardinality by default and you have no owner willing to enforce route normalization — the new feature becomes a cost and performance liability rather than a capability.
• You are evaluating hosted APM or OpenTelemetry as the strategic direction; bolting on a single-maintainer bundle creates a migration to undo later.

How to Pitch It (Stakeholders)

Executive summary: We re-reviewed l3tum/prometheus-metrics-bundle, an MIT-licensed Symfony bundle that exposes application metrics in Prometheus format, following the 1.9.0 release. It remains a wiring convenience — a few hundred lines of container configuration on top of an existing open-source metrics client — not a platform. The release adds status and uri labels to collected metrics, which is genuinely useful: it enables per-endpoint and per-status error rates, and therefore endpoint-level SLOs and canary comparisons. It does not change the fundamentals: zero stars, zero dependents, and a single release after a multi-year gap as the only signal of maintenance activity.

Recommendation: Unchanged — do not adopt it as a dependency. Approve a small, time-boxed instrumentation task (days, not weeks) using the actively maintained Prometheus PHP client directly, and explicitly include route-template and status-code labels in that task's scope, since 1.9.0 confirms those are the labels product actually needs. This delivers the capability we want — SLOs, error budgets, canary comparison, usage metering — without an orphaned package and without blocking an OpenTelemetry migration.

For engineering: treat the bundle as a reference for collector registration and scrape exposure, and treat 1.9.0 as a spec for the label set: status is safe and bounded; uri must be normalized to a route template (no IDs, slugs, or query strings) or it will blow up cardinality. If we are pinned to Symfony 5 and need something this week, vendoring is defensible, but assign an owner.

Cost/risk framing: near-zero license cost, low integration cost, and a small but real standing risk if adopted — an effectively single-maintainer dependency in the observability path is a single point of failure precisely when we need visibility most. The new release lowers feature risk slightly and maintenance risk not at all. Build-it-ourselves remains cheap enough that buying (or adopting) is not justified.