-
Notifications
You must be signed in to change notification settings - Fork 89
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
Enable web site log analysis #346
Comments
Assuming it doesn't involve scripts / cookies / tracking pixels on the client-side — IOW it's based on server logs —, this seems useful to get a picture of what's consumed from the website. |
I honestly can't see how origin logs would have helped for these problems. It would be better with some sort of scan/verification of the content. |
If it could be counting e.g. curl-for-win downloads on any timescale, without any other parameter, it'd already be useful input. I assume fastly is filtering bogus requests from such logs, but even with those included, it's an indicator of scale. For now it's not possible to tell if that number is 1000, 100000, 10 million or 100. |
Logging won't help us detect volumes though so it's not really worth working much on it. |
Right now, the statistics that Fastly gives on web site accesses is extremely broad. It would be useful at times to have more details on which URLs are being hit most, and which ones are causing errors. Logs on the origin server don't provide many details because of the caching. This would be very useful in cases like #344 for example, and it might have spotted #272 for us, as well as just giving general estimates on site usage.
Fastly has just announced their own analysis system that is in beta: https://www.fastly.com/blog/introducing-log-manager-and-insights-now-in-beta It might be worth asking them if we could try it out. With curl's traffic levels, even running it for an hour would likely provide some useful insights.
Alternately, running a simple access log analysis tool like https://www.awstats.org/ on the origin server would be better than nothing.
If this is done, privacy of the reports needs to be considered, which probably means most reports can't be publicly visible.
The text was updated successfully, but these errors were encountered: