Weave Code
Monolog Extra Bundle Laravel Package
hexanet/monolog-extra-bundle
Symfony bundle that extends Monolog with extra logging tools, making it easier to enrich log records with additional context and configure richer logging pipelines in your application. It integrates with Symfony's service configuration for straightforward setup and minimal boilerplate.
:memo: Symfony bundle with extra processors and logger to log request/response
Frequently asked questions about Monolog Extra Bundle
- Can I install hexanet/monolog-extra-bundle in a Laravel application?
- Composer may resolve it, but the package is a Symfony bundle built on FrameworkBundle, service tags, compiler passes and autoconfiguration. Laravel has no bundle kernel, so none of that DI glue has an execution path and you would only inherit dead weight plus transitive Symfony constraints. The practical route for Laravel is to copy the processor classes and register them yourself, not to require the bundle.
- How do I add extra fields to log records in Laravel the way this bundle does?
- Use config/logging.php and attach a Monolog processor through a channel tap class, or push a processor directly onto the logger in the tap's __invoke method. The processor merges your context array into each record's extra key, which is exactly what the bundle does on the Symfony side. Laravel 11 also ships a Context facade that stores shared key/value pairs across channels, which covers most of the same use cases without writing a processor at all.
- Is hexanet/monolog-extra-bundle compatible with Monolog 3 and Laravel 11?
- The 3.x line targets Monolog 3-era code, so the processor signature __invoke(array $record): array should line up with what Laravel 11 expects. The blocker is the Symfony bundle wrapper, not the processors, because Laravel wires Monolog through config/logging.php and channel taps rather than through a bundle kernel. Run composer why-not against your application to confirm resolution before assuming the old Symfony framework-bundle constraint still applies.
- What does the 3.x change 'additions key is not normalized anymore' mean for my log pipeline?
- It means the shape of emitted log records changed, so anything downstream that keys on those field names can break silently. Elasticsearch mappings, Loki label extraction, Datadog facets, saved queries and dashboards are all at risk of returning empty results rather than errors. The release note is a single sentence with no migration guidance, so audit your ingestion and alerting rules before upgrading.
- How does MonologExtraBundle configure extra log context in Symfony?
- You declare the extra fields in bundle YAML configuration and the bundle registers a Monolog processor through the service container to merge them into each record. It is autoconfigured with a processor tag, so it applies across channels and handlers without touching application logging code. That is convenient in Symfony and largely irrelevant in Laravel, where the equivalent is a tap class.
- Is it safe to log request bodies and headers with this bundle in production?
- Body and header logging is the most common cause of credentials and customer data leaking into log stores, and this package does not meaningfully enforce redaction. You must strip Authorization, Cookie, Set-Cookie, password fields and card numbers before records reach any handler, and you should confirm that with a test that asserts on the serialized output. Treat this as a compliance requirement, not a formatting preference.
- How do I test a Monolog processor without breaking logging in production?
- Unit test the processor in isolation by pushing it onto a Logger with a TestHandler or array handler and asserting on the resulting records. Also test the failure path, because a throwing or recursive processor can wedge request handling or take down the logger for the whole request. Wrap processor execution in try/catch and consider a volume circuit breaker on high-traffic channels.
- What are the alternatives to MonologExtraBundle for enriching log context?
- For Laravel, the native options are channel taps, a hand-written processor, or the Context facade introduced in Laravel 11. Monolog also ships processors such as IntrospectionProcessor, WebProcessor and UidProcessor that cover common metadata without third-party code. Writing a twenty-line processor usually beats pulling in a Symfony bundle you cannot actually boot.
- Which Symfony versions does the 3.x line support?
- The 2018-era symfony/framework-bundle constraint reported for older releases needs to be re-verified against the 3.x composer.json rather than carried forward untested. It may have been relaxed, but the release notes give no migration guidance either way. Check the actual constraint file and run composer why-not on your target stack before making a decision.
- Is hexanet/monolog-extra-bundle actively maintained?
- A v3.0.2 release implies an active 3.x line, so older claims that the project is dormant are stale and should not be repeated. The maintenance profile is better described as lightly maintained and poorly documented: a small maintainer base, a one-sentence release note with a typo, and no linked PR, changelog or migration notes for a change that alters emitted log records. Plan for the possibility that you own the code once you depend on it.
Weaver
How can I help you explore Laravel packages today?