Statsd Prometheus Bundle Laravel Package

Product Decisions This Supports

• Metrics instrumentation strategy for PHP services. This bundle is a glue layer: it emits StatsD metrics in DataDog tag format and exposes/forwards them into a Prometheus-compatible pipeline. Adopting or rejecting it is a decision about how your PHP services produce metrics, not just which library to import.
• Push vs. pull for request-scoped workloads. Prometheus is pull-based; PHP-FPM request lifecycles are short-lived and often unroutable. A library that supports pushing to a Pushgateway is a concrete answer to "how do we get PHP metrics into Prometheus at all?" — a real architecture decision that surfaces in infra review.
• Tag/label schema standardization. Tagged metrics (DataDog format) map naturally to Prometheus labels. If you're deciding on a naming and labeling convention across services, this package forces the conversation early — and label cardinality is where observability budgets die.
• Build vs. buy vs. adopt-OSS. The realistic alternatives are (a) write ~200 lines of StatsD/Pushgateway glue yourself, (b) adopt the promphp/prometheus_client_php ecosystem, or (c) go vendor-neutral with OpenTelemetry. This package is the "adopt small OSS" option, and evaluating it is really evaluating that third path.
• StatsD → Prometheus migration sequencing. Teams running DogStatsD today but standardizing on Prometheus need a bridge. This is a candidate bridge, which makes it a lever in a migration roadmap rather than a net-new capability.
• Use cases it plausibly serves: per-route and per-tenant request metrics, business KPIs (signups, checkout events) emitted alongside technical metrics, and unified dashboards across polyglot services where PHP is the odd one out.

When to Consider This Package

Adopt-consider criteria — all should hold:

• You are on Symfony, not Laravel. Despite the framing, this is a Symfony bundle (*Bundle, DI extension, kernel event hooks). There is no Laravel service provider; on Laravel you'd be writing your own integration anyway, which erases most of the value.
• You already operate StatsD/DogStatsD-style emitters and a Prometheus + Pushgateway stack. If either side is missing, you're buying a bridge to nowhere.
• You specifically want tag support in DataDog format while landing in Prometheus — that translation is the package's actual differentiator.
• The metrics are supplementary, not load-bearing. Instrumentation failure should never break a checkout flow; treat this as best-effort telemetry.
• You are willing to fork and own it. Three stars, zero dependents, no release since May 2023. This is effectively an unmaintained internal utility that happens to be public. Budget for a maintainer, or don't adopt.

Look elsewhere when:

• You're on Laravel. Use a Laravel-native StatsD wrapper, promphp/prometheus_client_php, or an OpenTelemetry SDK. Don't port a Symfony bundle to save a day.
• You need traces and metrics together, or vendor neutrality. OpenTelemetry is the strategic answer; a bespoke StatsD-tags-to-Prometheus bridge locks in a format you'll migrate off later.
• You need security patching, SLAs, or a support contract. MIT and abandoned is fine for a logging shim, not for anything in a compliance boundary.
• Cardinality control matters. Tag-heavy emission in a small library usually means label explosion is your problem to solve, not theirs.
• A standard pull-based scrape already works for your deployment (long-running workers, RoadRunner/Swoole). Then the Pushgateway complexity is pure overhead.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that lets our Symfony services send tagged metrics into Prometheus. It is not a platform bet and should not be funded as one. The realistic decision is "fork a 200-line glue library and own it" versus "build the same thing in-house" — roughly comparable cost, slightly better starting point if we're already on StatsD and Pushgateway. The risk is maintenance: last release 2023, three stars, no downstream dependents, so upstream support is effectively zero. Recommend it only as a tactical bridge with a named owner and an expiry date, paired with a standing evaluation of OpenTelemetry as the strategic target.

To engineering: The value is the tag-format-to-Prometheus mapping and the Symfony wiring — you skip the boilerplate of a StatsD client plus Pushgateway push. The cost is that you inherit an unmaintained dependency: pin to a specific commit, vendor or fork it into our namespace, add our own tests around the emit path, and wrap it behind an internal metrics interface so we can swap to OpenTelemetry without touching call sites. Non-negotiable: emission must be non-blocking and failure-tolerant, and label cardinality gets reviewed like any other schema change. If we're on Laravel rather than Symfony, stop here — the integration work exceeds the value.