Laravel Logging Laravel Package

Getting Started

This package is essentially undocumented in public signals (no stars, no dependents), so treat it as a small internal-style utility you must read before you trust. The description — "Enrich laravel logging" — places it in the Monolog processor / log-context category: adding request IDs, user identity, tenant, environment, or timing data to every log line.

Minimal path:

1. Install and inspect in one pass.

   composer require eur-rsm/laravel-logging
   

   Before writing any code, open the vendor directory and read, in this order:

   • composer.json — the extra.laravel.providers / aliases block tells you whether auto-discovery registers anything, and the require block tells you which Laravel and Monolog versions it actually supports.
   • src/ — the service provider is the map of the whole package. Anything it binds, extends, or taps is the entire surface area.
   • config/ — if a config file is published, it is the real documentation.
   • README.md — often thin; skim last, not first.

2. Publish whatever is publishable.

   php artisan vendor:publish --provider="EurRsm\Logging\LoggingServiceProvider"
   

   Confirm the actual namespace from composer.json autoload before running this. If nothing publishes, the package is likely configured entirely through config/logging.php.

3. Look at config/logging.php first use case. The overwhelmingly likely integration point is the tap key on a channel, which Laravel passes to Monolog's pushProcessor:

   'daily' => [
       'driver' => 'daily',
       'path' => storage_path('logs/laravel.log'),
       'level' => env('LOG_LEVEL', 'debug'),
       'tap' => [EurRsm\Logging\Processors\EnrichLogs::class],
   ],
   

   Treat the class name as a guess until you've read src/. If the package ships its own channel driver or formatter instead, the provider's extend() call will name it.

4. Verify with a single line.

   Log::info('enrichment smoke test');
   

   Then tail -f storage/logs/laravel.log and confirm the extra keys appear. If they don't, you're not on the channel you think you are — check LOG_CHANNEL and any stack channels.

If the repo turns out to be a stub or abandoned (0 dependents is a warning), the fallback is 20 lines of your own: a Monolog processor in a tap, registered in AppServiceProvider. Do not block a sprint on a package you can replace that cheaply.

Implementation Patterns

Attach enrichment per-channel, not globally. Enrichment that includes user or tenant data is wasted — and risky — on queue workers, scheduler output, and CLI commands. Define a dedicated channel and route only what needs it:

'enriched' => [
    'driver' => 'daily',
    'path' => storage_path('logs/enriched.log'),
    'level' => 'info',
    'tap' => [/* enrichment classes */],
],

Then use Log::channel('enriched')->info(...) or push it into a stack and let the noisy channels stay lean.

Context-passing over magic. Whatever the package auto-detects (request ID, authenticated user, IP), it will only see what's available at log time. For jobs and console commands, bind the context yourself before dispatching:

// In middleware or a job's constructor
Log::withContext([
    'request_id' => (string) Str::uuid(),
    'user_id' => auth()->id(),
]);

If the package exposes its own context setter, prefer it so the key names stay consistent with what its processor writes.

Correlate across the request/queue boundary. The high-value workflow: generate a correlation ID in middleware, stash it in a scoped container binding or Context, and re-hydrate it in queued jobs from a job property. Without this the enrichment only helps you in synchronous HTTP paths, which is where you least need it.

Wrap it behind your own abstraction if you plan to keep it. If the package provides a facade or helper, use it. If it only provides processors, register them via tap and let your application code call plain Log:: — that keeps the dependency at the config layer, where removing it is a one-line diff rather than a find-and-replace.

Pair with structured output. Enrichment is only useful if you can query it. Combine with a JSON formatter or send to a collector (Papertrail, Loki, Datadog) via a Monolog handler. Enriched key/values inside a plain-text line are effectively unqueryable.

Gotchas and Tips

• Monolog processors see everything on the channel — including framework noise. A processor on your main channel will stamp user IDs onto deprecation notices and vendor warnings, bloating the log and sometimes leaking identifiers into third-party error reports. Scope tightly.

• Serializer failures on context. If enrichment injects models or objects rather than scalars, json_encode in the formatter can throw or silently drop the field. Force (string) / (int) casts in any processor you write or configure.

• PII and secrets. Auto-detected user identity, request bodies, or headers in logs is the most common way packages like this become a compliance problem. Audit exactly which keys the processor adds before it goes anywhere near production, and confirm whether the package redacts Authorization/password fields — assume it does not until you've read the code.

• tap runs per channel, and stack channels multiply. A processor tapped onto a stack applies once, but tapped onto three channels in a stack applies three times if you also tap the stack. Pick one level.

• Silent failure mode. A processor that throws takes down logging itself, and logging failures are often swallowed by Laravel's error handling — you get missing logs, not an exception. Guard processor bodies in try/catch and fail open.

• Config caching. After publishing or editing config in a deployed environment, php artisan config:cache is mandatory. A processor that resolves env vars at runtime rather than config time will behave differently once cached — a classic stale-context bug.

• Octane and long-lived workers. Static state, memoized user IDs, or singletons holding request context will bleed between requests. If you deploy under Octane, verify the processor resolves context per-log-call, not at construction.

• Version pinning. With no dependents and no release signal, constraints may be loose (^1.0 against an unreleased branch). Pin exactly, and vendor-review the source before any composer update. If it's a single-maintainer package, consider forking the processor into app/Logging/ — the code is almost certainly small enough that ownership is cheaper than dependency risk.

• Extension point to prefer. Laravel's own Log::withContext() and tap cover ~90% of "enrich logging" needs. If the package's value is only that, skip the dependency and use the framework primitives. Reserve the package for genuine extras — formatters, redaction, multi-handler routing — that you'd otherwise write yourself.