- How do I install juststeveking/eloquent-log-driver in a Laravel app?
- Install it with Composer using composer require juststeveking/eloquent-log-driver. Then publish the package's config stub and migration with php artisan vendor:publish and run php artisan migrate to create the logs table. Finally register the channel in config/logging.php and point LOG_CHANNEL at it. Because the last release is from 2020, test the install on your exact Laravel and Monolog versions before rolling it out.
- Does eloquent-log-driver work with Laravel 10, 11 or 12?
- Not reliably out of the box. The last release was 2020-11-04, aimed at the Laravel 8 era, and five Laravel majors plus Monolog 3 have shipped since with no compatibility test matrix. The most likely outcome on a current stack is a hard failure at channel instantiation or the first write, because Monolog 3 changed the handler signature. Verify in a spike and budget a patch rather than assuming it works.
- How does eloquent-log-driver actually store logs?
- It is a Monolog handler plus a LogManager extension registered by a service provider, shipped with a publishable config stub, a migration, and an Eloquent model. When you route a channel through it, a call like Log::info becomes an INSERT against a logs table with a row per record and a JSON context column. There is no viewer, search index, alerting, or access control, so you query the table through Eloquent like any other model.
- How do I configure the eloquent log channel in config/logging.php?
- Add an entry to the channels array in config/logging.php using the package's driver name, mirroring the stub the package publishes. Then set LOG_CHANNEL, or the stack you use, to that channel so traffic routes through the handler. Blast radius is limited to the channels you explicitly route through it, so you can keep file logging for everything else.
- Is eloquent-log-driver safe for high-traffic production applications?
- Generally no. Every record is a synchronous, unbuffered, unbatched database round trip on the request or queue-worker path, which is a direct latency tax visible at p99 under load. It also puts logging on the primary database's write path, sharing connection, CPU, disk, and failure domain with business data. It is defensible for low-volume, single-tenant, queryable application events like failed webhook deliveries or auth anomalies, and indefensible for high-throughput APIs or multi-service estates.
- Does eloquent-log-driver handle log retention or pruning?
- No. The package does not ship retention, pruning, or partitioning, so a row-per-record table with a JSON context column accumulates unbounded. You have to own cleanup yourself, typically a scheduled job that deletes or archives old rows, plus an index and partitioning strategy if volume grows. Plan for that before enabling the channel, not after the table is large.
- Does eloquent-log-driver redact PII or sensitive data before saving?
- No, there is no redaction hook. The JSON context column will capture request payloads, headers, tokens, and user identifiers unless you intervene, for example by sanitising context before logging or by choosing which channels and log levels route to the driver. If you need PII scrubbing before persistence, that is something you must build yourself. The package provides no access control either, so anyone with database access can read the logs.
- What happens to eloquent-log-driver if the database goes down?
- Logging failures can cascade. If the database is the failure domain, the handler can throw while writing, and unguarded that destroys diagnostics precisely during the incident you most need them for. You need a fallback channel and explicit circuit-breaker behaviour, such as a stack with a file or stderr sink, and code that swallows write failures. Treat this as a prerequisite before production use.
- Why does eloquent-log-driver break on Monolog 3?
- Monolog 2 handlers implement write(array $record), while Monolog 3, used by Laravel 9 and later, expects write(LogRecord $record): void. The handler in this package was written for the Monolog 2 signature and has not been updated since 2020. The fix is small, updating the signature and any record-access calls, but you own that patch and its maintenance. Confirm the exact diff on your versions in a spike before deciding to depend on it.
- What are the alternatives to eloquent-log-driver for database logging in Laravel?
- Options include Laravel's built-in single, daily, stack, and stderr channels, Monolog handlers for database or external services, and third-party sinks like Papertrail, Sentry, or a log aggregation service. Building it yourself is also viable: the package is roughly 150 lines, and the pattern of a custom channel registered through the LogManager is worth copying even if the code is not. Decide first whether the requirement is an audit trail, which is retained, access-controlled, and actor/subject oriented, or diagnostics, which are high-volume and ephemeral, because a database sink only fits the former at modest volume.