It seems I left many people with too little detail on my last post about JavaScript so, by request, I will give a bit more information about what it is our Foglight architects are working on. The way we are treating JavaScript instrumentation is like we’d treat any new domain. Today Foglight monitors the network, web, end user, database, application, and operating system domains; now, with JavaScript instrumentation, we are also monitoring the browser domain. The first thing we assess in new domains is the data that is available to us. We want to know what we can get and then we want to look at how we get it. Our initial focus will be on 3 new, fairly distinct, datasets: HTML 5 navigation timing, JavaScript errors from the browser, and important browser events like clicks from a mouse or enters from the keyboard. We are actively working on bringing in all of these datasets. These are all very likely to be in the Q3 release but there is no guarantee at this point. This is all purely forward looking and subject to change.

We’ll start with the HTML5 navigation timing. This dataset is available in the newer Internet Explorer, Firefox, and Chrome browsers. It is not available on Safari or many of the mobile device browsers. What’s nice about it is that we can get full page load time in the browser and we can see breakouts of DNS lookup, redirect, SSL handshake, processing, and cache access timing. For more details you can reference this page: These measurements are taken on each page. There are element end times available through this API but one of the current weaknesses in the data is that we don’t get start times of the elements on the page, these measurements are called resource events. A good use of resource events will be to use them to gage the effects of partner infrastructures or third party components that are in your pages.

Next on to a more straight forward data set and that is JavaScript errors. These errors are invisible to Foglight today because they happen in the browser and are not sent over the wire. Now that we are in the browser we can trap them and report on them in addition to what is already captured off the wire.

Finally, we have browser events. These are nice to track and add valuable contextual information to the captured page and hit data, especially for asynchronus applications. For example, a page had a click on a menu. Once we know this click happened we can start associating other data to that click. Alone it’s not very interesting but when you think of these events in the context of a subsequent set of hits gathered off the wire and JavaScript errors this data becomes super interesting. For example, I see a click followed by an asynchronus call back to my web server that took 1 second and after that I saw a JavaScript error. Consider what you would see today if you just have FxM and FxV wire datasets or even worse, if you’re still stuck with just web logs.

The beauty of these new datasets will become more evident when you see them all combined in one Foglight page. Think of looking at a bunch of hits or even a session in FxV today. Now think of that, already rich data, with supplemental data that comes right from the user’s desktop. If you thought Foglight allowed you to understand a lot more about what your user’s are experiencing, just wait until you get a look at this stuff.

As always feedback is welcomed and encouraged…