This is why I recommend switching to HAProxy.
[1] https://www.haproxy.com/products/haproxy-enterprise-edition/
We're running v1.4 in production and it has been working pretty nice for us.
You should post the issue on their https://github.com/allinurl/goaccess, they may be able to help you.
Regarding the branding, for me top is a real-time tool rather than a logging tool. I was picturing something that may have been more useful for older style Apache httpd installs where you have several virtual hosts on a server and you'd want to know who is hogging the resources or causing the problems.
watch bash -c "topngx < /path/to/access.log"
Averages can lie, especially when something like an empty query can take close to zero time compared to a non-trivial transaction. If some robot or other artifact of your site is generating a some amount of null queries that will make your average response time look better than it actually is. Percentiles, particularly on the tail of 90th or above, tell a better story of how well and consistently you're responding to traffic under load.
And ofcourse there is another problem of correctly storing all your latencies accurately which becomes pretty hard if you are using something like prometheus.
EDIT:
1# I'm gonna compile it and provide a screenshot via a pull request.
2# Compilation failed because it needed sqlite3 headers and this is not reported in the app. I'm gonna edit that in the readme too :)
This year (specially with the whole covid thingy) I set a goal to contribute more to open source. I'm trying to find every little issue I can find and contribute to :P
Which presumably means those metrics are available in the OSS edition somehow...
https://nginx.org/en/docs/http/ngx_http_stub_status_module.h...
Anyone know if there's a "deeper" way to get the same stats info about what Apache is doing without having to basically wait in line with all the other incoming requests?
Why make a whole new tool with limitations instead of improving the existing one?
What world does this guy live in that a program in Rust is easier to get running on any random machine than python script?
Distributing single binary would be easier, but `cargo install xyz` seems harder than python script