Laravel Log Viewer Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular: Fits seamlessly into Laravel’s monolithic architecture (Lumen/5-8) without requiring microservice-level integration. Lightweight enough for modular setups if logs are centralized.
• Observability Stack: Complements existing tools (e.g., Sentry, Datadog) by providing a self-hosted, UI-driven log inspection layer for development/staging. Avoids vendor lock-in (unlike SaaS alternatives).
• Log Format Agnostic: Works with Laravel’s default Monolog setup (single/multi-file, rotated logs) but lacks explicit support for structured JSON logs or external log shippers (e.g., Fluentd). Assumes logs are stored locally.

Integration Feasibility

• Low Friction: Zero public assets or vendor routes reduce merge conflicts. Installation is a single Composer dependency + route definition.
• Dependency Risks:
  • Laravel Version Lock: Explicitly supports L4.2–8 but may lag behind minor releases (e.g., Laravel 9+ features like improved logging).
  • Monolog Dependency: Relies on Laravel’s default logging stack; custom log handlers (e.g., syslog, database) may require adjustments.
• Database Impact: None (logs are file-based). No schema migrations or ORM dependencies.

Technical Risk

Key Questions

1. Log Volume/Retention:
   • How large are production logs? Will the UI handle real-time streaming (e.g., tail -f) or only static files?
   • Are logs rotated? If so, does the viewer support multi-file reconstruction?
2. Access Control:
   • Who needs access? Will you use Laravel’s built-in auth or a dedicated service (e.g., OAuth2 proxy)?
3. Log Sensitivity:
   • Are logs scrubbed for PII before viewing? Plan for redaction (e.g., via Monolog processors).
4. Alternatives:
   • Why not use Laravel Forge/Telescope or a SaaS tool (e.g., Logflare)? Justify self-hosting costs (devops overhead).
5. Future-Proofing:
   • Will this replace or augment existing observability tools? Define SLOs for log availability.

Integration Approach

Stack Fit

• Laravel Core: Native integration with Monolog; no conflicts with Laravel’s logging stack.
• Frontend: Zero dependencies (pure PHP/Blade). Works with any Laravel frontend (Livewire, Inertia, vanilla Blade).
• Infrastructure:
  • Self-Hosted: Deploy alongside Laravel (shared host, VPS, or Kubernetes).
  • Air-Gapped: No external APIs; logs remain on-disk.
• CI/CD: Minimal impact. Add to composer.json and deploy as part of the Laravel stack.

Migration Path

1. Discovery Phase (1 day):
   • Audit current logging setup (channels, handlers, rotation).
   • Verify log file locations (default: storage/logs/laravel.log).
2. Installation (0.5 day):

   composer require elkadrey/laravel-log-viewer
   php artisan vendor:publish --provider="Elkadrey\LogViewer\LogViewerServiceProvider"
   

   • Publish config (adjust log_path, max_files, per_page).
3. Route Integration (0.5 day):

   Route::middleware(['auth:sanctum'])->get('/logs', [\Elkadrey\LogViewer\Controllers\LogViewerController::class, 'index']);
   

4. Testing (1 day):
   • Validate with:
     • Default Laravel logs.
     • Rotated logs (if used).
     • Custom log channels (if applicable).
   • Load test with large log files (>10MB).
5. Security Hardening (0.5 day):
   • Add middleware to restrict access (e.g., CanAccessLogs policy).
   • Implement log redaction if needed.

Compatibility

Sequencing

1. Phase 1: Deploy in staging with read-only access for devs.
2. Phase 2: Gradually roll out to production with limited access (e.g., SREs only).
3. Phase 3: Integrate with incident workflows (e.g., link logs to Jira/PagerDuty).
4. Phase 4: (Optional) Extend for custom log sources (e.g., database logs).

Operational Impact

Maintenance

• Vendor Updates: Monitor for Laravel version support. Fork if upstream lags.
• Log Management:
  • Retention: Ensure log rotation policies align with viewer’s max_files config.
  • Cleanup: Add cron job to purge old logs if storage grows unchecked.
• Dependencies:
  • Composer: Update elkadrey/laravel-log-viewer alongside Laravel.
  • Blade Templates: No changes expected unless extending UI.

Support

• Troubleshooting:
  • Logs Missing: Verify log_path in config and file permissions (storage/logs/).
  • Performance Issues: Add per_page limit or implement client-side pagination.
  • Access Denied: Check middleware and user roles.
• Documentation: None provided; create internal runbook for:
  • Setup steps.
  • Common issues (e.g., rotated logs not appearing).
  • Access control rules.

Scaling

• Horizontal Scaling: Stateless UI; scale Laravel app as usual. Log files must be shared storage (e.g., NFS, S3 via log_channel).
• Vertical Scaling: UI performance degrades with large log files (>100MB). Mitigate with:
  • Client-side pagination.
  • Pre-filtering logs (e.g., by severity).
  • Offloading to a dedicated log service (e.g., ELK) for production.
• High Availability: Log files are single points of failure. Replicate logs if uptime is critical.

Failure Modes

Ramp-Up

• Developer Onboarding (0.5 day):
  • Train team on:
    • Accessing logs via /logs route.
    • Filtering by date/severity.
    • Customizing the viewer (extending LogViewerController).
• Incident Response (1 day):
  • Integrate with alerting (e.g., Slack notifications for critical logs).
  • Document how to export logs for analysis (e.g., curl + jq for JSON).
• Feedback Loop:
  • Gather input from devs/SREs on missing features (e.g., search, annotations).
  • Plan for Phase 2 enhancements (e.g., log tailing, team sharing).