Ngtop – Request analytics from the Nginx access logs | Hacker News Reader

Ngtop – Request analytics from the Nginx access logs

github.com

120 pointsfacundo_olano20 comments

Goaccess (https://github.com/allinurl/goaccess) does this in real time and has been very stable for well over a decade.

Found it much easier to just used structured logs and slice them with [angle grinder](https://github.com/rcoh/angle-grinder)

Recently discussed 3 months ago:

https://news.ycombinator.com/item?id=41115128 (11 comments)

Your link is to the current thread...

Oops, here is the correct link:

https://news.ycombinator.com/item?id=40195557

Thank you for letting me know

This is cool. I just installed goaccess and was using that to look at the nginx logs but this is also neat. I like post-hoc analysis of these things rather than injecting JS just because it's easier for me to manage for my personal sites. Thank you.

What is the simplest solution to access nginx log? Could it be setting an endpoint(behind simple user/pass) that echos the content of the log?

a decent syslog daemon will stream it anywhere you like

ssh is the simplest

for exporting nginx logs elsewhere, vector.dev is nice. can send to dozens of places. can parse user agent string, and do ip geocoding too

Thanks, but I want to access the log through browser though.

Is there something like logwatch that could send me a digest of all 404s, 500s etc.?

ngxtop is also very useful for providing real-time metrics:

https://github.com/lebinh/ngxtop

Too bad the maintainer stopped responding to or accepting pull requests…lot of PRs open for 10 years, including mine

Pick a slight variation on the name, look through the unmerged upstream PRs to find some "obviously good" ones (or to fix other deficiencies you noticed personally), merge them to your fork, and who knows ... your fork might become the next popular home of the project!

Unless you're pushing to the same GitHub account / group, you don't even have to change the name.

Did you consider maintaining a fork? Because it looks nice indeed.

This looks great. I wrote my own “counter” for my personal sites but I haven’t developed it a lot more. This probably makes more sense.

I used something similar in the past for website analytics but came to realize that javascript based tracking is more useful for my use case of understanding how people use my website.

JS tracking leaves out most bots as well. They were a nuisance with this method.

It is not for production use because:

"Whenever the program is run, it looks for the nginx access.logs, parses them and stores the data into an SQLite DB. " ... "The command line arguments express a filtering criteria, used to build the SQL query that counts the requests."

Why does that exclude it from production use?

Reply on news.ycombinator.com