Open robbieaverill opened 7 years ago
I would rather use a log-parser to parse the actual logs, than putting these into the database. Although a DB served log entry is faster, it serves no purpose to re-store things and pollute the database with access entries.
Parsing the logs is easy enough and the speed difference is minimal. After all, it's a CMS thing, not something that affects the frontend user!
Yeah @Firesphere - I don't see much point in parsing system logs and saving them as LogEntry records in this module - best to merge into the grid field as they're read from file
I would thing, only using warning+ to show up and an option in the config to set the logging level and parsing.
https://github.com/kassner/log-parser looks promising (although that's a quick look, not in-depth)
https://github.com/kassner/log-parser looks promising (although that's a quick look, not in-depth)
Would tie nicely into #13
Good spot! Also, you're clearly more awake than I am :P
An idea that surfaced on Slack recently - to include handling for apache/nginx/PHP/FPM error logs in this module.
Presumably they wouldn't be
LogEntry
instances in the database, and would not be able to be deleted, but should be able to be viewed in the grid, and in detail.