My biggest quality of life improvement for understanding logs has been lnav ( https://lnav.org/ ) -- does everything mentioned in this post in a single tool with interactive filtering and quick logical and time based navigation.
Tips for analyzing logs
21–30 of 136 posts
Re: Tips for analyzing logs
#22Re: Tips for analyzing logs
#231) Fuck grep, use ripgrep, especially if you have to scour over an entire directory.
2) Get good with regex, seriously, it will shave hours off your searching.
3) For whatever application you are using, get to know how the logging is created. Find the methods used where said logs are made, and understand why such a log line exists.
4) Get good with piping into awk if needed if you need some nice readable output.
Re: Tips for analyzing logs
#24Re: Tips for analyzing logs
#25cd ~/logs
cat * | grep
Re: Tips for analyzing logs
#26Re: Tips for analyzing logs
#27`journalctl -u myservice -S "5 min ago"`
Re: Tips for analyzing logs
#28A minor optimization is collapsing the grep -v, from this: cat file | grep -v THING1 | grep -v THING2 | grep -v THING3 | grep -v THING4 to this: egrep -v 'THING1|THING2|THING3|THING4' file That gets rid of the cat and three greps. Both POSIX and GNU encourage grep -E to be used in preference to egrep. A pcregrep utility also used to exist, if you want expansive perl-compatible regular expressions. This has been absor…
'pcregrep' still exists. But with PCRE2 supplanting PCRE, it is now spelled 'pcre2grep'.
I don't know the precise history of 'grep -P' and whether 'pcregrep' was actually absorbed into it, but 'pcregrep' is its own thing with its own features. For example, it has a -M/--multiline flag that no standard grep (that I'm aware of) has. (Although there are some work-arounds, e.g., by treating NUL as the line terminator via the -z/--null-data flag in GNU grep.)
Re: Tips for analyzing logs
#29My biggest quality of life improvement for understanding logs has been lnav ( https://lnav.org/ ) -- does everything mentioned in this post in a single tool with interactive filtering and quick logical and time based navigation.
At my current company, we're using pdsh with tail -f piped into sed to follow logs from multiple remote servers at the same time, label them and colorize them. Works okay. Decent solution without needing to install much other software. Not my favourite because it doesn't deal well with SSH sessions timing out and leaves some tail -f processes hanging, and some other quirks. But out of laziness and risk of breaking th…