Log Viewer after 2 months

It has only been 2 months since the Log Viewer was launched to the public as an Open-Source log viewer for the Laravel framework. I did not think much of it in the beginning – maybe it would help 10-20 developers make their life easier, including myself, but the response was much more significant that I expected.

Quick stats so far

• 1,900+ stars on GitHub
• ~65,000 installs
• 64 Pull Requests made (24 of them made by contributors other than me)
• 28 issues closed (fixed or explained as non-issue)

Not only did the package receive a lot more love than I imagined, it also received contributions from the community to make it better! Thank you all, bravo 👏

New features

I have a limited amount of free time – usually Fridays and weekends – to contribute to this project. The attention this package got definitely kept me going and wanting to improve it even further. I also had tons of fun working on it!

I had some cool ideas for features that no other log viewer for Laravel does. So, for the last 2 months, Log Viewer has been my primary focus during my free time and together with the community we’ve built some cool features 🤓 Here’s a quick look at them.

Dark Mode

Although this hasn’t shipped with the initial version of the Log Viewer, it quickly became the number one requested feature. Who could’ve guessed, right? 😅

I believe one of the first community PRs was to add a Dark Mode. Log Viewer is a tool for developers – it needs a dark mode.

You can also choose a System theme, which will switch between Light/Dark mode based on your system preferences. That is set by default.

Improved severity selection

The new dropdown design of selecting log severity levels is much more space-efficient, leaving room for other features later. It now also shows the total count of logs found.

Log groups (folders)

If you include logs from multiple places, you will see them grouped in the UI. Expand/collapse, as well as perform any actions (download, delete, etc) on the groups – just like regular log files.

It is not based on the glob patterns defined, but rather the actual folder the logs are in. If multiple patterns resolve to the same folder – those log files will still be grouped under the same group.

On unix systems, the user’s home path will be replaced with a tilde ~ character for a cleaner design.

Searching across all files

Another heavily requested feature, as voted in the Twitter pool.

This comes useful especially if you use the daily log driver, which creates a new log file every day. If you’re looking for something, you may not know what day it happened, or what log file it is in.

Here’s how it works:

• If you have selected a log file – it will search that log file only.
• If you have not selected any log file – it will search across every log file known to Log Viewer.

In case of a global search, sometimes it may take a while if you have gigabytes of logs across hundreds of log files. For this purpose, there’s a progress bar that will update you on the search’s progress:

Chunked log indices

The way the Log Viewer is faster than other log viewers for Laravel is by indexing the logs first before viewing them. Once we know the timestamp, severity, and the position in file for each log, we can paginate over them much more efficiently – in milliseconds in fact.

Previously, when working with large log files (more than 1 million logs inside a single file), the Log Viewer’s index could grow really big (reaching well over 100 MB in size for a multi-dimensional array in PHP) and thus increasing the memory usage for each request.

While it’s not very common to have huge log files, especially using the daily driver, it can still happen – you might get an infinite loop going on writing millions of logs, or an external service might be down during the night causing hundreds of thousands of exceptions. You don’t want to lose any of that. Your log files should be readable and accessible no matter the size.

So, in favor of an even higher scalability than previously available, I’ve rebuilt the indexing engine to split a single large index into smaller, more manageable chunks.

A single 1 GB log file might be indexed with ~200 small chunks stored in the cache. Once we know what severity levels you’re interested in, and what page you’re currently on – we can figure out the exact chunk to pull and read from. Notice the memory usage when browsing a 1 GB log file – it’s only 6 MB! That’s the beauty of not loading the full log file into memory every time you read it.

What’s next?

So, what’s next on the roadmap?

There’s still a number of features I’d like to build into the Log Viewer, namely:

• Date filters. With the global search now available, it makes perfect sense to limit your search to a particular date range. Not only would it be faster, but also give you only the results you need.
• Mobile-friendly UI. I have underestimated the amount of developers checking their logs on-the-go. I never do that myself, so I did not think much of it. It was a “nice to have” feature that I did not prioritize for the first release.
• Custom Log Parsers. You most likely have logs other than just Laravel. Apache/nginx, MySQL/PostgreSQL, Supervisor, and so on. There are many more logs that you might need to read for debugging. Wouldn’t it be nice if all of these logs could be viewed in the Log Viewer?

If there’s another feature you’d like to see as part of the Log Viewer, be sure to check our GitHub Discussions page where you can upvote existing feature requests or suggest your own!

You can also open up a Pull Request with your feature implemented – I welcome all code suggestions and improvements and would love your help to make the Log Viewer even better.

Don’t forget to visit the Log Viewer’s GitHub page and ⭐️ star it!

If you’d like to know more about what I do, subscribe to the mailing list here and follow me on Twitter – https://twitter.com/arukomp

Thank you to all the contributors and supporters, I appreciate you all!