Metrics Bundle Laravel Package

Product Decisions This Supports

• Observability build-vs-buy. An MIT-licensed Prometheus exporter is a "build cheaply" data point in the decision to keep paying for Datadog/New Relic/AppSignal versus standing up Prometheus + Grafana and instrumenting in-house. It lets you price the self-hosted option credibly instead of guessing.
• Framework strategy, not just tooling. This is a Symfony bundle, not a Laravel package — no service provider, no facade, no Laravel routing. If the decision on the table is "Laravel or Symfony," this package only exists inside the Symfony branch. For a Laravel codebase the equivalent decision moves to spatie/laravel-prometheus or a hand-rolled /metrics route. Treat this as evidence that the Prometheus path is cheap on Symfony, not as a Laravel dependency.
• Roadmap and usage analytics. A scrape endpoint feeds SLO dashboards, error-rate and latency tracking (RED metrics), and feature-adoption telemetry — the difference between "we think this is used" and a prioritization input you can defend.
• Capacity and cost planning. Infrastructure metrics (memory, request counts, DB timings) give finance and platform leads the numbers for scaling and hosting decisions without an APM contract.
• Incident readiness. Can the team detect and page on regressions before customers report them? A metrics endpoint plus alerting rules is the minimum viable answer, and its absence is a roadmap risk you should name.
• Maintenance ownership as a product cost. With 0 stars, 0 dependents, and a last release of July 2022, adopting this makes the team the de facto maintainer. That is a resourcing decision, not a technical one, and belongs in the same conversation as the observability budget.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony 5/6 on PHP 8, and you control the kernel configuration.
• You already operate Prometheus and Grafana, or are committed to standing them up. Without a Prometheus server this bundle produces nothing useful.
• You need generic infrastructure and request metrics quickly — memory, request counts, DB timings — and do not need distributed tracing, exemplars, or high-cardinality business metrics.
• You are comfortable vendoring or forking the code with a named internal owner. That is the realistic usage model for an artifact with no community.

Look elsewhere when:

• You are on Laravel. The bundle's DI tags and auto-registration do not resolve in Laravel's container; only the library-level classes are reusable, and only with adapter work. promphp/prometheus_client_php behind a service provider, or spatie/laravel-prometheus, covers the same surface with less effort.
• You need maintained dependencies. No release since mid-2022 means no PHP 8.3/8.4 compatibility guarantee, no Symfony 7 support, no security patching, and key-person risk.
• You need more than a scrape endpoint. No tracing, no log correlation, no APM-grade profiling. If those are requirements, OpenTelemetry or a commercial tool is the honest choice.
• Nobody owns Prometheus operations. Self-hosted Prometheus is free in license and expensive in attention; the TCO argument collapses if no one owns the alerting rules.
• Cardinality control is a hard requirement. Unbounded labels are the most common cause of metrics outages; if the package gives you no label allow-listing, budget for enforcing it at the instrumentation layer regardless.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed way to publish operational metrics from Symfony services into Prometheus, so we can build dashboards and alerting without an APM subscription. It is small and low-risk to trial, and the permissive license means we can fork it internally if upstream stays quiet — which, given a last release in 2022 and effectively zero adoption, is the assumption we should plan on. Recommend a time-boxed spike, not a platform commitment, and name an owner before we depend on it in production.

To engineering: A thin Symfony bundle that wraps promphp/prometheus_client_php and exposes a Prometheus text-format scrape endpoint, with a collector abstraction for counters, gauges, and timings. Two constraints to state up front: it is Symfony-only, so Laravel teams should use spatie/laravel-prometheus or wrap the underlying client directly; and it is dormant, so we inherit all patching. The sensible pattern is to evaluate it as a reference implementation and vendor the pieces we need rather than take a long-term Packagist dependency. Practical guardrails: pick a real storage backend (APCu per host, Redis for multi-instance — in-memory is a smoke test only), keep the /metrics route off the public internet, cap label cardinality, set scrape timeouts so a slow collector cannot block PHP-FPM workers, and add a smoke test asserting valid exposition format after every dependency bump. If the spike shows we need more than counters and gauges, skip straight to OpenTelemetry rather than accumulating custom instrumentation we will have to migrate later.