Srf Datadog Statsd Bundle Laravel Package

Product Decisions This Supports

• Observability instrumentation strategy — this package answers a narrow question ("how do we wire a StatsD client into a Symfony DI container?") and nothing more. It is useful as a reference pattern for a thin config-plus-service-registration wrapper, not as a component to standardize on. Use it to validate that the integration layer is ~100 lines of glue, which informs whether instrumenting PHP services with StatsD metrics is cheap enough to put on the roadmap.
• Build vs. buy — the answer here is build. With 2 stars, 0 dependents, no release since September 2015, and an archived repository, there is no vendor to buy from and no community to lean on. The underlying client (php-datadog-statsd) is the real dependency; the bundle is disposable glue. A Laravel service provider wrapping that client directly is a sub-day task and gives you ownership of version constraints, config shape, and test coverage.
• Framework-fit assessment — this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/*.php publishable config, and no Laravel-version compatibility metadata. Any roadmap item framed as "add Datadog StatsD to our Laravel services" cannot be satisfied by this package; it can only be informed by it.
• Dependency governance / supply-chain policy — a concrete data point for a "no archived or unmaintained dependencies" rule. Zero dependents is not neutral; it means no one has exercised this code in production at scale, so defects would surface first in your environment. Good candidate for a denylist entry rather than a build-vs-buy discussion.
• Use cases it actually covers — emitting counters, gauges, timings, and sets to a Datadog Agent over UDP from a PHP service, with connection settings externalized to bundle config. That's the entire surface area. It does not cover tracing, log correlation, APM spans, or DogStatsD tagging strategy — if the roadmap needs those, this package is out of scope regardless of its maintenance status.

When to Consider This Package

Adoption criteria, and where it fails them:

• Framework match — fails. Symfony-only. A Laravel codebase would be pulling in Symfony DI conventions it doesn't use.
• Maintenance signal — fails. Archived, last release 2015-09-28. That predates PHP 7.0, PSR-11 container interoperability, and Symfony 3. No realistic path to PHP 8.x.
• Community validation — fails. 2 stars, 0 dependents. No downstream users means no battle-testing and no one to escalate bugs to.
• Escape hatch quality — marginal. Since it is a thin wrapper, you could fork it, but forking a Symfony bundle to use in Laravel is strictly more work than writing the equivalent provider.
• Only viable scenario — you are maintaining a legacy Symfony 2.x application from roughly 2015 that already depends on this bundle. In that case, leave it alone, pin it, and plan its removal as part of an observability migration rather than a framework upgrade.

Look elsewhere when: you need Laravel support (write a service provider over the StatsD client), you need current PHP support (evaluate datadog/dd-trace-php or a maintained DogStatsD client), or you need tracing/log correlation alongside metrics (evaluate OpenTelemetry PHP, which also avoids single-vendor lock-in at the instrumentation layer).

How to Pitch It (Stakeholders)

To executives: Recommend not adopting. This is an archived Symfony bundle last released in 2015 with 2 GitHub stars and zero dependent projects — meaning it is unmaintained, untested in the wild, and does not support any currently maintained PHP version. The risk it introduces (unpatched code, no security response path, no upgrade route) outweighs the small convenience it offers. The equivalent capability is a roughly one-day build for our team, so there is no meaningful buy-side savings to weigh against the risk. Treat it as a design reference only.

To engineering: The bundle is thin glue between a Symfony DI container and php-datadog-statsd: config for host/port/namespace plus a service definition. That glue is the part we don't need — we'd write a Laravel service provider with publishable config, a facade or injectable client, and a no-op fallback when the agent is unreachable so metrics never block request handling. The real decision to evaluate is the client and transport (UDP fire-and-forget vs. buffered), tagging conventions, and whether StatsD metrics alone are sufficient or whether we should go straight to OpenTelemetry so metrics and traces share one instrumentation layer. Estimate: one engineer-day for the provider plus tests, excluding dashboards.