Live data from Hacker News

Log File Viewer for the Terminal

lnav.org

1–10 of 60 posts

Re: Log File Viewer for the Terminal

#4
Oh yeah! lnav is famous. I remember using it like a decade ago to monitor an array of web servers while at GoDaddy; good ol' times.

First commit is from Sep 13, 2009: https://github.com/tstack/lnav/commit/b4ec432515e95e86ec9d71... . Woah! we’re old.

This is what the UX looked like back in the day: https://github.com/tstack/lnav/commit/bce2caa654160518ec11f6...

Re: Log File Viewer for the Terminal

#5
post #2

This is almost the thing I want and need. What I need is some sort of TUI grafana - Json log splitter/organizer/finder

I use vnlog and feedgnuplot to massage and plot data on the console all the time. It's even less than a tui, but might be what you want.

Re: Log File Viewer for the Terminal

#6
post #5
post #2

This is almost the thing I want and need. What I need is some sort of TUI grafana - Json log splitter/organizer/finder

I use vnlog and feedgnuplot to massage and plot data on the console all the time. It's even less than a tui, but might be what you want.

If you're fine with CLIs, maybe my Kelora project is worth a look. It's a very flexible log processor with built-in scripting: https://kelora.dev

Re: Log File Viewer for the Terminal

#9
I tried lnav about 7-8 years ago and as a terminal junkie I really liked the features.

The only breaking thing was a huge (almost bloated) memory consumption. At that time lnav basically just kept everything in memory. Does anyone did that change?

Re: Log File Viewer for the Terminal

#10

I tried lnav about 7-8 years ago and as a terminal junkie I really liked the features. The only breaking thing was a huge (almost bloated) memory consumption. At that time lnav basically just kept everything in memory. Does anyone did that change?

According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.

At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.

Post reply on HN