Metrics Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for instrumentation. Whether to add a third-party package, adopt a hosted APM/observability vendor, or own ~150 lines of counter/gauge/timer code behind an internal interface. This package is a useful data point for how small the "build" side actually is.
• Standardizing on a metrics facade. Deciding to expose one Metrics::increment()/timing()/gauge() interface to product teams so the backend (StatsD, Prometheus, OTel, vendor) can be swapped without touching call sites. The bundle's abstraction shape is the transferable idea; the code is not.
• SLI/SLO definition for PHP services. Choosing which server-side signals (request latency, error counts, queue depth, business events) become the basis for error budgets and alerting thresholds.
• Roadmap prioritization with server-truth data. Instrumenting feature adoption and conversion inside the app tier rather than relying solely on client-side analytics, which under-counts API and background traffic.
• Rollout and deprecation monitoring. Deciding when a legacy code path can be deleted by measuring old-vs-new usage before and after a migration.
• Tech-debt triage on legacy Symfony services. Whether to leave an existing instrumentation dependency in place, pin it, or budget a replacement as part of a platform upgrade.
• Capacity and cost planning. Committing to per-request counters and latency histograms as inputs to infrastructure sizing decisions.

Net: this package informs the decision framework and the interface design. It does not inform a purchase order.

When to Consider This Package

Consider it only when all of the following hold:

• You maintain a frozen, legacy Symfony 2.x/3.x application that already depends on it — in which case the decision is "pin and isolate," not "adopt."
• You want a reading reference for a small, opinionated in-app metrics abstraction (named counters, gauges, timers, backend adapters) and will reimplement rather than install.
• Your dependency policy permits a package with no upstream maintainer, and you accept owning any future patch yourself.
• The capability is genuinely narrow — basic aggregation and export — with no need for labels, context propagation, or cardinality controls.

Look elsewhere when any of these are true:

• You're on Laravel. This is a Symfony Bundle: it ships a DI extension, service definitions, and kernel-level wiring. Laravel has no bundle/config-loading equivalent, so "installing" it means porting it. There is no realistic path to value from composer require.
• You're on a supported PHP or framework version. The last release is January 2017 — predating PHP 7.2, Symfony 4, and the Laravel 5.5+ era. Expect incompatibility with anything current and no security-patch path for transitive dependencies.
• You need community or vendor support. 10 stars and 0 dependents means effectively no user base and no escalation route. The low opportunity score reflects that: there is nothing to build a bet on.
• You need modern observability semantics — OpenTelemetry conventions, Prometheus exporters, label dimensionality, trace correlation. This predates all of it.
• Safer substitutes exist and are maintained: OpenTelemetry PHP SDK, Prometheus PHP client, StatsD clients, Laravel Pulse/Telescope, Symfony's current tooling, or an in-house service behind an interface you control.

Decision rule: adopt only where removal costs more than keeping it. Never for greenfield work.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a 2017 Symfony bundle for collecting application metrics. It is not a candidate for adoption. With 10 stars, zero dependent packages, and no release in eight years, the maintenance and security risk exceeds the cost of the equivalent capability, which is small — roughly one to two engineering days behind a stable interface. The recommendation is a no-go on adding it as a dependency. We should instead standardize instrumentation on a maintained option (OpenTelemetry, or our existing observability vendor) that gives us vendor portability and a patch path.

For engineering — the substance: The package is a Symfony Bundle — DI extension plus service wiring — so it does not map onto Laravel's service-provider and config model without a port; there is no drop-in story. Its real value is conceptual: a thin abstraction over named counters, gauges, and timers with pluggable backends. That abstraction is worth having, and it is cheap to own — a small service behind an interface, with a vendor adapter behind it, so instrumentation at call sites survives a backend change. Adding this package would put an unmaintained PHP 7-era dependency into our graph to solve a problem we can solve in a day. If any legacy Symfony service already runs it, keep it, pin the version, and containerize it away from new code.

The ask: Approve the no-go, and redirect the underlying instrumentation request to the platform team with OpenTelemetry as the default backend and an internal facade as the contract. Success looks like: one metrics interface adopted by service teams, one backend we can replace, and zero unmaintained dependencies introduced this quarter to get there.