Monolog Extra Bundle Laravel Package

Product Decisions This Supports

• Observability & audit trail requirements. The core capability here — auto-injecting request context (method, URI, headers, status, duration) and optionally response payloads into every log record — is the plumbing behind three distinct product needs: incident debugging, support-ticket forensics, and audit/compliance logging. Deciding whether any of those are roadmap items determines whether you need this capability at all.
• Build vs. buy. This is the concrete artifact for that decision. The capability is worth roughly a day of engineering; the package is an archived, ~100-line Symfony bundle with 3 stars and 0 dependents. The "buy" option effectively doesn't exist, which makes "build a small in-house middleware/processor" the clear winner — and gives you a cost anchor for the conversation.
• Scope definition for a logging MVP. Reading the package's processor set is a cheap way to spec your own: which fields to capture, at which log level, sampled or not, structured (JSON) vs. freeform.
• Data-protection policy decisions. Request/response body logging is a PII/GDPR surface, not just a technical feature. You need to decide what gets redacted (auth headers, cookies, payload fields), retention windows, and whether body logging is opt-in per route. This package offers no policy layer — you'll be defining it regardless.
• Framework strategy. It's a Symfony bundle, so it's a direct signal that the Laravel path diverges: Laravel middleware + Monolog context/taps, not a Symfony DI bundle.

When to Consider This Package

Adoption criteria — all of these would have to be true, and even then it's a stretch:

• The stack is Symfony, not Laravel (the bundle buys you nothing in Laravel; Monolog is shared but the DI wiring isn't).
• You're on a legacy, frozen PHP 7.x / older Monolog version and the app is in maintenance-only mode.
• You are willing to vendor the code, own it, and patch it yourself — treat it as sample code, not a dependency.
• No security response SLA or PHP 8 / Symfony 5–7 compatibility is required.

Where to look instead:

• Laravel: middleware that pushes request context via Log::withContext() / Context facade, plus a Monolog tap for response capture. For user-facing audit trails, spatie/laravel-activitylog or an event-sourced audit table is the better fit than raw request logs.
• Symfony: symfony/monolog-bridge and Monolog's built-in introspection/request processors, plus an HttpKernel listener you own. Maintained alternatives exist; a 2018 archive does not qualify.
• Anywhere: ~100–150 lines of first-party middleware. You keep control of redaction, sampling, and schema.

Red flags that disqualify it for production use here: archived repository, last release 2018-11-14, 3 stars, 0 dependents, no maintainer, no demonstrated PHP 8 or modern Symfony support, and no security disclosure path. Zero dependents also means zero field-testing — the code has not been exercised at scale.

How to Pitch It (Stakeholders)

Decision: Do not adopt hexanet/monolog-extra-bundle. Build the equivalent request/response logging in-house.

For executives: We evaluated a package that would have given us request-level logging out of the box. It was archived in 2018, has no maintainer, and no one else uses it. Adding it would put unmaintained third-party code into our production logging path — a security, audit, and maintenance liability that outweighs the saved effort. The same capability is roughly one engineering day of first-party code, which we control. Recommendation: build, don't buy; net cost is low and we avoid the dependency risk entirely.

For engineering: The package's processor design is worth copying; the dependency is not. Implement a middleware that attaches a request ID, method, path, status, duration, and user identifier to the log context, with an allowlist-based redaction step for headers and body fields before anything is written. Enforce structured JSON output and a retention policy. Do not log bodies by default — make it per-route opt-in so we stay clean on PII.

Supporting numbers: 3 stars, 0 dependents, archived, last release November 2018 — versus roughly one day of internal work and full ownership.