- How do I install danielme85/laravel-log-to-db?
- Install it with Composer using composer require danielme85/laravel-log-to-db, then publish the package config and migration and run php artisan migrate. Next, register the new channel in config/logging.php and reference it from the channel or stack your application already uses. No changes to your existing Log::info() or Log::error() calls are required. Lumen needs manual service provider registration and config wiring, which is documented but less turnkey.
- Which Laravel, PHP, and Monolog versions does this log channel support?
- The package advertises Laravel 5.6 and newer, but that range spans the Monolog 2 to 3 transition and several major Laravel releases. Before adopting it, check the package changelog and CI test matrix for the exact Laravel, PHP, and Monolog versions actually exercised. Run your own staging test on the version you deploy rather than trusting the headline constraint. Treat unverified version support as an integration risk, not a guarantee.
- How do I configure the database log channel in config/logging.php?
- Add a channel entry with the package's log-to-db driver and set its connection, table, model, and minimum log level. Then either make it a standalone channel you call explicitly or add it to a stack alongside a file or stderr channel so you keep a fallback sink. Keeping the default stack intact during rollout makes the change additive and easy to reverse. Log levels and context are preserved on the stored records.
- What happens if the database write fails while logging?
- The handler's own failure behavior decides whether the entry is silently dropped, an error is thrown, or the failure recurses back into the logging path. That behavior is not something you should assume, so test it explicitly by pointing the channel at an unreachable connection. Always pair this channel with a non-database fallback such as a file or stderr channel in the same stack. This is especially important during an incident, when logging volume spikes and the database may already be under pressure.
- Does writing logs to the database slow down my Laravel requests?
- Each log event is a synchronous database round trip unless the handler buffers or queues writes, so high log volume adds request latency and database load. Keep the channel's minimum level high enough to avoid logging noise, and confirm in the code or docs whether buffering or queueing is supported and configurable. For high-throughput services, a file or stderr sink forwarded to a log platform is usually a better fit. Test under realistic volume before enabling it broadly.
- Can I send logs to a dedicated database connection to isolate the load?
- The connection is configurable, so you can point the channel at a separate database or connection rather than your primary application database. This keeps log write pressure and large payload tables away from critical transactional queries. Verify how the package resolves the connection when the app uses multiple connections, and confirm the migration runs against the right one. Isolating the connection also makes failure-handling behavior easier to reason about.
- Can I use a custom Eloquent model or table name for stored logs?
- Yes, the package lets you configure the connection, table, and model, and it ships a publishable migration you can edit. A custom model is useful if you want scopes, casts, or relationships for an admin viewer. If you change the table name, update the config and the published migration together so they do not drift. Check for collisions with existing tables before running the migration in production.
- Does the shipped migration include indexes for querying logs by level, channel, or date?
- Index coverage for real query patterns such as level, channel, and created_at is not something to assume, so review the published migration before running it. Add composite indexes that match how your dashboard or audit queries actually filter and sort. Without them, log tables grow quickly and queries become slow. Also confirm the table name is configurable and does not clash with anything already in your schema.
- How are large exception traces, context arrays, and non-UTF-8 data handled?
- Exceptions and context arrays can be large and may contain PII, secrets, or non-UTF-8 bytes, so validate column types and serialization before production use. Check whether the log message column is TEXT or LONGTEXT and whether oversized payloads are truncated or cause insert failures. Consider scrubbing sensitive context in your logging calls rather than relying on the handler. If you use the MongoDB path, treat it as a separate compatibility surface with its own driver dependency.
- Is there built-in log retention or pruning, or do I have to manage it?
- Retention is typically something you own: schedule a pruning command or job that deletes rows older than your policy window. Database-backed logs grow fast, and an unmanaged table will eventually affect query performance and backups. Confirm whether the package ships any pruning command before building your own. Pair pruning with the indexes on created_at so deletes stay cheap.