Statsd Request Headers Bundle Laravel Package

Product Decisions This Supports

• Observability dimensioning: should request headers (and route) be a first-class metric tag? The package answers a narrow question — "can we slice request volume/latency by header-derived attributes in StatsD?" — and its answer is a design pattern, not a dependency: a kernel event listener that extracts configured values and emits them as StatsD tags. v1.1.0 ("add route and optim names") extends that pattern toward route-derived tags and cheaper tag naming, which is the genuinely interesting signal here: route is a bounded-ish dimension where header values are not. The pattern remains the reusable artifact; the code does not.
• Build vs. buy (buy → build, unchanged). A single minor release does not convert an abandoned package into a maintained dependency. There is no changelog discipline, no stated support window, no CI/PHP-version compatibility signal, and one maintainer. The decision still collapses to "spend 1–2 days writing a listener/middleware + a StatsD client call" versus "vendor a Symfony bundle and own it forever." Build still wins.
• Data governance / privacy posture. Storing raw request headers in a metrics backend is a PII and secrets-exfiltration risk: Authorization, Cookie, X-Forwarded-For, Referer, and tenant identifiers routinely land in headers. A PM decision this informs is whether header-derived metrics require an allowlist of non-sensitive headers plus hashing/salt for anything identifying — a policy this package still does not enforce.
• Cardinality budget. v1.1.0 adds route, which is lower cardinality than raw headers but still unbounded under dynamic path segments (/orders/{id} vs /orders/12345). Any adoption decision must pair with an explicit tag-cardinality cap and a route-normalization rule. The "optim names" change hints at tag-budget pressure but ships no documented guardrail, so that cost still lands on your platform team.
• Roadmap signal, not roadmap input. The 2016-era workaround has been absorbed by OpenTelemetry/StatsD-with-tags and structured logging. A lone 2024-vintage-style housekeeping release is a maintenance blip, not a revival — a "do not revisit" note plus a watch item, not a backlog item.

When to Consider This Package

Criteria for adoption (all must hold):

• You are on legacy Symfony 2.x/3.x with the original m6web/statsd client already in the stack — this is a Symfony bundle wired through the DI container and kernel events, so it has no path into Laravel beyond reading it as a design reference.
• You need a working example of how to hook kernel.request/kernel.response and emit tagged metrics (now including route), and you intend to fork or reimplement, not composer require.
• You have a StatsD backend that accepts tags and a cardinality policy already agreed — including a route-templating rule.
• You have verified the release actually runs on your PHP version. v1.1.0 ships a one-line summary and no compatibility statement; treat "it released" as unrelated to "it works on 8.x."

When to look elsewhere (i.e., almost always):

• Any Laravel application — bundles are Symfony-kernel constructs; Laravel's equivalent is middleware or terminable middleware, and there is nothing here to install. This remains the dominant case and is unaffected by the release.
• Any production system. One release after a multi-year gap does not restore: security response, dependency updates, PHP 8.x guarantees, or an upstream fix cadence. Unmaintained-by-default code on the request path of every HTTP call is still a standing liability.
• Any team without a named owner for the metrics pipeline — you would be adopting a dependency and simultaneously becoming its maintainer.
• When the underlying need is better served elsewhere: OpenTelemetry instrumentation, Laravel Telescope/Pulse-style middleware, or structured request logging give you header- and route-derived dimensions with far better sampling and redaction support.
• When headers contain anything sensitive and you have no redaction layer — do not start here, regardless of version.

How to Pitch It (Stakeholders)

For executives: Still not recommended for adoption. A new v1.1.0 exists — described only as "optimise event (add route and optim names)" — but it is a single maintenance release from a package that previously had no activity since September 2016, with zero stars and zero dependents. One commit does not create a support commitment, a security response process, or a compatibility guarantee. The underlying idea (tagging request metrics with header- and route-derived attributes) is sound and already reflected in our observability roadmap; the code itself still carries unquantified maintenance, security, and compliance risk if placed on the request path.

For engineering: Treat it as a ~50-line reference pattern, not a dependency. The v1.1.0 change is directionally correct and worth reading — adding route as a dimension and tightening tag names is exactly the cardinality-aware thinking the original lacked — but the four non-negotiables remain ours to build: an explicit allowlist of non-sensitive headers, a route-normalization + cardinality cap on tag values, redaction of Authorization/Cookie, and unit tests asserting sensitive headers can never be emitted. Estimated effort: 1–2 days, versus indefinite ownership of an unmaintained fork.

Recommendation: Keep as rejected — reference only, and correct the record in the rejection note: version pin is now v1.1.0, not "no release since 2016," so the rationale must rest on maintenance posture and architecture mismatch rather than inactivity. Log the pattern (including the route-dimension refinement) in our observability design notes, assign the middleware work to the platform backlog, and set a low-cost watch: revisit only if the package shows sustained releases plus a Laravel-viable distribution path — neither of which a single housekeeping commit establishes.