Announcing JS Error Reporting and AJAX Timing in New Relic

I work on the engineering team developing New Relic’s browser monitoring features, so it’s exciting to announce that, as of today, we’re offering a sneak preview of JavaScript Error Reporting and AJAX Timing to all of our customers, even those on free Lite accounts! We’ve also reorganized our existing real user monitoring (RUM) features to reflect the fact that for many customers a larger and larger percentage of their applications are written in JavaScript and HTML and run in the browser.

I want to talk a bit about what it was like to develop this product, the technical challenges we faced, and the way we’ve used the increased visibility into our own users’ browsers to better understand how our code is working.

Decorations for your JavaScripts

The first step in building a system that makes it easy to see the JS errors and AJAX happening in user browsers was figuring out how to collect the data. We have some experience writing instrumentation at New Relic so we knew decoration was the key. Instrumentation, whether it’s for Ruby, Java, .NET, or Node, nearly always follows the Decorator Pattern. This is one of those classic “Gang of Four” software design patterns. The goal of the decorator is to add additional functionality to an object dynamically. Pretty much every language has a mechanism for doing this, whether it’s swizzling, alias_method_chaining, function wrapping, or byte code manipulation.

Say you have a function that does something. It might look like this:

firstCode

You may decide to decorate this function (and other functions) with some additional behavior that logs how long the function took to run. That might look like this:

472a8e1bf43005480e55f84cbac03200

Chase Douglas and Nick Niemeir developed a system for decorating the interesting APIs in the browser, creating a low impact mechanism for installing listeners on events, setTimeouts, and AJAX calls, and providing a way to ship useful information from a huge variety of browsers to your eyes. Our continuous integration setup runs our test suite against the 20 most popular desktop and mobile browsers (representing nearly all internet traffic) to help ensure compatibility and root out obscure browser bugs.

Object #<Object> has no method ‘object’

Once we’d learned how to instrument the JavaScript running in web sites, we set our minds to trying to make sense of it. We learned quickly that it’s the wild west out there. Browser extensions, adware, and not-to-spec browser behavior means there’s few rules to the errors browser will throw. It’s not uncommon to see a rogue browser come in and throw thousands of errors per minute because of some wonky JS running in an extension. As a result we had to find a way to cut down on the noise and help our customers easily distinguish a real problem on their site from a messed up browser acting crazy. We worked hard to develop a set of metrics that are sensitive to errors that many users are experiencing, but not to errors that occur many times in a loop in one page load.

On the Browser App overview page we graph the percentage of “Page views with JS Errors.”

Sam image 1

We’ve found that frequently JS errors are all or nothing. Either you get none or you get a lot, so this high level metric is a good indication of the general health of your JavaScript.

If you dig deeper, into the JS errors tab, you’ll find graphs that show you the number of page loads that were effected by a specific JS error.

Sam blog 2

This helps minimize the noise for errors thrown in a tight loop by one browser to help you quickly identify the problems that many users are experiencing (and the browsers they’re experiencing them in).

And for when you’re diving deep into a problem we also provide complete details from individual error occurrences, including error message, stack trace, browser version, user agent string, url, and controller action. No we don’t just use window.onError.

Sam blog 3I heard you like Asynchronous JavaScript and XML (AJAX)

We’re also providing visibility into the AJAX requests hitting your site. For the non-technical crowd, AJAX is a way for a web page to request more data from the server without completely loading a new web page. It’s everywhere. Single page web apps do it and it’s increasingly rare to find a traditional web app that doesn’t have a significant AJAX component.

However, while many companies (including New Relic) have offered “Real User Monitoring (RUM)” for years it’s almost unheard of for developers to have visibility into how their apps’ AJAX requests are performing.

Fortunately, with today’s release, it just takes the click of a button to see the response times, throughput, HTTP status codes, and data transfer of all your AJAX requests recorded from the end users’ point of view.

We’ve also developed the capability to time the JavaScript callback functions that process AJAX responses in the browser. Currently we show this as one of the components of AJAX Response Time Breakdown and we’ve also been having a lot of fun thinking through the features this capability will allow us to create in the future.

Sam blog 4We’ve found having increased visibility into AJAX to be extremely helpful for quantifying the effect that performance problems have on the end user experience. If you’ve ever waited for a slow chart to load on rpm.newrelic.com you know what I’m talking about. Now we can see how long our customers are waiting for their charts to load and focus on improving that experience.

Sam blog 5The future of browser monitoring

When our team came together to develop New Relic Browser monitoring we set the goal of providing the same level of visibility into single page and front end applications as our customers currently enjoy for their Ruby, Java, .NET, PHP, Python, and Node apps. Today we’ve taken a major step towards achieving that goal but we know that the future holds much more. Developers are increasingly leveraging the browser as an advanced application development platform, and they’re doing it without full visibility into how changes in their JavaScript, CDN usage, or data transmission strategies effect their users in production. As a long time user of New Relic’s Ruby app monitoring it’s hard for me to imagine deploying to production without the visibility and confidence that New Relic’s tools provide. The Browser team is committed to ensuring front end developers can enjoy that same confidence, that they can quickly detect problems, and that they can focus more of their energy on building great user experiences instead of chasing down production problems.

You can enable our sneak preview features by visiting the JS Errors or AJAX tabs in the New Relic Browser interface. Both features will be generally available as part of a paid offering later in 2014. What? Paid offering? Yes, but don’t worry you’ll always get the existing real user monitoring features you know and love as part of your New Relic APM subscription. The new offering will have all sorts of really cool NEW stuff, like JavaScript Errors, AJAX Timing, CDN Performance Monitoring, and more.

We hope you like what you find and we look forward to your feedback.

About the author

Sam Goldstein is engineering manager, agents, for New Relic. He manages Browser Application Monitoring team. He's been writing Ruby for almost a decade and is the author of several semi-popular gems, including diffy and timetrap.

Tell us your thoughts Or Send us an internal high five

Talk to @newrelic