

Front End JavaScript Error Tracking - volldabei95zwei
http://grexi.github.io/console/

======
STRML
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](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.

------
neilunadkat12
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..

~~~
shankscoder
You might want to check out Atatus, www.atatus.com.

Their next release (out in the next few weeks) will feature Contextual Error
Tracking - which helps a developer to know what user actions happened, find
out what input the user gave, identify in what context the error had occurred,
easily reproduce the error from the steps listed, etc.

They also provide a detailed Stacktrace and Environment report.

Note: I'm not affiliated with Atatus directly. I know them as they work out of
my coworking space, but I'm a big fan of the tool and hopefully, first in line
for the next release.

