Laravel Request Logger Laravel Package

Technical Evaluation

Architecture Fit

• Zero-configuration logging aligns well with Laravel’s middleware-driven architecture, enabling granular control via route-level middleware or global configuration.
• Driver-based extensibility (e.g., custom log storage like Elasticsearch, S3, or third-party APIs) leverages Laravel’s Manager Pattern, reducing vendor lock-in and allowing future-proofing.
• Correlation-ID integration (via bilfeldt/laravel-correlation-id) enhances observability for distributed systems, aligning with modern microservices and observability trends.
• Pruning support via Laravel’s model:prune (or custom commands) ensures scalability for high-traffic applications by preventing log bloat.

Integration Feasibility

• Minimal setup: Requires only composer require + migrations, with optional config publishing. Low friction for adoption.
• Middleware-first approach: Seamlessly integrates with Laravel’s middleware stack (e.g., Route::middleware('requestlog')), avoiding invasive changes to business logic.
• Database agnosticism: Supports dedicated logging databases (via REQUEST_LOGGER_DB_CONNECTION), reducing main DB load and enabling archival strategies.
• Header filtering: Case-insensitive HTTP header filtering (e.g., Authorization) prevents sensitive data leaks while logging payloads.

Technical Risk

• Breaking changes in v3.x:
  • Correlation-ID dependency: Requires bilfeldt/laravel-correlation-id (v3.0+), adding a new dependency. Mitigate by evaluating if this is acceptable for your stack.
  • Migration changes: New columns (correlation_id, request_id) in request_logs table may require downtime for large deployments. Test in staging first.
  • Removed features: aggregate() method and log_context config require migration to alternatives (e.g., laravel-route-statistics).
• Performance overhead:
  • Logging every request/response adds I/O latency. Benchmark in staging to validate impact (especially for high-QPS APIs).
  • Database writes for every request may strain connections. Test with your DB’s write capacity.
• Sensitive data exposure:
  • Default config excludes api_token but may need customization for other PII (e.g., password, credit_card). Use config('request-logger.headers') to filter.
  • Response payloads are logged by default; sanitize or exclude sensitive fields (e.g., response->setContent('***')).

Key Questions

1. Observability goals:
   • Is this for debugging (ad-hoc logs) or analytics (aggregated metrics)? If analytics, consider pairing with bilfeldt/laravel-route-statistics.
   • Do you need real-time monitoring (e.g., Slack alerts for 5xx errors)? Extend with custom drivers (e.g., webhooks to PagerDuty).
2. Data retention:
   • How long should logs be retained? Configure pruning (e.g., requestlog:prune --days=30).
   • Will logs be exported (e.g., to Elasticsearch)? Extend with a custom driver.
3. Security/compliance:
   • Are there GDPR/PCI requirements for log sanitization? Customize RequestLog model to redact fields.
   • Should logs be encrypted at rest? Use Laravel’s Encrypted Database Fields or a custom driver.
4. Scalability:
   • For high-throughput systems, consider async logging (e.g., queue-based) or a dedicated logging service (e.g., AWS CloudWatch).
   • Will logs be queried frequently? Add indexes to request_logs (e.g., user_id, path, status_code).
5. Migration strategy:
   • Can you test v3.x’s breaking changes in a staging environment before production rollout?
   • Do you need to backfill logs for historical analysis? Use a custom migration to populate correlation_id/request_id.

Integration Approach

Stack Fit

• Laravel 10–13.x: Native support with zero configuration for most use cases.
• PHP 8.1–8.5: Compatible with modern PHP features (e.g., enums, attributes).
• Database: Works with MySQL, PostgreSQL, SQLite (default). Supports dedicated logging DBs via REQUEST_LOGGER_DB_CONNECTION.
• Observability stack:
  • Correlation-ID: Integrates with laravel-correlation-id for distributed tracing (e.g., Jaeger, Datadog).
  • Custom drivers: Extend to log to Elasticsearch, S3, or third-party APIs (e.g., Splunk).
• CI/CD:
  • Tests included; validate with composer test in your pipeline.
  • Migration tests: Ensure php artisan migrate succeeds in CI.

Migration Path

1. Assessment phase:
   • Audit current logging (e.g., Monolog, custom tables) to identify gaps.
   • Decide on scope: Start with critical routes (e.g., /api/payments) before global enablement.
2. Dependency updates:
   • If upgrading from v1/v2 to v3.x:
     • Add bilfeldt/laravel-correlation-id (composer require).
     • Run migrations to add correlation_id/request_id columns.
     • Replace aggregate() calls with laravel-route-statistics.
3. Configuration:
   • Publish config: php artisan vendor:publish --tag=request-logger-config.
   • Customize:

     'headers' => ['authorization', 'proxy-authorization'], // Case-insensitive filtering
     'exclude_parameters' => ['password', 'credit_card'],
     'log_statuses' => ['4**', '5**'], // Log only errors
     

4. Deployment:
   • Phased rollout: Enable logging for a subset of routes first (e.g., Route::middleware('requestlog')->group(...)).
   • Monitor performance: Use Laravel Debugbar or New Relic to track latency spikes.
5. Post-migration:
   • Set up pruning: php artisan schedule:run (if using Laravel Forge/Envoyer).
   • Extend with custom drivers if needed (e.g., Elasticsearch).

Compatibility

• Middleware: Works with Laravel’s built-in middleware (e.g., auth, throttle) and third-party packages (e.g., spatie/laravel-honeypot).
• Testing:
  • Mock RequestLog in unit tests:

    $this->partialMock(RequestLog::class, fn($mock) => $mock->shouldReceive('create()->once()));
    

  • Use HttpTests trait for integration tests:

    public function test_logs_request()
    {
        $response = $this->get('/api/endpoint');
        $this->assertDatabaseHas('request_logs', ['path' => '/api/endpoint']);
    }
    

• Legacy systems:
  • If using Laravel <10, use v2.x (but note PHP 8.2+ requirement).
  • For non-Laravel PHP, this package is Laravel-specific; consider alternatives like Monolog.

Sequencing

1. Pre-deployment:
   • Test in staging with representative traffic.
   • Validate log sanitization (e.g., no PII leaks).
   • Benchmark performance impact (e.g., ab -n 10000).
2. Deployment:
   • Enable logging for non-critical routes first.
   • Monitor error rates (e.g., 500 responses) post-deployment.
3. Post-deployment:
   • Set up alerts for log volume spikes (e.g., Prometheus + Grafana).
   • Document query patterns for request_logs (e.g., WHERE status_code = 500).

Operational Impact

Maintenance

• Updates:
  • Follow changelog for breaking changes (e.g., v3.x’s Correlation-ID dependency).
  • Minor updates are safe (e.g., v3.8.0 → v3.9.0).
• Dependencies:
  • bilfeldt/laravel-correlation-id (v3.x+) adds maintenance overhead. Monitor for updates.
  • Custom drivers may require updates if they rely on internal package APIs.
• Log rotation:
  • Use Laravel’s prune command or a cron job to manage storage:

    php artisan requestlog:prune --days=30
    

  • For large datasets, consider partitioning the request_logs table by date.

Support

• Troubleshooting:
  • Missing logs: Verify middleware is registered and no exceptions are silenced.
  • Performance issues: Check DB connection pooling and query plans (EXPLAIN ANALYZE).
  • Correlation-ID missing: Ensure `bil