- How do I install kassner/log-parser in a Laravel application?
- Install it with Composer as a normal PHP dependency; it is not a Laravel-specific package, so there is no mandatory service provider or migration to run. In a Laravel app you typically bind it behind a small internal service or adapter class registered in a service provider, then inject that adapter into commands or queued jobs. Because it is framework-agnostic, keep the package namespace out of your domain code and expose only normalized DTOs from your adapter. That keeps the dependency replaceable if upstream maintenance stalls.
- What exactly does kassner/log-parser parse?
- It reads log files and turns each entry into a structured object exposing the entry date, PSR-3 level, description or message, and context data. It is designed to handle multi-line entries such as stack traces so an exception does not get split into several unrelated records. It is a parsing component only: it does not ingest, store, index, search, rotate, or alert on logs. Treat it as one narrow stage in a larger log pipeline.
- Does kassner/log-parser support PSR-3 log levels?
- Yes, entries are surfaced with PSR-3 severity levels such as emergency, alert, critical, error, warning, notice, info, and debug. That makes it straightforward to map parsed levels onto your own enum, database column, or monitoring severity scale. Map the levels explicitly in your adapter rather than relying on raw strings, so a format change cannot silently break filtering or alerting downstream.
- Can I filter log entries by level or date while parsing?
- The library supports filtering so you can select entries of interest instead of materializing everything. Typical use cases are pulling only errors and criticals for a dashboard, or restricting a backfill to a specific date range. Combine parser-level filtering with chunked reads and queued jobs for large files, and always keep the raw line available for rejected or unparsable records. Persist a normalized record plus the original line so you can re-process after a parser upgrade.
- How does it handle multi-line stack traces and exceptions?
- Multi-line entries such as exception stack traces are kept together as part of the owning entry rather than being emitted as separate malformed records. This is important because naive line-by-line parsing fragments traces and destroys their diagnostic value. Still, validate against real samples from your application, since custom log formatting, JSON context, or unusual indentation can change how a multi-line block is detected. Keep a regression corpus of representative traces and assert on it in CI.
- Which PHP and Laravel versions are supported?
- The package is not Laravel-specific, so Laravel version coupling is low risk, but you must still check its Composer PHP constraint against your runtime and CI matrix. Add an integration test that parses sample logs inside your application so a PHP upgrade or dependency bump fails loudly rather than silently. Since the last release was in July 2023, verify compatibility with your current PHP version before adopting it broadly. Pin the dependency version and re-test on every PHP upgrade.
- Is kassner/log-parser a complete log management solution?
- No. It is a parser, not a platform: there is no ingestion pipeline, storage, indexing, search, alerting, rotation handling, or retention policy. If you need those capabilities out of the box, look at full log platforms or managed services instead. Where it fits well is as a commodity component inside a Laravel pipeline you already own, feeding structured records into your own database, object storage, or analytics layer.
- Will it perform well with large or high-volume log files in production?
- Parsing is CPU-bound, so scale horizontally with queue workers and process files in streams or chunks rather than loading whole logs into memory. Enforce backpressure, isolate failures per file or chunk, and route malformed lines to a dead-letter path so one bad record cannot stall a batch. Avoid calling the parser directly in HTTP request paths; run it from scheduled commands and queued jobs. Benchmark against representative production samples, including worst-case long lines, before committing to throughput targets.
- Is kassner/log-parser actively maintained, and what is the licensing risk?
- The license is Apache-2.0, which is commercially acceptable, and adoption is real but niche. The last release was July 2023 and repository provenance is not clearly documented in your evaluation context, so treat maintenance health as a moderate risk. Pin the version, track PHP security updates, and keep the parser behind an internal interface so you can fork or swap it without touching domain code. Assign explicit ownership for parser failures and format drift.
- How should I integrate and test kassner/log-parser in a Laravel codebase?
- Wrap the library in a single LogParserService or adapter that returns normalized DTOs, bind it in the container, and invoke it from an artisan command or queued job that reads files from local disk or S3. Start with a discovery spike on representative production log samples, define the normalized record contract and validation rules, then backfill historical logs and reconcile output against your current approach. Maintain a corpus of real log samples covering IPv6, escaped quotes, timezone offsets, line-ending variants, and compressed inputs as regression tests. Keep the legacy path available until validation metrics are clean, then schedule ongoing ingestion with metrics and dead-letter handling.