Laravel Request Logger Laravel Package

Technical Evaluation

Architecture Fit

• Middleware-Based Design: The package leverages Laravel’s middleware stack, making it a non-intrusive addition to existing request handling. This aligns well with Laravel’s middleware-first philosophy (e.g., Kernel.php).
• Extensibility: Custom log_profile and log_writer classes allow for granular control over logging logic (e.g., filtering by route, user role, or request type).
• Sanitization: Built-in sensitive data masking (e.g., passwords, tokens) reduces compliance risks (GDPR, PCI-DSS) without manual intervention.
• Storage Agnosticism: Supports any filesystem disk (local, S3, etc.), enabling scalability for high-traffic apps.

Integration Feasibility

• Low Friction: Single Composer install + config publish + middleware registration (app/Http/Kernel.php).
• Laravel Native: Uses Laravel’s Log facade and filesystem APIs, minimizing dependency conflicts.
• Middleware Hooks: Can be placed early (e.g., web group) to capture all requests or late (e.g., auth group) for authenticated users only.

Technical Risk

• Performance Overhead: Logging every request/response may impact latency in high-throughput systems. Mitigation: Use log_profile to filter logs (e.g., only POST requests or error paths).
• Storage Bloat: Unchecked log retention can fill disks. Mitigation: Configure rotation via the provided rotate-logs command or integrate with Laravel’s filesystem rotation.
• Sensitive Data Leaks: Misconfigured sanitization could expose PII. Mitigation: Test with edge cases (e.g., nested JSON payloads, custom headers).
• Dependency Maturity: Package has no stars/downloads, indicating unproven stability. Risk: Potential bugs in edge cases (e.g., large payloads, custom log writers).

Key Questions

1. Use Case Alignment:
   • Is logging all requests justified, or should we filter by route, HTTP method, or user role?
   • Do we need real-time log analysis (e.g., ELK stack) or just archival?
2. Storage Strategy:
   • What’s the retention policy (e.g., 30 days)? How will we handle log rotation?
   • Is S3/remote storage required, or will local disk suffice?
3. Performance Impact:
   • What’s the expected request volume? Should we sample logs (e.g., 1% of requests)?
   • Are there alternatives (e.g., Laravel’s built-in Log::channel() with structured logging)?
4. Compliance:
   • Does the sanitization cover all sensitive fields in our payloads?
   • Are logs encrypted at rest (if using S3/local storage)?
5. Monitoring:
   • How will we alert on log failures (e.g., disk full, write errors)?
   • Should logs be forwarded to a SIEM (e.g., Splunk, Datadog)?

Integration Approach

Stack Fit

• Laravel Ecosystem: Seamless integration with Laravel’s middleware, filesystem, and logging systems.
• PHP Version: Requires PHP 8.0+ (check compatibility with your stack).
• Dependencies: Only requires Laravel 8.x+ and PHP’s native filesystem APIs (no heavy libraries).

Migration Path

1. Installation:

   composer require the-caretakers/laravel-request-logger
   php artisan vendor:publish --provider="TheCaretakers\RequestLogger\Providers\RequestLoggerServiceProvider" --tag="request-logger-config"
   

2. Configuration:
   • Set disk to a dedicated filesystem (e.g., logs disk in config/filesystems.php).
   • Configure log_profile to filter requests (e.g., only POST /api/*).
   • Example config/request-logger.php:

     'log_profile' => \App\Services\LogProfile::class, // Custom filter logic
     'sanitize' => [
         'headers' => ['authorization', 'cookie'],
         'payload' => ['password', 'credit_card'],
     ],
     

3. Middleware Registration: Add to app/Http/Kernel.php:

   protected $middleware = [
       // ...
       \TheCaretakers\RequestLogger\Middleware\RequestLogger::class,
   ];
   

   Optional: Place in a specific group (e.g., web or api) for targeted logging.
4. Testing:
   • Verify logs appear in storage/app/request-logs/ (or configured disk).
   • Test sanitization with sample payloads containing sensitive data.
   • Validate rotation with php artisan request-logger:rotate.

Compatibility

• Laravel Versions: Tested on 8.x+; may need adjustments for Lumen or Laravel 7.x.
• Custom Log Writers: If extending, ensure the class implements TheCaretakers\RequestLogger\Contracts\LogWriter.
• Monolithic vs. Microservices: Better suited for monolithic Laravel apps; microservices may need distributed logging (e.g., ELK).

Sequencing

1. Phase 1: Pilot with a non-critical endpoint (e.g., /health).
2. Phase 2: Gradually roll out to high-value routes (e.g., /api/payments).
3. Phase 3: Integrate rotation/alerting and monitor storage growth.
4. Phase 4: Extend with custom log_profile or log_writer if needed.

Operational Impact

Maintenance

• Configuration Drift: Centralized config (config/request-logger.php) reduces drift risk.
• Dependency Updates: Monitor for breaking changes in Laravel or PHP core.
• Log Management:
  • Rotation: Use the built-in rotate-logs command or cron job:

    * * * * * php artisan request-logger:rotate
    

  • Retention: Set up filesystem cleanup (e.g., Laravel’s filesystem rotation or S3 lifecycle rules).

Support

• Debugging:
  • Logs can aid in reproducing issues (e.g., malformed requests, missing headers).
  • Downstream Impact: Logs may reveal API consumer errors (e.g., invalid payloads).
• Incident Response:
  • Logs can correlate requests with errors (e.g., failed payments → log the exact request).
  • Forensics: Useful for security audits (e.g., brute-force attempts).
• Documentation:
  • Add internal docs on log structure (fields, sanitization rules).
  • Train devs on customizing log profiles for edge cases.

Scaling

• High Traffic:
  • Sampling: Use log_profile to log only a subset (e.g., error paths).
  • Async Logging: Consider offloading writes to a queue (e.g., Laravel Queues) to avoid blocking requests.
  • Storage: Scale disk (e.g., S3) or archive old logs to cold storage.
• Multi-Region:
  • Deploy logs to region-specific disks (e.g., logs-us, logs-eu).
  • Use CDN for log access if querying logs remotely.

Failure Modes

Ramp-Up

• Onboarding:
  • 1-2 Hours: Install/config for basic logging.
  • 1 Day: Customize log_profile and test sanitization.
  • 1 Week: Integrate rotation/alerting and validate in staging.
• Skills Transfer:
  • Devs: Teach how to extend log_profile or log_writer.
  • Ops: Document log retention and alerting setup.
• Training:
  • Workshop: Demo logging a sample request/response cycle.
  • Cheat Sheet: Key commands (install, rotate, debug).