Laravel App Logger Laravel Package

Getting Started

kitloong/laravel-app-logger records application execution — incoming HTTP requests (method, URL, headers, payload, response, timing) and console runs — as structured entries through Laravel's logging stack. It is a diagnostic/observability aid, not an audit-trail package, so treat its output as "what did the app actually receive and return."

Minimal setup:

1. composer require kitloong/laravel-app-logger — v1.3.0 adds Laravel 13 support, so this is the version to pin if you are on L13. Package discovery registers the service provider automatically; no manual config/app.php entry needed.
2. Publish the config: php artisan vendor:publish --tag=app-logger-config. If the tag does not resolve, publish by provider (--provider="KitLoong\\AppLogger\\AppLoggerServiceProvider") and check what lands in config/.
3. Confirm the destination. The package writes through a dedicated log channel, so look at the channel definition that ships with the published config (or add your own channel in config/logging.php) before assuming output goes to laravel.log.
4. Enable it per environment — .env → APP_LOGGER_ENABLED=true (verify the exact key name in the published config; it is env-driven) — then hit a route and tail -f the resulting file under storage/logs/.

First useful use case: enable it in staging only, reproduce a bug report from a QA user, and read the captured request/response pair instead of asking them to re-describe what they clicked.

Implementation Patterns

Environment gating. The default posture should be: on in local/staging, off in production. Set the enable flag in .env per environment and keep the package's channel out of your production stack unless you have a retention story.

Dedicated channel + structured output. Point the package at its own channel rather than the stack channel. Each entry is a discrete, JSON-ish record, which makes it greppable and pipeable:

jq -c 'select(.status >= 500)' storage/logs/app-logger-*.log

This is where the package earns its keep — you can slice by status, duration, or route without parsing free-text log lines.

Correlate with a request ID. Add middleware that generates a UUID, calls Log::shareContext(['request_id' => $id]) (or withContext), and returns it in a response header. The package's entries then inherit the same context, so a user-reported header value takes you straight to the entry.

Gate noise at the source. Wrap the noisy parts of the app — health checks, webhook endpoints, asset routes — in an exclusion list if the config exposes one, or conditionally skip registration of the middleware in your bootstrap/app.php / route group. Logging every /up and /horizon poll drowns the signal within an hour.

Local debugging loop. During development, leave it on and keep a terminal tailing the channel. It replaces the ad-hoc Log::info($request->all()) lines people scatter through controllers, and it captures the response shape and timing for free.

Console coverage. For scheduled jobs and Artisan commands, the captured entry gives you the invocation and exit context — genuinely handy when a cron behaves differently under schedule:run than it does by hand.

Testing. Add the disable flag to phpunit.xml (<env name="APP_LOGGER_ENABLED" value="false"/>) so the suite does not generate gigabytes of log files in CI.

Gotchas and Tips

• PII and secrets. Headers and payloads are captured verbatim by default. Authorization, Cookie, passwords, and tokens will land on disk. Mask them in the publishable config or via a custom processor before this ever runs anywhere with real user traffic.
• Volume and rotation. Set the channel to daily and constrain LOG_DAILY_DAYS, or the file grows unbounded on a busy host. Check disk usage in staging after a week before trusting it in any long-lived environment.
• Large payloads and uploads. Requests with big JSON bodies or UploadedFile instances are memory- and disk-expensive to serialize. If the config serializes the whole request, exclude file inputs or skip logging on upload routes.
• Streamed and binary responses. streamDownload, StreamedResponse, and file responses cannot be read back for logging; expect the response body to be empty or truncated for those, and do not build assertions on it.
• Config caching. php artisan config:cache bakes the enable flag and the channel name in. Changing .env afterwards has no effect until you re-run config:cache — this is the number-one "it's on but nothing logs" cause.
• Middleware ordering. If you want the final status code and duration, the logger must sit outside the handlers that can short-circuit (auth, throttle, maintenance mode). Register it early in the global stack; otherwise 401/429/503 responses never appear.
• Long-running workers. Under Octane or queue workers, config and channel resolution are per-process. Toggling the flag means a worker restart, not just a config reload.
• Nothing in the logs? Work the list in order: flag set → config cache cleared → channel actually defined in logging.php → middleware registered in the stack → the channel's own level is not filtering the record out.
• Laravel 13 note. v1.3.0 is a compatibility release only — no API, config, or output-format changes versus v1.2.4. Upgrading is safe from this package's perspective; the real constraint is the rest of your dependency graph and your PHP version floor, so check those before bumping the framework.
• Extension points. The useful levers are the logging channel (swap in a formatter or an external handler like a Loki/Datadog driver and the package's output follows), the publishable config, and — if the middleware is bound in the container — a subclass registered in its place. Prefer the channel-level swaps; they survive package upgrades with less churn.