-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add additional reverse proxy setup metrics from Varnish logs #190
Comments
Meant to documenting the log format, but close the set of windows that had the comment, now redone. ;-) Items of interest might be object cache hits, age and maybe how often same items are missed, or fall out of the cache. Log Output:
Log Format:
|
I have a branch that I've been experimenting with, it allows users to add custom metrics to certain panels, though, I must say that allowing custom panels/modules might be ideal. Please keep this open so I can look into it in more detail. Also, can you expand on how some of the items of interest should get displayed, e.g., a metric within a panel, new panel? |
Really not sure how it would be best displayed, thinking about metric that would be useful to me. Some of the metric don't provide info all the time, so I might need to expend the logging to add a metric, so that reports can be more accurately displayed. URL's sorted with highest cache hit rate, miss rate. Another would be to sort URL by Age? Not sure how to represent the data, but resources with return code 200 comes out of cache, verse return 304 would be client side cached, yet unchanged. URLs with columns for return code count? ie ...
I have a few other ideas, about time to server and time from backed, but not sure how much info you might be looking for. I have a few logs that might be worth sending offline that could give you more insight? |
Thanks for posting this in. I still think this should be configured at the user level. However, it definitely adds a good level of complexity since metrics would need to be defined by the user. The other option is to hard-code them if they are pretty standard. Are you looking to display these metrics on the request panel only? or could they go somewhere else too? It's also worth mentioning that adding more metrics would increase the parsing time and memory consumption. Feel free to post any other ideas... Thanks. |
Thank you for entertaining some of our crazy ideas. And a bigger thank you for time spend on goaccess!! Been able to create custom metrics at a user level would make goaccess even more useful tool, but I can see how that could get out of hand. Something I like, is the easy with which I can use and of late, make reports with. Above counters would make sense in the request panel as extra columns.. Any additional code/complexity/metrics would require more resources, which seeing that I am the only person interested in these added metric, might not be worth extra resources for all users? |
Having a reverse proxy in front of a web server, means that your reverse proxy would have more accurate visitor details compared to your web server, unlike #78, I have details that would be interesting to see per url, like the number of cache hits, age, times.
The text was updated successfully, but these errors were encountered: