- Is m6web/statsd-prometheus-bundle a Laravel package?
- No. Despite being filed alongside PHP packages, it is a Symfony bundle that integrates through Symfony Bundle registration, a Configuration tree, and a DI extension. Laravel does not consume those mechanisms, so there is no drop-in path. Treat it as a pattern or source of emitter code rather than a Laravel dependency.
- Can I install m6web/statsd-prometheus-bundle in Laravel with Composer?
- There is no working Composer install path from this repository to a functional Laravel integration. The package's entry point is Symfony-only, and the v8.0.2 release only widens dependency constraints. Laravel has its own container, service providers, and config publishing, none of which this bundle supplies.
- How does this package get StatsD metrics into Prometheus?
- It emits counters, gauges, and timings using the m6web/statsd library in DataDog's tagged StatsD wire format. It is designed to sit in front of prometheus/statsd_exporter, which translates those tagged StatsD lines into Prometheus series. Prometheus then scrapes the exporter, typically through a /metrics endpoint.
- What Laravel version support does m6web/statsd-prometheus-bundle offer?
- None officially. The v8.0.2 release allows psr/container 2.* and symfony/contract 3.*, which can reduce Composer collisions with Laravel 10 and 11, but that is a constraint change, not Laravel support. There is still no Laravel service provider, facade, or configuration publishing.
- How do I integrate tagged StatsD metrics into a Laravel application?
- Port the tagged-statsd emitter rather than installing the bundle: extract or reimplement the client and tag formatter, bind a singleton in a Laravel service provider, add a facade, and publish config. Skip the bundle's Symfony event subscribers and middleware, since Laravel has no equivalent hook surface. Validate the emitted tag syntax against statsd_exporter empirically before committing.
- Which StatsD client does this bundle wrap?
- It builds on the m6web/statsd library and adds tag formatting for DataDog-style metrics. The underlying client's health, supported PHP versions, and maintenance activity matter as much as the bundle's. Check that upstream project before deciding whether to fork the bundle or replace the client.
- Does the DataDog tagged StatsD format work with statsd_exporter?
- That is the design intent, but it is the highest-risk unknown for any integration. You need to confirm the emitted tag syntax against statsd_exporter's dogstatsd_tags or datadog parser configuration. Do this empirically with real metric output rather than relying on documentation claims.
- Is m6web/statsd-prometheus-bundle actively maintained?
- Maintenance is dependency-only. The repository has around 3 stars and 0 dependents, with recent v8.x constraint bumps in 2024 or 2025, so it is not abandoned outright, but there is no evidence of feature work, bug triage, or a supported-version policy. There is also no visible security disclosure process or CI compatibility matrix.
- What are the alternatives for Prometheus metrics in Laravel?
- Evaluate dedicated Laravel Prometheus exporters or prometheus/client_php directly, or keep statsd_exporter and write a small tagged StatsD emitter tailored to your app. A custom Laravel service provider around a healthy StatsD client is often simpler than porting a Symfony bundle. Compare scrape-based and push-based approaches against your deployment model.
- What production risks come with StatsD over UDP in a Laravel stack?
- StatsD over UDP is fire-and-forget, so metric loss is silent by design. Correctness depends on the statsd_exporter configuration and your alerting layer, not on the client. Test tag parsing, metric naming, and scrape health in staging, and monitor for gaps before relying on these metrics for alerts.