MonologBundle

MonologBundle integrates the Monolog logging library into Symfony’s dependency-injection container, turning what would otherwise be manual handler and formatter instantiation into declarative configuration under config/packages/monolog.yaml. It supports the full range of Monolog handler types — stream, syslog, rotating file, console, GELF, Slack, email, and many more — each configurable per-environment (dev/prod/test) with its own level, bubbling behavior, and formatter options.

The bundle’s dependency-injection extension (MonologExtension, backed by an ~1,000-line Configuration class defining the full config schema) also handles Symfony-specific concerns: routing log records to named “channels” so different parts of an application (e.g. security, doctrine, request) can have independent handler stacks, processor registration via compiler passes, and automatic request-context enrichment. This makes it the standard way any Symfony application configures where its logs go and how they’re formatted, without writing PHP bootstrapping code for Monolog directly.

What You Get

• Declarative configuration for every major Monolog handler type (stream, rotating file, syslog, console, GELF, Slack, email, Sentry-compatible service handlers) under config/packages/monolog.yaml
• Named logging “channels” that let different application subsystems (security, doctrine, request, mailer) route to independent handler stacks with their own levels
• Per-environment configuration overrides (dev/test/prod) so verbose console/debug handlers are automatically excluded from production
• Compiler passes (AddProcessorsPass, LoggerChannelPass) that wire tagged processor services and channel-specific loggers into the container automatically
• A FormatterConfigurator for attaching custom Monolog formatters to handlers declaratively rather than via manual service construction

Common Use Cases

• Routing application logs to different destinations per environment — e.g. console + file in dev, syslog or a log-aggregation service in production
• Isolating noisy framework subsystem logs (Doctrine query logs, security events) into separate channels with independent verbosity
• Sending critical error-level logs to Slack, email, or a GELF-compatible log aggregator (Graylog, Logstash) without custom bootstrapping code
• Enriching log records with request context (IP, route, session data) via Monolog processors registered through the bundle’s compiler pass

Under The Hood

Architecture — The bundle’s core is src/DependencyInjection/Configuration.php (~1,040 lines), a Symfony Config TreeBuilder definition enumerating every supported handler type and its options, consumed by MonologExtension.php (~870 lines) which translates the resulting config array into container service definitions for Monolog handlers, formatters, and the logger channel hierarchy; Compiler/AddProcessorsPass.php and LoggerChannelPass.php run after extension loading to wire tagged processor services and per-channel loggers into their target handlers. Tech Stack — PHP 8.2+, built directly on monolog/monolog ^3.6 and Symfony 7.3/8.0’s config, dependency-injection, http-kernel, and monolog-bridge components, with no other runtime dependencies. Code Quality — 7 PHPUnit test files cover the extension and configuration-parsing logic, focused specifically on validating the large configuration schema translates correctly into container services rather than testing Monolog’s own handler behavior (which is Monolog’s own test responsibility); the codebase is small and tightly scoped (six PHP files under src/) reflecting its role as a thin, focused DI-configuration layer. API Design — The entire public interface is YAML configuration rather than a PHP API — a developer never instantiates a class from this bundle directly, but instead declares handler stacks and channels in monolog.yaml, which trades some flexibility for a very low-friction, discoverable configuration surface backed by Symfony Config’s built-in validation and helpful error messages on misconfiguration.