If I was actually doing this and wanted to run it on a production site, I would certainly not fire off a post on each error. The most likely solution that I would use off the top of my head would be to store the data in localStorage of the current user where supported.
You wouldn't need to collect everysingleerror, but just a sample. You shouldn't really need to be that concerned with the totally extreme edge cases, and if you are triaging correctly then it's the most common errors that you want to look out for.
So I would implement something that would result in a random selection of my visitors from collecting the errors for me and also have a buffer and client side rate limit included into the application so that errors are saved up, and sent in bulk.
As I start collecting errors which I realise are totally beyond my control, I would then start dropping errors generated from particular files and extensions installed and stop logging them.
Logging everything is wrong in my opinion.
Edit:
Yes I would do the bulk of deciding what to log on the server. However, I think I would still have some standard rules that I know I can apply to disregard certain error events. But since I would constantly be working over the logs, the majority would be done server side.
I think you meant "I agree with the idea but I would implement it differently."
I think I would rather the client blindly send all of the exceptions and put the handling logic on the server side. That way you can get a grasp of total number of errors, number of clients affected, etc. etc. Then you can decide what you are going to persist to database/redis for debugging, etc. If this creates too high a load on the server (then you have some really buggy code) and can configure nginx/apache to ignore some requests...
I would probably catch errors as you would on server side logging, log them according to severity and have the ability to turn on/off logging of certain types on errors via config (eg. log.debug, log.warning, log.fatal etc).
Although I've never had client errors logged to the server, I have had it logged in a hidden "console" (uses Firebug if available, otherwise custom logger). This gave us enough info to debug the error and we could tell users to open the console and copy paste the trace (was accessible via key combo Ctrl+`).
If I was actually doing this and wanted to run it on a production site, I would certainly not fire off a post on each error. The most likely solution that I would use off the top of my head would be to store the data in localStorage of the current user where supported.
You wouldn't need to collect every single error, but just a sample. You shouldn't really need to be that concerned with the totally extreme edge cases, and if you are triaging correctly then it's the most common errors that you want to look out for.
So I would implement something that would result in a random selection of my visitors from collecting the errors for me and also have a buffer and client side rate limit included into the application so that errors are saved up, and sent in bulk.
As I start collecting errors which I realise are totally beyond my control, I would then start dropping errors generated from particular files and extensions installed and stop logging them.
Logging everything is wrong in my opinion.
Edit:
Yes I would do the bulk of deciding what to log on the server. However, I think I would still have some standard rules that I know I can apply to disregard certain error events. But since I would constantly be working over the logs, the majority would be done server side.