Front End JavaScript Error Tracking

This is a cool project- I've been working on a version of this using Sentry, a PhantomJS web scraper and a simple XHR.

Admittedly, HTML2Canvas (or anything that creates <canvas> from the page so it can be screenshotted) is pretty cool and allows this great sort of annotation/selection capability where a user can choose to highlight what went wrong and provide some feedback. That's great. I found html2canvas to be really resource heavy when taking the snapshot, and there was no way to do it 'automatically'. Why does that matter? When debugging, I want history.

My ideal bug-reporting tool would not only give user specs, stack traces and a screenshot, but a history of screenshots going back to an arbitrary length so I can figure out exactly what the user was doing that triggered that error. Trial and error could lead one to the correct sequence of screenshots but I've found one per 10s / 6 max (so 60s of history) to be a pretty good way to do it.

So if you know you want history, how do you get it? You can't use html2canvas to just take snapshots the entire time the user is using the page (I've tried (work account on GitHub): https://github.com/niklasvh/html2canvas/pull/270). It's far too slow, memory heavy, and if done asynchronously can create really strange render bugs if the user scrolls or mutates the DOM. Some of these issues can be fixed but it will forever be slow and take a ton of CPU. So I came up with something else.

At the same time I was working on a web scraper + screenshotter using PhantomJS that talked to RabbitMQ. I thought: why render the screenshot at all on the client? I have all the same resources; I can recreate the environment from source, on my own time, asynchronously, without making the client do the work for me and slowing down their browser. So the implementation I came up with does the following:

1. Maintains a rolling 5-element array of HTML snapshots (usually via document.firstChild.outerHTML), tied to setInterval. That part is easily configurable to your preference. The snapshots even contain a virtual cursor element that I just track using mousemove events. 2. On error, collects the usual data using Raven (the client-side library that reports to Sentry, the open-source error aggregator). 3. Rather than hit Sentry directly, the browser POSTs to a local route. That route separates the HTML snapshots from the Raven/Sentry data, and creates UUIDs for each snapshot to create S3 filenames. 4. The Sentry data is sent to Sentry along with the S3 filenames, and the HTML + filenames are put on a RabbitMQ queue. 5. A separate process is listening to the queue, grabs HTML off the queue and renders the page using the CSS (no scripts) from the running webserver. The screenshot is then uploaded to S3. 6. A Sentry plugin displays those images in the bug report, assuming the S3 urls are valid. They may take a while to resolve but they usually show up in < 2 minutes.

Since there are a lot of moving parts, I've always wanted to create a simple devops service out of this, but I haven't had the time, being busy with other projects. But if there is interest, I could open-source some of the components.

One of my friend had made a similar project around 2 years back.. its called errorception.com.

I think it seems to be doing good now..