We wrote our own version of this which took about 2 minutes to write. 1. Client hits /support/client-info which generates a specific system error with a unique ID (right 6 digits of a GUID) and pumps browser, error and user context information via log4net into our logging system. Client tells us the error ID. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring to…
Seems kind of awkward. Thinking about it offhand using some Rails terminology, let's see. * Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic. * Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This w…
Probably really wouldn't be that slow, unless done really naively - much of that information is already being written to a web server logfile in most cases, and that doesn't slow things down too much. Send the info to a separate logging server/db. If you're getting a lot of traffic, you're possibly doing a lot of queries anyway - one more is incrementally painful, but shouldn't be a killer.