Logs Laravel Package

Technical Evaluation

Architecture fit The package addresses a genuine gap: routine-level tracing plus SQL query capture is precisely the layer where Laravel applications are least observable out of the box. Laravel's native Log facade captures application events but not query execution; DB::listen exists but requires hand-rolled wiring. If litermi/logs packages that wiring into a service provider with publishable config, it occupies a legitimate cross-cutting concern in the framework's bootstrapping layer — no intrusion into domain code, which is the right architectural placement for an observability utility.

That said, the capability overlaps almost entirely with laravel/telescope (query watching, request tracing, slow-query detection) and barryvdh/laravel-debugbar for local work. The package must justify itself on footprint, production-safety, or log-format ergonomics rather than on capability alone. It also overlaps with plain structured logging via Monolog channels. The TPM question is not "does it work" but "what does it replace, and is that replacement cheaper to own."

Integration feasibility Mechanically trivial: composer require, Laravel package auto-discovery, optional php artisan vendor:publish for config, env flags to toggle. A competent Laravel engineer can have it emitting logs in an afternoon. The real effort is not integration — it is validation. With zero stars, zero dependents, and no score, there is no external evidence that the package has ever run in a production application other than its author's.

Technical risk

• Adoption signal is absent. Zero dependents and zero stars means no community code review, no Stack Overflow corpus, no downstream bug reports. Every defect is yours to find.
• Bus factor of one. Single-owner repositories with no release history imply no deprecation policy, no security disclosure path, and no guarantee of a response to a CVE or a Laravel major-version break.
• Sensitive-data exposure. Query logging captures bound parameters. Passwords, tokens, session identifiers, and PII can land in plaintext log files. This is the single largest risk and must be assessed before any non-local deployment.
• Runtime overhead. A global DB::listen callback executes on every query. On query-heavy endpoints this is measurable, and naïve implementations buffer queries in memory until flush.
• Recursion hazard. If the package writes logs to the database, the write itself emits a query, which the listener captures. Whether the package guards against this is the first thing to verify in code.
• Unverified version constraints. PHP and Laravel support ranges are unknown; a package written for Laravel 8 may silently misbehave on 11.

Key questions

1. What are the declared composer.json constraints for PHP, illuminate/*, and Laravel major versions? Are they accurate or aspirational?
2. Does it redact or truncate bound parameters, and is redaction configurable per-key?
3. Is there recursion protection for database-backed log channels?
4. Is query capture sampling-capable, or all-or-nothing?
5. Is there a tagged release, a CHANGELOG, and a license compatible with commercial use?
6. Does it hook DB::listen, the query log, or middleware — and does it behave correctly under Octane, queued jobs, and multiple connections?
7. Who maintains it, and is there any stated support commitment?

Integration Approach

Stack fit Assume a standard Laravel application on PHP 8.x with Monolog channels already configured. The package should be treated as a log producer, not a logging stack — it must write into existing channels rather than introduce its own transport. If it insists on its own storage table or file path, that is a design smell and a retention-policy problem you inherit.

Migration path Do not adopt directly. Two viable paths:

• Preferred: treat the repository as reference implementation. Reproduce the query-tracing behavior with a first-party DB::listen listener (~50 lines) bound to your own config and redaction rules. Zero dependency, full control, no vendor risk.
• Acceptable: adopt behind an internal adapter — a thin first-party service that calls the package — so the package can be swapped or forked without touching call sites. Fork into a private VCS if it survives evaluation.

If Telescope already exists in the stack, the correct decision is usually to use Telescope's query watcher in non-production and structured logging in production, and to take no new dependency at all.

Compatibility Verify package discovery registers cleanly, that the config file publishes without collision, and that it does not register global middleware or override the default log channel. Test explicitly under Octane (long-lived workers retain listener state), under php artisan queue:work, and with more than one DB connection configured.

Sequencing

1. Spike (1–2 days): read the source. Confirm recursion guard, redaction, and version constraints. If any is missing, stop.
2. Local/CI only: enable, inspect emitted payloads for secrets and for query volume per request.
3. Staging, sampled: 10% sampling, measure p95 latency delta and log ingest volume.
4. Production: only with redaction enforced, sampling on, a dedicated channel with retention limits, and a kill switch via env flag.
5. Review at 30 days: keep, fork, or replace with first-party listener.

Operational Impact

Maintenance Ongoing cost is low in code and high in ownership. Pin the exact version, disable automatic minor upgrades, and budget for a fork the moment a Laravel major release lands. Treat the fork as the expected steady state, not the contingency — with one maintainer and no release cadence, you will eventually own this code.

Support There is effectively no support tier. No SLA, no issue-triage history, no security contact. Escalation path is "read the source." Acceptable for a dev-only tool; unacceptable for anything on the production critical path without internal expertise to debug it.

Scaling Log volume scales with query volume, not request volume — a page issuing 400 queries multiplies ingest cost accordingly. Requires sampling, parameter truncation, per-environment channel routing, and a hard retention window. Without sampling, this package can double or triple log spend on a query-heavy service.

Failure modes

• Disk exhaustion from unbounded query logs on a high-traffic service.
• Credential leakage into log files and downstream aggregators — a compliance incident, not a bug.
• Recursive logging if the log channel writes to the database, producing runaway query amplification.
• Latency regression on hot paths from the per-query listener.
• Silent breakage on framework upgrade, with no upstream fix forthcoming.

Each needs mitigation before production: sampling, redaction config, a non-database log channel, a load-test gate, and a version-pin policy.

Ramp-up Installation is an hour. Understanding what the output means, and building the runbook for redaction rules, retention, and the disable switch, is a one-to-two-day effort for one engineer. That engineer becomes the de facto owner — plan for that person to be identifiable and retained.

Recommendation: Do not adopt as a production dependency in its current state. It is a useful reference for building a first-party query-tracing listener, and the cost of that alternative is roughly one engineer-day. Adopt the package only if source review clears the recursion, redaction, and version-constraint questions, and then only behind an internal adapter with a pinned version.