Console Logger Bundle Laravel Package

Getting Started

Minimal Steps

1. Installation:

   composer require catchamonkey/console-logger-bundle
   

   Ensure your composer.json includes the package under require.

2. Register the Bundle: Add the bundle to app/AppKernel.php (or config/bundles.php for Symfony 4+):

   new Catchamonkey\Bundle\ConsoleLoggerBundle\CatchamonkeyConsoleLoggerBundle(),
   

3. First Use Case: Run a console command that throws an exception (e.g., php bin/console your:command). The exception will now be automatically logged via Monolog at the ERROR level.

Where to Look First

• Configuration: Check app/config/config.yml for Monolog settings (if any customization is needed).
• Logs: Verify logs in app/logs/dev.log (or your configured log file) to confirm exceptions are captured.

Implementation Patterns

Usage Patterns

1. Automatic Exception Logging:

   • The bundle hooks into Symfony’s console command execution and logs all uncaught exceptions thrown during command execution.
   • No manual logging required; exceptions are captured transparently.

2. Integration with Monolog:

   • Logs are written to the same Monolog handlers configured in your application (e.g., monolog.handler in config.yml).
   • Example Monolog config (if needed):

     monolog:
         handlers:
             main:
                 type: stream
                 path: "%kernel.logs_dir%/%kernel.environment%.log"
                 level: error  # Ensure this is set to capture ERROR-level logs
     

3. Workflow for Debugging:

   • Develop Locally: Use dev.log to inspect exceptions in detail.
   • Production: Ensure log rotation and retention policies are in place (e.g., via monolog.handler.rotation).
   • CI/CD: Pipe logs to a service like Sentry or Datadog for alerting.

4. Custom Command Logging:

   • If you need to log exceptions from specific commands, ensure the command extends Symfony\Component\Console\Command\Command (default behavior).
   • For custom command classes, verify the bundle’s event listener is triggered (see "Gotchas" below).

Integration Tips

• Pair with Sentry/Error Tracking: Use the logged exceptions as a trigger for external error-tracking services (e.g., Sentry’s Monolog handler). Example:

  monolog:
      handlers:
          sentry:
              type: service
              id: monolog.handler.sentry
  

• Log Context: Enhance logs with command-specific context by overriding the bundle’s logger or using Monolog’s context feature:

  // In your command:
  $this->getApplication()->getLogger()->info('Custom context', ['command' => $this->getName()]);
  

• Symfony 4+ Adaptation: For Symfony 4/5, register the bundle in config/bundles.php:

  return [
      // ...
      Catchamonkey\Bundle\ConsoleLoggerBundle\CatchamonkeyConsoleLoggerBundle::class => ['all' => true],
  ];
  

Gotchas and Tips

Pitfalls

1. Bundle Not Triggering:

   • Cause: The bundle may not work if your command class does not extend Symfony’s Command class or if the command is executed outside the Symfony kernel (e.g., via a custom script).
   • Fix: Ensure commands are run via php bin/console and extend Symfony\Component\Console\Command\Command.

2. Log Level Mismatch:

   • Cause: If Monolog’s level is set to debug or info, exceptions (logged as ERROR) may not appear.
   • Fix: Configure Monolog to log ERROR level or higher:

     monolog:
         handlers:
             main:
                 level: error
     

3. Outdated Symfony Support:

   • Cause: The bundle was last updated in 2014 and may not support newer Symfony versions (5.x+).
   • Fix: Test thoroughly or fork the bundle to update dependencies (e.g., symfony/console, symfony/dependency-injection).

4. Missing Log Files:

   • Cause: Log directory permissions or Monolog misconfiguration.
   • Fix: Verify app/logs/ is writable and Monolog is properly configured:

     chmod -R 775 app/logs/
     

Debugging Tips

• Check Event Listener: The bundle registers an event subscriber (CatchamonkeyConsoleLoggerBundle\EventListener\ConsoleLoggerListener). Verify it’s loaded by dumping the container’s service tags:

  php bin/console debug:container | grep console.logger
  

• Override Logging Behavior: Extend the bundle’s logger by creating a custom subscriber:

  use Symfony\Component\Console\Event\ConsoleErrorEvent;
  
  class CustomConsoleLoggerSubscriber
  {
      public function onConsoleError(ConsoleErrorEvent $event)
      {
          $logger = $event->getCommand()->getApplication()->getLogger();
          $logger->error('Custom error log', ['exception' => $event->getErrorObject()]);
      }
  }
  

  Register it as a service with the kernel.event_listener tag.

Extension Points

1. Custom Log Format: Override the bundle’s logger by injecting a custom Monolog handler or processor. Example:

   services:
       app.custom_console_logger:
           class: Monolog\Handler\StreamHandler
           arguments: ['%kernel.logs_dir%/console_errors.log']
           tags:
               - { name: monolog.logger, channel: console }
   

2. Exclude Specific Commands: Filter exceptions by command name in a custom subscriber:

   if ($event->getCommand()->getName() !== 'your:excluded-command') {
       $logger->error($event->getErrorObject());
   }
   

3. Add Metadata: Attach command metadata (e.g., input arguments) to logs:

   $logger->error('Command failed', [
       'command' => $event->getCommand()->getName(),
       'input' => $event->getInput(),
       'output' => $event->getOutput(),
   ]);
   

Configuration Quirks

• No Explicit Configuration: The bundle requires zero additional configuration beyond installation. All logging uses the default Monolog setup.

• Symfony Flex Compatibility: If using Symfony Flex, ensure auto-wiring is enabled in config/services.yaml for custom subscribers:

  parameters:
      container.autowiring.strict_mode: true