Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lnav – An advanced log file viewer for the small-scale

lnav.org

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Lnav – An advanced log file viewer for the small-scale

#41

Post by tobylvp »

tstack wrote: post #37
tobylvp wrote: post #9

For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.

I'm the author of lnav and had never heard of logviewplus before, thanks for mentioning it. It looks like we've independently arrived at a very similar feature set, that's pretty neat. I will now shamelessly steal some of your ideas :)

It looks like you have done a great job with lnav - it's impressive. I know how much work has gone into LogViewPlus and you must have made a similar commitment. I thought I was the only one crazy enough to want to solve this problem. :-)

I would be happy to chat to a like mind if you are interested. You can contact me here: https://www.logviewplus.com/contact.aspx

Steal away! :-)

Re: Lnav – An advanced log file viewer for the small-scale

#42

Post by winter_blue »

tobylvp wrote: post #9

For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.

Is LogViewPlus heavily tied to Windows? How hard would a port to Linux be?

I love that so many Windows tools get a nice-looking GUI, versus a heavy CUI lean to *nix tools.

Re: Lnav – An advanced log file viewer for the small-scale

#43

Post by kcbanner »

tobylvp wrote: post #9

For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.

I've been using https://glogg.bonnefon.org/. The mark / matches feature is really handy. However there are a few bugs with highlighting and it hasn't been updated in a while. Will have to check this out!

Re: Lnav – An advanced log file viewer for the small-scale

#44

Post by tobylvp »

winter_blue wrote: post #42
tobylvp wrote: post #9

For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.

Is LogViewPlus heavily tied to Windows? How hard would a port to Linux be? I love that so many Windows tools get a nice-looking GUI, versus a heavy CUI lean to *nix tools.

As things currently stand - hard. LogViewPlus is written in .Net using WinForms, so it is heavily tied to Windows. However, Microsoft is evolving. The bulk of the code can now be made to be cross-platform easily, but the front-end remains a problem.

I would love to do a Linux port as soon as there is a viable cross-platform GUI technology with strong 3rd party vendor support. The controls in LogViewPlus are very rich.

Re: Lnav – An advanced log file viewer for the small-scale

#45

Post by tobylvp »

kcbanner wrote: post #43
tobylvp wrote: post #9

For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.

I've been using https://glogg.bonnefon.org/ . The mark / matches feature is really handy. However there are a few bugs with highlighting and it hasn't been updated in a while. Will have to check this out!

Glogg is a great tool. We take a bit of a different approach in that we parse the log file. This enables some more in-depth features such as SQL reporting. We also support remote file access (for example, SFTP).

Let me know if you have any questions or feedback. You can reach me on the contact page of the site.

Re: Lnav – An advanced log file viewer for the small-scale

#46

Post by sgc »

electroly wrote: post #34
LinuxBender wrote: post #32

Earlier quoted context omitted.

I've also seen people say that and to instead use "blkdiscard -sz" but that also does not write to specific blocks. I still can not find a definitive source saying that shred is not able to write to specific blocks on a SSD and it is not clear to me that wear leveling actually prevents shred from writing to specific blocks. But I agree that I have seen people say this repeatedly on StackExchange, ServerFault and Redd…

Wear leveling prevents anyone from writing to specific blocks. It decouples the OS's block numbering from the physical blocks. That indirection allows it to distribute writes evenly across the drive even if the OS is writing to consecutive blocks (or the same block). This behavior is fundamental; it's what wear leveling is and why it exists. Wear leveling exists to prevent you from writing to the same block repeatedl…

Does that mean that partitions on an SSD therefore do not affect the long term wear on the SSD?

Re: Lnav – An advanced log file viewer for the small-scale

#47

Post by zulu-inuoe »

10987654321 wrote: post #13
zulu-inuoe wrote: post #12

Say I'm building a logging library, is there any sort of generally agreed-upon standard per what a log file should look like? I know there's several formats that lnav supports, but I'm not familiar with them. I've always had trouble before figuring out what a good compromise between log format and flexibility looks like. Especially wrt newlines in the log message itself (eg if I want to log a stack trace) Any thought…

Not sure about lnav but most log aggregation systems support json and logfmt-formatted logs, and there are many standard logging libraries that supports emitting those formats Of those json is better if you want to be able to do more advanced stuff (nest dictionaries, use lists, ...) and logfmt is better if you want to have human-readable logs without external tools as well, an example line can look like msg="Request…

Thank you! Now when you say json logging, are there any common patterns you can guide me to look at? Just looking around for JSON logging gives me results like [1] which talk about JSONL (object per line, presumably JSON serializer makes sure to not emit literal newlines).

But some other places describe this a bit more liberally. And [2] notes that I should include a time stamp in each log entry which makes sense.

[1]: https://stackoverflow.com/questions/10699953/format-for-writ... [2]: https://www.papertrail.com/solution/tips/8-essential-tips-fo...

Re: Lnav – An advanced log file viewer for the small-scale

#48

Post by tstack »

Thaxll wrote: post #39

I mean if the goal is to read logs the default color scheme looks pretty bad, why there are so many colors in the example? For example the http 403/404 is red but it does not stand out. Also why a 404 would be red in the first place.

> why there are so many colors in the example?

Identifiers, like process-names/pids/IPs, are semantically highlighted by default to make it easier to visually match up values that are the same. And, it's this way because I like it this way, so that's the default.

> For example the http 403/404 is red but it does not stand out.

To me, the red stands out. But, I would also have a much wider window, so the red would stand out even more with the rest of the text.

> Also why a 404 would be red in the first place.

Because 4XX are error codes.

Of course, lnav is pretty customizable at this point, so you can adjust it to your liking. The theme can be changed to something less colorful and the log format definitions can be patched to change their behavior.

Post reply on HN