Statsd Bundle Laravel Package

Product Decisions This Supports

• Observability build-vs-buy: Decides whether we hand-roll StatsD client wiring and service configuration per app, or adopt a bundle that gives us a ready-made statsd service with Symfony DI integration. For a single service the build cost is small; across a portfolio it compounds, which is where a bundle earns its keep.
• Metrics standardization: Choosing a shared client and configuration surface lets us enforce one metric naming convention, one flush/namespace config, and one set of tags across teams — a prerequisite for dashboards and alerts that actually correlate.
• SLO and alerting roadmap: Teams cannot commit to latency/error-budget targets without a cheap way to emit counters, gauges, and timers from request handlers, console commands, and queue workers. This package is the plumbing behind that commitment.
• Business KPI instrumentation: Beyond infra metrics — signups, checkout completions, payment failures — product analytics often rides the same StatsD pipeline. Deciding on the emitter early avoids a second instrumentation stack later.
• Platform scope decision (important caveat): This is a Symfony bundle, not a Laravel package. If our fleet is Laravel-first, this is effectively a no for direct adoption and a signal to standardize on a framework-agnostic PSR client or a Laravel-native provider instead. That is itself a roadmap-relevant finding.

When to Consider This Package

Adopt when:

• The application is Symfony (the bundle targets Symfony 2-era through modern versions) and we want DI-configured StatsD with minimal glue code.
• We already run a StatsD-compatible backend (Datadog agent, Telegraf, statsd_exporter) and just need emission from PHP.
• Our needs are plain counters, gauges, and timers — not distributed tracing or histogram-heavy instrumentation.
• We are willing to pin the version and accept fork risk: last release was 2023-08-09, the project has ~55 stars, zero known dependents, and a low overall health score. Treat it as vendored infrastructure, not a strategically supported dependency.

Look elsewhere when:

• We are on Laravel — the bundle's service definitions and autoconfiguration won't load; a PSR-14/PSR-18 client wrapped in a service provider is the pragmatic path.
• We need OpenTelemetry traces plus metrics in one SDK, or Prometheus-native exposition rather than push-based StatsD.
• We need advanced tag cardinality control, exemplars, or active security patching guarantees.
• The team has no appetite for maintaining a low-activity dependency — a ~100-line custom wrapper over an existing StatsD client may be lower total cost of ownership than adopting and eventually forking this.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed integration layer that lets our Symfony services emit operational and business metrics with near-zero engineering effort, unlocking dashboards, SLOs, and alerting without a platform project. The cost is low and reversible; the main risk is that the project is community-maintained with a 2023 last release and a thin user base, so we should treat it as a convenience wrapper we can replace in an afternoon rather than a long-term platform commitment.

To engineering: It provides a configured StatsD service and Symfony DI integration so teams stop hand-wiring clients and drifting on metric names. The trade-off is explicit: low activity upstream means we pin the version, keep the usage surface narrow (counters/gauges/timers behind our own thin interface), and plan to fork or swap if it stalls. If we are a Laravel shop, this does not apply — we should standardize on a framework-agnostic client instead, and I'd recommend we make that call before teams independently pick their own emitters.