Simple Logger Laravel Package

Technical Evaluation

Architecture Fit

• Minimalist PSR-14 Compliance: The package provides a lightweight implementation of \Psr\Log\LoggerInterface, making it suitable for projects requiring basic logging without heavy dependencies (e.g., Monolog, Symfony Logger). Ideal for:
  • Greenfield projects where logging is a low-priority feature.
  • Legacy systems needing PSR-14 compliance without refactoring.
  • Microservices with strict resource constraints (e.g., serverless functions).
• Limitation: Lacks advanced features (e.g., log rotation, structured logging, async handling). Not suitable for high-observability systems (e.g., distributed tracing, ELK stack integration).

Integration Feasibility

• PHP 8.0+ Required: Ensures compatibility with modern Laravel (8.x+) but may exclude older PHP versions.
• No Laravel-Specific Features: Works as a generic PSR-14 logger; requires manual wiring (e.g., binding to Laravel’s container via Log::driver() or LoggingChannel).
• Output Flexibility: Supports file, CLI, or custom handlers via setHandler(), but lacks built-in Laravel integrations (e.g., single channel, stack channel).

Technical Risk

• Low Risk for Basic Use Cases: Minimal setup, no breaking changes expected.
• Medium Risk for Advanced Scenarios:
  • Missing Contextual Logging: No support for structured logs (e.g., JSON) or stack traces by default.
  • No Async Support: Blocking writes may impact performance in high-throughput apps.
  • Error Handling: Crashes in handlers (e.g., file I/O) could silently fail.
• Dependency Risk: Zero dependents suggest limited real-world validation.

Key Questions

1. Why Not Use Laravel’s Built-in Logger?
   • Does the project need PSR-14 abstraction for vendor packages?
   • Are there specific constraints (e.g., avoiding Monolog’s ~10MB footprint)?
2. Handler Strategy:
   • How will logs be routed (file, syslog, custom)? Does the package’s setHandler() suffice?
3. Performance Requirements:
   • Will async logging or batching be needed (e.g., for 10K+ requests/sec)?
4. Observability Needs:
   • Are structured logs or metadata (e.g., request IDs) critical?
5. Future-Proofing:
   • Is the team open to migrating to a more feature-rich logger (e.g., Monolog) later?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Direct Integration: Bind the logger to Laravel’s container via config/logging.php:

    'channels' => [
        'simple_logger' => [
            'driver' => 'custom',
            'via' => \Averor\SimpleLogger\Logger::class,
            'handler' => env('LOG_HANDLER', 'file'),
        ],
    ],
    

  • Handler Options:
    • File: Use setHandler(new \Averor\SimpleLogger\Handler\FileHandler('/path/to/logs.log')).
    • CLI: Use setHandler(new \Averor\SimpleLogger\Handler\StreamHandler('php://stdout')).
    • Custom: Extend \Averor\SimpleLogger\Handler\AbstractHandler for unique needs.
• Alternate Approach: Use as a fallback logger in App\Exceptions\Handler or for non-critical logging.

Migration Path

1. Phase 1: Pilot Testing
   • Replace a non-critical logger (e.g., debug logs) with simple-logger to validate integration.
   • Compare output format with existing logs (e.g., Monolog’s JSON vs. plain text).
2. Phase 2: Full Rollout
   • Update config/logging.php to route specific channels (e.g., single) to simple-logger.
   • Deprecate legacy loggers incrementally.
3. Phase 3: Feature Gaps
   • If structured logs are needed, wrap the logger in a decorator to add metadata:

     $logger = new StructuredLogger(new \Averor\SimpleLogger\Logger());
     

Compatibility

• Pros:
  • Zero external dependencies (beyond PHP core).
  • PSR-14 compliant; works with any PSR-14-aware package.
• Cons:
  • No Laravel-Specific Integrations: Missing Log::channel() support out of the box.
  • Handler Limitations: Custom handlers must be implemented manually.
  • No Queue Integration: Cannot leverage Laravel’s queue system for async logging.

Sequencing

1. Prerequisites:
   • PHP 8.0+ and Laravel 8.x+.
   • Basic logging configuration in config/logging.php.
2. Steps:
   • Install via Composer: composer require averor/simple-logger.
   • Create a custom driver in config/logging.php.
   • Test with Log::channel('simple_logger')->info('Test message').
3. Post-Integration:
   • Monitor log file/handler performance under load.
   • Plan for potential migration to Monolog if gaps are critical.

Operational Impact

Maintenance

• Pros:
  • Low Maintenance: Minimal codebase (~500 LOC); easy to audit/modify.
  • No External Dependencies: Updates are PHP/Laravel version-dependent only.
• Cons:
  • Manual Handler Management: Custom handlers require local maintenance.
  • No Built-in Rotation: Log files must be managed externally (e.g., Laravel’s log-rotate or logrotate).
  • Limited Tooling: No native support for log aggregation (e.g., Papertrail, Datadog).

Support

• Pros:
  • Simple Debugging: Plain-text logs are easy to read and grep.
  • No Vendor Lock-in: PSR-14 standard ensures portability.
• Cons:
  • No Official Support: Community-driven; issues may go unanswered.
  • Lack of Documentation: Minimal examples or best practices.
  • Error Isolation: Handler failures (e.g., disk full) may crash the app unless wrapped in try-catch.

Scaling

• Performance:
  • Synchronous Writes: Not suitable for high-write scenarios (e.g., >1K logs/sec) without async workarounds.
  • Memory Usage: Negligible overhead; ideal for low-resource environments.
• Horizontal Scaling:
  • Stateless Design: Works in stateless setups (e.g., queue workers), but log handlers must be shared (e.g., NFS for file logs).
  • No Distributed Logging: Lacks features like correlation IDs or structured metadata for distributed tracing.
• Workarounds:
  • For async logging, pair with Laravel’s queue system:

    Log::channel('simple_logger')->useQueue()->info('Async message');
    

    (Requires custom handler implementation.)

Failure Modes

Ramp-Up

• Developer Onboarding:
  • Pros: Easy to understand; no complex setup.
  • Cons: Lack of Laravel-specific examples may slow adoption.
• Training Needs:
  • Document custom handler implementations.
  • Train ops teams on log file management (rotation, retention).
• Tooling Gaps:
  • Integrate with existing monitoring (e.g., Prometheus metrics for log volume).
  • Set up alerts for log handler failures (e.g., via Laravel’s failed job queue).