We recently had a customer from a large clothing retailer ask us if there was any way to ensure that data, such as a username/password combination, could be restricted such that it was “checked out” and available only for a specific concurrent user. This is very common with logins, where systems often will prevent concurrent logins from multiple IP addresses.

While BrowserMob does not have a concept in which data rows can be “checked out”, some simple scripting can achieve the same results. The key is in creative use of the browserMob.getUserNum() and browserMob.getTxCount() APIs. You can learn more about them by reading up on the BrowserMob APIs.

To demonstrate how you can use our new API to leverage deeper integration with your internal monitoring tools, we’re going to guide you through an example that connects Nagios (a ubiquitous open source monitoring tool) with BrowserMob’s web site monitoring service.

Getting it all setup:

Since this is intended to be a quick how-to, we’re going to assume that you already have a working Nagios installation behind your firewall and an active monitoring job with BrowserMob. Here at the BMob we eat our own dog food, utilizing our own monitoring service to monitor BrowserMob.com. For this example, we’ll use a monitoring job called “BMOB” for our Nagios integration.

The BrowserMob team is excited to launch our new API, giving customers access to all their data (including load test results and monitoring reports) through a simple programmatic interface. The API is still in beta and will likely change over the next few weeks, but we welcome everyone to take a look, kick the tires, and send us any feedback.

Currently the API is “read only”, allowing access to load test and monitoring data. We will be adding new services in the coming weeks, including endpoints for creating load tests, monitoring jobs, and working toward complete programmatic access to anything you can do on the BrowserMob website today.

For load tests, yes (we’re working to add support for this to monitoring). You can use BrowserMob API to add any name/value pair to your transactions or steps. Here’s a simple example:

var selenium = browserMob.openBrowser();
 
var tx = browserMob.beginTransaction();
 
var step = browserMob.beginStep("Home Page");
 
selenium.open("http://example.com");
 
// record how long it took for some text to appear
var start = new Date().getTime();
selenium.waitForTextPresent("dynamic text");
var end = new Date().getTime();
 
// get a special cookie out and store it
var cookie = selenium.getCookieByName("myCookie");
tx.put("cookie_value", cookie);
 
// and store the "text" timing, associated with the step
step.put("text_timing", end - start);
 
browserMob.endStep();
 
browserMob.endTransaction();

The important things to notice here are that both beginTransaction() and beginStep() actually return objects that represent the transaction or step, respectively. You can then call put() on those objects to associate arbitrary data, such as custom timings or cookie values, with them.

Then when the transaction is stored in the load test database, you’ll be able to look them up in the name_value_pairs table. For more information on the test database schema, consult the documentation.

We’re always working hard to improve our BrowserMob monitoring and load testing services. Over the last few weeks, we’ve pushed pushed out a bunch of improvements:

New Monitoring and Load Testing Location

Hot off the heels of Amazon’s announcement of a new US West Coast cloud data center, we are happy to report that you can now schedule load tests and monitoring jobs from this new location. Simply select the “San Jose, CA” location when scheduling tests.

Often when it’s time to run a load test or turn on website monitoring, you don’t necessarily want the transaction hitting all your third party components on the page.

For example, you don’t want your analytics software to record the visits as real visitors, since that would skew your marketing metrics. Likewise, you don’t necessarily want advertisements served up, especially if the ad vendor uses “click-through rates” (CTR) to optimize ad prices and a load test would artificially drive down the CTR.

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha