Symfony Prometheus Exporter Laravel Package

Product Decisions This Supports

• Observability build vs. buy: this package exposes an app-level /metrics endpoint in Prometheus' text exposition format, so you can answer "do we need a commercial APM seat for every service, or can our existing Prometheus/Grafana stack cover it?" with a real prototype instead of a vendor deck.
• SLO / error-budget roadmap commitments: once technical and business counters (request latency buckets, queue failures, signup/checkout counts) are exported, reliability targets become a product decision you can defend with data rather than an engineering slogan.
• Feature adoption and funnel instrumentation: custom counters and gauges let PMs define metrics at the source (e.g. feature_x_enabled_total) without waiting on a data-warehouse ticket — useful for launch readouts and kill/keep decisions on flagged features.
• Capacity and pricing decisions: gauges for active tenants, queue depth, or usage units feed directly into capacity planning and usage-based pricing tiers.
• Release gating: a scrapeable metrics surface makes "ship/no-ship" a quantitative call (error rate, p95 latency) instead of a vibe check, and keeps those numbers vendor-portable if you later migrate.
• Migration/decommission decisions: consistent metric names across old and new services let you compare parity during a re-platform before switching traffic.

When to Consider This Package

Adopt when:

• You already run (or are committed to running) Prometheus and a dashboarding layer — the exporter is only valuable if something scrapes it.
• Your service is Symfony-based, or a Laravel app where you're comfortable pulling in Symfony components and wiring the bundle manually — this is a Symfony bundle, not a Laravel package, so budget integration work and expect no Laravel service provider, config publishing, or facade.
• You want a thin, vendor-neutral, self-hosted metrics surface with no per-host licensing, and your team has the ops maturity to own the scrape config, retention, and alerting.
• You need standard RED/USE-style application metrics, not deep tracing or log correlation.

Look elsewhere when:

• Your stack is Laravel-first and you want zero-friction setup — prefer Laravel-native options (e.g. spatie/laravel-prometheus or the prometheus/client_php library wrapped in a service provider) before retrofitting a Symfony bundle.
• You need distributed tracing, log aggregation, or product analytics — this is metrics only; pair with OpenTelemetry or a managed APM.
• You need high-cardinality, per-user analysis — Prometheus is the wrong store; use an events pipeline or warehouse.
• You have no Prometheus infrastructure and no appetite to run it — the total cost of ownership dwarfs the package's value; a managed vendor is the cheaper decision.
• Maintenance-risk sensitivity: 3.0.0 is a major bump whose only content is routine dependency refresh and code-style cleanup — a signal of low feature velocity and thin release notes. That's acceptable for a deliberately small exporter, but pin the version, read the composer constraints before upgrading, and assume you may need to fork for fixes.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source adapter that lets our application publish standard performance and business metrics into monitoring tooling we already run. It is a low-cost hedge against per-seat observability contracts and gives us a defensible, data-backed basis for reliability commitments and capacity planning. The 3.0.0 release is housekeeping — updated dependencies and code-style fixes — not new capability; there is no new cost, no new vendor, and no change to the value proposition. The main caveat is that it is a Symfony component in a predominantly Laravel codebase and is maintained at low velocity, so we should treat it as a thin utility to pin and own rather than a strategic dependency.

For engineering (the ask): Upgrade 2.2.0 → 3.0.0 is labeled "nothing special," but it is a major version, so the changelog does not by itself prove backward compatibility. Before merging: diff composer.json for bumped PHP/Symfony/platform constraints, run the full suite against our supported PHP versions, and smoke-test the /metrics scrape endpoint in staging to confirm metric names, label sets, and output format are unchanged (dashboards break silently on renamed labels). Since this is a Symfony bundle used in a Laravel app, verify the bundle registration path still works and that no container-compilation assumptions changed. Pin exact versions in composer.lock, add a /metrics assertion to the smoke suite, and record the upgrade as low-risk-but-verified rather than routine.