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

11–20 of 60 posts

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

#11

Post by hericium »

joshka wrote: post #8
hericium wrote: post #2

Do we need lnav thread every 3 weeks?

lnav is pretty great. I wish it had a library that could be pulled out into an app instead of a terminal. There are a few things that make more sense with a GUI like standard keyboard shortcuts, filtering, saving exports, etc.

Not saying there's something wrong with lnav - just that spamming HN every 3 weeks isn't great.

There were submissions with links to lnav.org main site:

- 21 days ago

- 22 days ago

- 46 days ago

- 68 days ago

It's a spam campaign from my pov.

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

#12

Post by zulu-inuoe »

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 thoughts for a format that would generally work ootb in lnav or other log viewers?

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

#13

Post by 10987654321 »

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 finished" tag=request_finish status=200 user=brandur@mutelight.org user_id=1234 app=mutelight app_id=1234
Some more info here https://www.brandur.org/logfmt

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

#15

Post by capableweb »

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…

There is a bunch of them (log formats). I don't think any is like ISO/ANSI standarized, but many tools work with many of the different formats.

Probably the most common one (or at least was most common, maybe not anymore) would be "NCSA Common log format" (or just CLF) which looks something like this:

    127.0.0.1 user-identifier frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
https://en.wikipedia.org/wiki/Common_Log_Format

Many tools for getting analytics out of server-side logs can work with CLF and the various variations. But probably today there are more "modern" formats as well.

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

#16

Post by c0wb0yc0d3r »

LinuxBender wrote: post #5

The package is available in Alpine so I tried it out. It seems to work best if the terminal is using en_US.UTF-8. My default is C but I have a function to set UTF-8. I was curious if it could handle stdin and it does. It saves the output in ~/.config/lnav/ something to probably add to my clean up script. It is convenient that it can prepend timestamps to logs. I could see this being nice for people that do QA on buil…

I was under the impression that the shred command was pretty hard on SSDs. Did that change?

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

#18

Post by LinuxBender »

c0wb0yc0d3r wrote: post #16
LinuxBender wrote: post #5

The package is available in Alpine so I tried it out. It seems to work best if the terminal is using en_US.UTF-8. My default is C but I have a function to set UTF-8. I was curious if it could handle stdin and it does. It saves the output in ~/.config/lnav/ something to probably add to my clean up script. It is convenient that it can prepend timestamps to logs. I could see this being nice for people that do QA on buil…

I was under the impression that the shred command was pretty hard on SSDs. Did that change?

It would be as hard as writing the file {n} number of times again. So if one created a 1MB log file and then did a 3 pass wipe that would write 3MB. Number of passes would really just depend on the system being worked on. If PCI I would expect 7 passes and I am sure that would just be factored into the cost of the servers for that environment.

Shred also isn't perfect as it has no concept of the file systems journal and does not clean that data but I think it is still good practice for sensitive data, in addition to filesystem or file level encryption on systems with highly sensitive data.

With sensitive data one must look at the value of the data vs the value of the SSD. If I go out of my way to extend the life of my SSD, do I risk losing $5billion? That is how I factor in whether or not extra wear-and-tear on a SSD makes sense.

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

#19

Post by __float »

hericium wrote: post #11
joshka wrote: post #8

Earlier quoted context omitted.

lnav is pretty great. I wish it had a library that could be pulled out into an app instead of a terminal. There are a few things that make more sense with a GUI like standard keyboard shortcuts, filtering, saving exports, etc.

Not saying there's something wrong with lnav - just that spamming HN every 3 weeks isn't great. There were submissions with links to lnav.org main site: - 21 days ago - 22 days ago - 46 days ago - 68 days ago It's a spam campaign from my pov.

Do you browse new? None of these have had more than a couple points since https://news.ycombinator.com/item?id=9294622 in 2015.

It seems very reasonable that most visitors simply never saw any of those submissions.

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

#20

Post by chalst »

hericium wrote: post #11
joshka wrote: post #8

Earlier quoted context omitted.

lnav is pretty great. I wish it had a library that could be pulled out into an app instead of a terminal. There are a few things that make more sense with a GUI like standard keyboard shortcuts, filtering, saving exports, etc.

Not saying there's something wrong with lnav - just that spamming HN every 3 weeks isn't great. There were submissions with links to lnav.org main site: - 21 days ago - 22 days ago - 46 days ago - 68 days ago It's a spam campaign from my pov.

Five submissions in 70 days is rather less than a spam campaign in my view.
Post reply on HN