Monolog Extra Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap sequencing. The real decision this package informs is whether "structured log enrichment" ships this quarter or waits behind tracing/metrics work. It is a cheap, incremental step (context on every log line) rather than a platform investment — useful as an interim credibility win while OpenTelemetry work is scoped.
• Build vs. buy vs. copy. The package is a Symfony bundle exposing a handful of Monolog processors (request/web context, session, tags, and a config-driven "global extra" processor). For a Laravel codebase the bundle itself is not installable in a meaningful way — its value is as an MIT-licensed reference design. The decision is therefore "copy ~4 small classes or write ~40 lines of middleware," not "adopt a dependency."
• Support-cost and MTTR levers. Per-request fields (URI, method, client IP, user agent, session/user id, release/app tag) let support and on-call filter logs to a single user or session. Frame the investment against reduced triage time per ticket and faster incident containment, not against revenue.
• Log cost and data-governance trade-off. Every added field multiplies log payload size and indexes cardinality in ELK/Datadog. This forces an explicit decision on which fields are always-on vs. sampled, and triggers a PII review (IP, user id, session id, user agent are personal data under GDPR) before anything ships.
• Standardization decision. A shared field-naming convention across services (e.g., extra.request_id, extra.user_id) is a durable architectural choice that outlives any single package; this repo is a starting vocabulary, not the standard itself.
• What it does not support: no customer-facing feature, no new revenue surface, no compliance-grade audit trail (log retention and tamper-evidence are out of scope).

When to Consider This Package

Consider it when:

• You are on Symfony 5/6/7 with Monolog and want config-driven request/session/tag context without writing processors yourself.
• You want a compact, readable reference implementation of context enrichment to copy or fork (MIT permits this).
• You run a small monolith shipping to ELK/Datadog and want this done in an afternoon by one engineer.
• You need a field-naming convention to standardize across a handful of services quickly.

Look elsewhere when:

• You're on Laravel (the likely case here). There is no service provider, no Laravel config integration, and the DI wiring is Symfony-specific. Use Log::shareContext() plus a small middleware for request/user/session fields, or tap the channel to push processors. That covers ~90% of the package's function in first-party code.
• You need traces and metrics, not just log fields. Go to OpenTelemetry PHP with Laravel instrumentation, or Sentry/Datadog APM. Log context alone won't answer latency and dependency questions.
• You need redaction, retention policy, or PII scrubbing. That's a dedicated logging-pipeline concern; this package adds fields, it does not govern them.
• You need vendor support, an SLA, or ecosystem validation. 6 stars and 0 dependents means effectively no community proof, and the m6web → BedrockStreaming namespace move is a mild abandonment signal. The recent release date helps, but it is a single-maintainer bet.
• Version compatibility is unproven. Verify the Monolog major-version constraint against what Laravel/Symfony already pins before spending any evaluation time — a conflict here ends the conversation.
• You're at high log volume. Validate the hot-path cost of processors per record and the per-GB impact on your logging vendor before enabling globally.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a tiny open-source utility for attaching request and user context to application logs. It has no revenue impact, but it materially shortens the time to diagnose production incidents and support tickets, because on-call can filter logs to a single user, session, or release instead of grepping timestamps. Cost is roughly one engineer-day and no licensing fee (MIT). The recommendation is not to take on the dependency — it's a Symfony bundle and we're on Laravel, with only 6 stars and no downstream users — but to reuse its MIT-licensed approach internally. Approve it as a small observability hygiene item, contingent on a privacy review since the fields it suggests (IP address, user id, session id) are personal data, and on a decision about which fields are always-on versus sampled to keep logging costs flat.

To engineering (one paragraph): Treat m6web/monolog-extra-bundle as a design reference, not a dependency. Port the pattern: a middleware that calls Log::shareContext() with request id, method, URI, client IP, user id, session id, and app/release tag; a tap on the channel to inject static globals (environment, service name, git SHA); and a redaction pass that strips or hashes session ids and IPs before they leave the process. Standardize the field names in a shared constants class so every service and dashboard agrees. Gate it behind config so noise-sensitive channels can opt out, and measure log volume delta in staging before enabling in production. Total effort: half a day to one day, with a PII sign-off as the only external blocker.