lnav

Speaking as the author, I too wish it was written in Rust. But, I started it in 2007 when I needed to get practice with C++ for work. At this point, there's so much code in lnav, rewriting would be a long process. There are some sub-components[1] that are written in Rust though. A new project called logana[2] is written in Rust and is headed in a good direction. Use/contribute to that if you're really interested. [1] - https://github.com/tstack/lnav/tree/master/src/third-party/l... [2] - https://github.com/pauloremoli/logana/

Chrome uses sandboxing and a lot of safe tooling (wuffs, rust) for untrusted data. curl is heavily fuzzed and you still mostly control what you are downloading unless the target is compromised. With logs the attacker controls what goes into your logs. And you don't need to really look very hard, there are a fair number of very recent stack and heap overflows: https://github.com/tstack/lnav/issues?q=is%3Aissue%20heap%20...

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...

Looks very useful, will give it a go. This resonates with my use of grep+less: https://github.com/tstack/lnav?tab=readme-ov-file#why-not-ju...

> - regex101 support for quickly defining custom formats is just awesome. Versioning support is slightly broken however, probably because regex101 changed something, so there's no easy way to update the format once you've initially imported it. There is a `pull` sub-command and it looks like it still works. Running the following will generate a patch file with the updated regex: lnav -m format <format-name> regex std regex101 pull It creates a patch file since the original file might've been modified. > - There are lots of different filtering capabilities, but there is no unified treatment of them. For example, `:hide-lines-before` and `:filter-out` are at their core the same type of operation: filtering. I should be able to pull up a list of all filters that are currently active and easily add new ones and toggle or delete existing

lnav is amazing and I use it often. I do have a list of gripes where I think it could be improved, so I'm just going to dump them here in case you're interested: - regex101 support for quickly defining custom formats is just awesome. Versioning support is slightly broken however, probably because regex101 changed something, so there's no easy way to update the format once you've initially imported it. - I feel like there's missing opportunity for integration between various features. - There are lots of different filtering capabilities, but there is no unified treatment of them. For example, `:hide-lines-before` and `:filter-out` are at their core the same type of operation: filtering. I should be able to pull up a list of all filters that are currently active and easily add new ones and toggle or delete existing ones. - I would expe

> I do wish there was support for switching formats so I could switch between different "views" over the same data, maybe it will be possible someday :) I created https://github.com/tstack/lnav/issues/1274 to remember this

As others have kinda alluded to, it could be useful for testing TUI applications. I develop a logfile viewer for the terminal (https://lnav.org) and have a similar application[1] for testing, but it's a bit flaky. It produces/checks snapshots like [2]. I think the problems I run into are more around different versions of ncurses producing slightly different outputs. [1] - https://github.com/tstack/lnav/blob/master/test/scripty.cc [2] - https://github.com/tstack/lnav/blob/master/test/tui-captures...

It looks like they run an SSH server inside a Docker container defined by this Dockerfile [1]. This uses the ForceCommand directive in the sshd_config file to ensure that a specific command is run when a user connects (rather than the user connecting directly to a shell). Depending on whether the user connects as the `playground` or `tutorial1` user they interact with a bash script that is either [2] or [3]; these run lnav, using the timeout command to limit how long users are connected for, and to kill the lnav process if it gets stuck. [1]: https://github.com/tstack/lnav/blob/master/demo/Dockerfile [2]: https://github.com/tstack/lnav/blob/master/docs/tutorials/pl... [3]: https://github.com/tstack/lnav/blob/master/docs/tutorials/tu...

> I also don't see something else I might want: a way to have a different "view" for certain log messages; maybe to switch between filtering/viewing particular ones, maybe to just have line-format be conditional based on the detected format. Have a look at the following comment on an issue that might be similar to what you're thinking of: https://github.com/tstack/lnav/issues/1065#issuecomment-1602... > I guess I can sort of do this based on `module-field`? but I might want it lighter-weight/finer-grained than that. Unfortunately, the "module-field" does not work for JSON logs at the moment. It's something I should really fix. Ultimately, lnav has existed for almost two decades now and I use it every day. So, it's always seeing improvements. If you're having a problem with it, file an issue on github. I don't always get around quickly

> But if some log message uses an attribute you haven't anticipated in the format definition, there's no way to see it in the pretty-printed output Properties in the log message that are not in the "line-format" are displayed below the message as key-value pairs. As an example, the bunyan[1] log format[2] has a few standard properties that are used in the "line-format" to form the main message. Then, as shown in this test[3] for this log[4], the remaining properties (even ones not mentioned in the format file) are shown underneath. > or filter on it in the UI Since they are part of the message as mentioned above, they can be filtered on. > and no ability to see it in the SQLite virtual table. The "log_raw_text" column in the table can be used to access the original log message from the file. So, you can use the JSON functions in SQLite

Valuable related discussion: https://www.reddit.com/r/devops/comments/13ab0l5/lightweight... Highlights: * Grafana and Loki seems to be favorite * https://datalust.co/seq is the easiest to deploy (single container) * https://github.com/tstack/lnav CLI based tool

Sorry for the crashes, have you sent the crash logs to support@lnav.org or opened an issue on https://github.com/tstack/lnav/issues ? I try to take a look at crash reports, but I’m not always able to figure out the issue from just the logs. If you have some time to spare in replicating the problem, I can take a deeper look.