When setting up monitoring jobs, there are often predictable time periods in which you want to change the behavior of a script or prevent it from running at all, without having to manually stop/start the monitoring job each time. For instance, you might want to prevent errors and alert emails during routine maintenance windows, or perhaps you’re only interested in site performance on weekdays during regular business hours. We’ve come up with solutions to a few common situations that will help jump start your scripts.

Overview
At the core of all these examples is a small configuration object that sits at the top of the script for quick changes, and a single function that returns true or false depending on whether or not the current time is within a blackout period. The following is some pseudo-code outlining one way in which you might choose to implement these examples in your own scripts. Don’t forget to add in the appropriate maintenance object and isInMaintenance() function from the examples below to make this work.

// The configuration object for the maintenance window
var maintenance = {...}
 
// The maintenance function (plug in the appropriate function)
var isInMaintenance = function() {
    ...
}
 
var selenium = browserMob.openBrowser();
 
if(!browserMob.isValidation() && isInMaintenance()) {
    // Active maintenance window
    browserMob.log("Is in maintenance!");
} else {
    // Run normal script
    browserMob.beginTransaction();
 
    browserMob.beginStep("Step 1");
    selenium.open("http://google.com/search?q=website+monitoring");
    ...
    browserMob.endStep();
 
    browserMob.endTransaction();
}

Web Page Check
The most straight forward way to check for a maintenance window is to have Selenium load a web page and look for an element that’s only present during scheduled down time. You’ll want to be careful not to choose something that is also present when the site is really in trouble or you will never get your alerts!

var maintenance = {
    check: {
        url: "http://example.com/home",
        element: "//img[@title=\"maintenance\"]"
    }
}
 
var isInMaintenance = function() {
    if(maintenance.check && maintenance.check.url != null && maintenance.check.element != null) {
        selenium.open(maintenance.url);
        return selenium.isElementPresent(maintenance.element);
    }
 
    return false;
}

Multipe Date Ranges
One of the most common requests we get is for a way to handle scheduled maintenance windows. These windows tend to be one-off date ranges decided well in advance of the actual event. Given a set of start/end dates, you could prevent monitoring errors and email alerts during the blackout periods. When setting the dates, don’t forget to include the time zone abbreviation in the argument string or the script will use the local time of the machine it’s running on.

var maintenance = {
    dates: [
        {start: new Date("05/12/2010 23:00 PDT"), end: new Date("05/13/2010 02:30 PDT")},
        {start: new Date("05/24/2010 23:00 PDT"), end: new Date("05/25/2010 02:30 PDT")}
    ]
}
 
var isInMaintenance = function() {
	var now = new Date(),
	    nowTime = now.getTime(),
	    maintenanceWindows = [];
 
    // Check for maintenance date ranges
    if(maintenance.dates && maintenance.dates.length) {
        maintenanceWindows = maintenance.dates;
    }
 
    for(var i in maintenanceWindows) {
        var m = maintenanceWindows[i];
 
        if(nowTime >= m.start.getTime() && nowTime < m.end.getTime()) {
            return true;
        }
    }
 
    return false;
}

Days of the Week
Here’s an example for blacking out specific days of the week. This will allow you to create a script that, for example, monitors on Mondays, Wednesdays, and Fridays, or only on business days. Simply provide a time zone offset, which is the number of minutes your time zone deviates from coordinated universal time (a.k.a. UTC, GMT, Zulu time), and the days of the week you don’t want to run the script (from 0-6, where 0 is Sunday, 1 is Monday, etc.).

var maintenance = {
    timezoneOffset: 240, // UTC offset in minutes (eg: NYC (GMT-4) is 4 * 60
    days: [0, 6]    // Sunday = 0, Saturday = 6
}
 
var isInMaintenance = function(){
    var now = new Date(),
        nowTime = now.getTime(),
        timezoneOffset = maintenance.timezoneOffset || 0,
        localTimezoneOffset = now.getTimezoneOffset(),
        timezoneDiff = localTimezoneOffset - timezoneOffset;
 
    // Check for full blackout days (such as weekends)
    if(maintenance.days != null && maintenance.days.length) {
        var targetDate = new Date(nowTime + (timezoneDiff * 60 * 1000)),
            targetDay = targetDate.getDay();
 
        for(var i in maintenance.days) {
            if(maintenance.days[i] == targetDay) {
                return true;
            }
        }
    }
 
    return false;
}

Time of Day
This example shows how you can have a daily blackout range. This code will parse the start/end strings into a daily time range adjusted to the target time zone. Use this if you only want to monitor during banker’s hours, or if you want to prevent a script from running while your database is backing up.

var maintenance = {
    timezoneOffset: 240, // UTC offset in minutes (eg: NYC (GMT-4) is 4 * 60
    hours: {start: "23:30", end: "07:30"}
}
 
var isInMaintenance = function(startTime, endTime, offset) {
    var offset = maintenance.timezoneOffset || 0;
    var now = new Date();
    var nowTime = now.getTime();
    var maintenanceWindows = [];
 
    var toUtc = function(localTime) {
        var chunks = localTime.toString().split(":");
        var h = parseInt(chunks[0], 10);
        var m = parseInt(chunks[1], 10) || 0;
 
        var d = new Date();
        d.setHours(h);
        d.setMinutes(m + offset);
 
        return d.getHours() + ":" + d.getMinutes();
    }
 
    var sH, eH, sM, eM;
 
    startTime = toUtc(maintenance.hours.start);
    var chunks = startTime.toString().split(":");
    sH = parseInt(chunks[0], 10);
    sM = parseInt(chunks[1], 10) || 0;
 
    endTime = toUtc(maintenance.hours.end);
    chunks = endTime.toString().split(":");
    eH = parseInt(chunks[0], 10);
    eM = parseInt(chunks[1], 10) || 0;
 
    var startDate = new Date(now.getFullYear(), now.getMonth(), now.getDate(), sH, sM, 0, 0);
    var endDate = new Date(now.getFullYear(), now.getMonth(), now.getDate(), eH, eM, 0, 0);
 
    if(startDate.getTime() <= endDate.getTime()) {
        // Single range mid-day
        maintenanceWindows.push({start: startDate, end: endDate});
    } else {
        // Date wraps, which means two blackout ranges in a single day
        var morning = new Date(now.getFullYear(), now.getMonth(), now.getDate(), 0, 0, 0, 0),
            midnight = new Date(morning.getTime() + (24 * 60 * 60 * 1000));
 
        maintenanceWindows.push({
            start: morning,
            end: endDate
        });
 
        maintenanceWindows.push({
            start: startDate,
            end: midnight
        });
    }
 
    for(var i in maintenanceWindows) {
        var m = maintenanceWindows[i];
        if(nowTime >= m.start.getTime() && nowTime < m.end.getTime()) {
            return true;
        }
    }
 
    return false;
}

Now, a few of you might have noticed that the above examples are compatible with one another; you can mix-and-match them as you see fit. Just combine the various maintenance object fields into one config object, combine the contents of all the maintenance methods you want to use (just watch not to overwrite the variable declarations), and you can create something that fits just about any situation.

Tweet This Post 

downtime · javascript · maintenance · maintenance windows · Monitoring · RBU · Scripting · scripts

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.

What you will need:

1. API Key & API Secret. Log on to browsermob.com with your account and under Home > My Profile you will find your API key and secret.
2. CLI BrowserMob API tool. Download our nifty API command line tool from http://github.com/rferreira/bmob-python
3. Nagios 3.06. We have it installed on Ubuntu Jaunty for this example.
4. jsonpretty. This just makes JSON strings human-readable in the CLI. Get it here: http://github.com/nicksieger/jsonpretty

Getting to know your monitoring job:

Before we can actually wire anything into Nagios we need to find out the internal id of a monitoring job. In the BrowserMob web interface monitoring jobs have friendly names like “BMOB”, but internally they are referenced by a unique id such as “fe33b13dc0764588b5eabf747a96a48b”.

You will need the monitoring job’s unique id. You can get it by running the following query (replacing the credentials with your own):

$ ./bmob.py -c XXX:XXX http://browsermob.com/a/m/all | jsonpretty
[
{
"browsers": [
"FF3"
],
"name": "BMOB",
"lastBilled": null,
"alertEmail": "support@browsermob.com",
"preferenceId": "7ea6d3b47c8c4a1c8d30db7fef9d5fd1",
"lastRun": 1273007522255,
"deleted": false,
"enabled": true,
"id": "fe33b13dc0764588b5eabf747a96a48b",
"lastUpdated": 1273005121243,
"frequency": 15,
"locations": [
"DALLAS",
"SING",
"AMS",
"NY",
"DC",
"DUBLIN",
"SF"
],
"scriptId": "21312a2da1834f2aa02db73f32037619",
"accountId": 2,
"email": "raf@browsermob.com"
}
]

Look for the “id” property in the JSON response.

Wiring it all up:

Now we need to write a wrapper script to query and parse the API results. Create a file called “check_bmob.sh” with the following contents:

#!/usr/bin/env bash
 
# RETURN CODES:
OK=0
WARNING=1
CRITICAL=2
UNKNOWN=3
 
WARNING_T=2000
CRITICAL_T=5000
 
ID="fe33b13dc0764588b5eabf747a96a48b"
 
# dates
START=$(date -u  --date="5 mins ago" +%s)000
END=$(date -u  +%s)000
RESP=$(/opt/bmob-python/bmob.py -d metric=responseTime,start=$START,end=$END,resolution=hour –c XXX:XXX http://browsermob.com/a/m/$ID | tr "," "\n" | grep responseTime | awk -F ":" '{print $2}')
 
for t in $RESP
do
   if [ $t -gt $CRITICAL_T ]
      then
         echo $t
         exit $CRITICAL
   elif [ $t -gt $WARNING_T ]
      then
         echo $t
         exit $WARNING
   fi
done
 
exit 0

What this script will do is look up the response time for the last 5 minutes and trigger an alert if the response time is greater than the threshold for WARNING_T or CRITICAL_T.

Now, we just need to tell Nagios to use it; the sample config below should do the trick:

# defining the command
define command {
    command_name    check_bmob
    command_line    /usr/lib/nagios/plugins/check_bmob.sh
}
 
define hostgroup {
    hostgroup_name website
    alias web site
}
 
define host {
    host_name browsermob.com
    check_command check_http
    alias login-check
    use generic-host
}
 
define service {
    hostgroup_name                  website
    service_description             response_time
    check_command                   check_bmob
    host_name                       browsermob.com
    use generic-service
}

Please keep in mind that Nagios’ configuration files can be–and usually are–fairly complex. The example above is purposely simple and may need to be modified to work in your environment.

If everything works as planned you should be able to log in to the Nagios web interface and see:

Pudding

Official BrowserMob API documentation:

http://cdn.browsermob.com/api.html

Tweet This Post 

API · Example · Monitoring · Nagios · tools

A couple days ago we announced a brand new pricing system that lowered our pricing across the board. For our existing customers, this pricing is quite a bit different than what they were used to, so we wanted to put together a list Frequently Asked Questions about the new plans.

Is this new pricing more or less expensive?

By any metric, this a price reduction. We’re extremely excited to have found a model that controls costs for our customers while actually making the revenue flow for our company healthier.

Not only did we reduce the overall pricing for monitoring and/or give a better value for the price, we created a new way to buy load testing from us that is significantly less expensive for most projects.

But even if you stick with the old model of paying for load tests, we’ve reduced the price because the first 25 RBUs or 100 VUs are always sold “at cost”. This means that a 100 RBU test that used to cost $300 now costs $15 under the new plan and $228.75 when using the old plan. To understand how you can choose between either plan, please see the Can I still use my old pay-as-you-go plan? question.

How has pricing for monitoring changed?

The old pricing model for monitoring used a complex formula in which the time of the script being used to monitor your site heavily influenced the overall cost. For example, a job that averaged 3 seconds per run might cost half of that of a script that took 7 seconds to run. The problem with this model was that if your site slowed down, your costs would go up, making your monitoring budget unpredictable.

The new pricing model eliminates that unpredictability. Instead, there is a constant number of monthly page views that you’ll used, based entirely on your script, number of locations you check from, and frequency at which you check. No matter how fast or how slow your site is, the price will remain constant.

For example, if you wanted to test a script that hit your home page, visited the login page by clicking the login link, and then logged in, that would be 3 page views. If your monitoring job ran that script every 15 minutes from two locations, you’d use 17,280 page views per month:

17,280 = 3 page views x 60 mins / 15 min freq. 
           x 24 hours x 30 days x 2 locations

Our pricing packages start at 3,000 monthly page views per month (FREE) and go all the way up to 350K monthly page views.

What happens to my current monitoring jobs?

If you were paying for a monthly, recurring plan, then you have already been converted over to the new model and are now paying less than you were before. That’s because we’ve lowered our pricing for all monitoring packages. For example, what was $300/mo is now $249/mo, and what was $175/mo is now $149/mo.

However, if you were not using a monthly credit package to pay for your monitoring, you may need to take some action. Your monitoring jobs have not been disabled, but they are currently running free of charge. Over the next few weeks, we will be contacting each customer who is in this situation and work with them on finding a monitoring package that fits their needs.

In some cases, a customer may want to transfer credits previously purchased and apply them toward a monitoring job. We are more than happy to convert purchases over this way and will work with each customer that is interested in doing this.

How has pricing for load testing changed?

In our previous pricing model, each concurrent RBU cost 10 credits/hour while each concurrent VU cost 1 credit/hour. Customers could buy credits at various rates ranging from 30 cents/credit down to 7.5 cents/credit, depending on the size of the purchase. Purchases of $5,000 or larger were eligible to purchase additional credits of any amount at the original price (usually 7.5 or 10 cents).

Under the new model, there are no more credits. Rather, we have converted them all to “cloud dollars” by multiplying the remaining credits in your account by the price paid for the credits. For example, if you purchased 1000 credits for $300 and had 300 at the time of the switch, you would be left with $90 in cloud dollars.

These cloud dollars can be used to pay for load tests. The price for each load test will be quoted at the bottom of the “schedule load test” page. If the test is larger than the load test package that you currently have, we will quote a higher price that is based on the old pay-as-you-go pricing plan.

How do “cloud dollars” compare to credits?

If you’re used to the old credit system, the easiest way to think of cloud dollars is that they reflect a credit price of just 1.5 cents – a 20X reduction from the 30 cent price most of our customers were using.

This means that a 100 RBU test that used to cost $300 now costs only $15 when you are subscribed to a qualifying load test package. For customers who purchased a larger credit package and therefore bought in to a smaller credit price (ie: 15 or 10 cents/credit), the savings are not as large but are still very significant (ie: 10X or 6.67X, respectively.)

Can I still use my old pay-as-you-go plan?

Absolutely.

Simply keep buying cloud dollars just like if they were the old credit system. When you schedule a test, you’ll be quoted a price to run the test. You may be presented with a note explaining that the per-test fee would be lower if you were using a load test package, but you are under no obligation to sign up for such a package. This is especially ideal for anyone who does infrequent load testing.

The price of test will be based on what your original credit price was. This means that a 100 RBU test might cost $228.75 for one customer at the 30 cent price point and $78.75 for another customer at the 10 cent price point. However, both would only pay $15 if they were subscribed to a load test package.

Can I upgrade to the new pricing?

Yes. We can apply any unused cloud dollars towards load testing or monitoring packages. Just contact us and we can get the process started.

What is the threshold for the free BrowserMob services?

For monitoring, you can do up to 3,000 page views per month for free.

For load testing, you can run up to 25 RBUs and 100 VUs at any time without paying for a load testing package. However, you will have to pay the raw cloud fees for each test. These fees are 15 cents per RBU hour and 1.5 cents per VU hour (ie: 25 RBUs = $3.75 and 100 VUs = $1.50). Each account comes with 10 cloud dollars to get you started, but you can purchase more at any time.

Tweet This Post 

Load Testing · Monitoring · Pricing

Today we launched a brand new pricing structure for both our website load testing and website monitoring service. When coming up with new pricing for both our products, we set out do to four things:

1. Make it simpler and easier for anyone to quickly understand.
2. Make our advanced products (ie: our real browser services) more affordable.
3. Give a better value by reducing our pricing across the board.
4. Provide a free offering that never expires.

Load Testing Pricing

Our load testing service now has two types of fees:

• A base fee to use the software.
• A “cloud fee” for each test that gets run.

The base fee is where BrowserMob makes money as a company. We offer a weekly, monthly, or annual price – with significant discounts for annual purchases. We also offer three levels of service: Basic, Advanced, and Professional. Each package includes enough “cloud dollars” (see below) to complete most testing projects.

The cloud fee represents our raw costs to run in the cloud. This means after you pay the base fee, you are free to run as many tests as you’d like with no extra markup. For example, $15 in “cloud dollars” gets you a 100 browser test or a 1,000 virtual user test.

The most exciting thing about this model is that if your tests require no more than 25 browsers or 100 virtual users, there is no base fee. This means that after you use up the complementary 10 cloud dollars with each signup, you can keep using the service by simply covering the raw fees incurred with each test.

We’re also excited to offer any of our Basic, Advanced, or Professional packages to non-profits and open source organizations free of charge.

You can review all the load testing packages here.

Monitoring Pricing

Our monitoring pricing is now based on a very predictable number of “monthly page views”. For example, if you want to check a page every 15 minutes from one location, you would require 2,880 page views:

2,880 = 1 page view x 60 min / 15 min x 24 hrs x 30 days

The best part about this new model is that if you need 3,000 or fewer monthly page views, the service is 100% free. For more frequent monitoring, our monthly plans start at $49. You can review the monitoring pricing here.

Existing Customers

We will be posting a follow-up Q&A for all of our existing customers shortly. It will explain the transition process and what options are available. At a high level, we expect 99% of our customers to immediately get a better value. However, if any existing customer prefers to stick with the old model, we will gladly honor it.

Update: Please see our FAQ entry that discusses the changes for existing customers.

Tweet This Post 

Load Testing · Monitoring · Non-profit · Opensource · Pricing

Yesterday BrowserMob launched monitoring services on two more clouds GoGrid and Rackspace. This allows users to monitor their websites from four different regions now: Washington, Dublin, San Francisco, and Dallas. We are very excited to have added two new clouds since it will giving customers the ability to see how their site loads from different parts of the country and different network paths.

If there is a region that you’d particularly like to see let us know since we plan on rolling out more locations over the next few months.

Tweet This Post 

No tags

An issue near and dear to our hearts is website performance monitoring over time. Not just alerting you when your webisite is down, but helping to find trends in the site’s performance. Are you getting more users on the weekends? Is you’re site slowing down due to third party ads? These are the types of questions one can only answeri if the websites performance monitoring is done continuously.

This tool can be used to alert you if your site goes down, but we are hoping people will use it for a lot more. The main view offers a long-term trend-line of the websites performance as well as a view of a smaller section. By highlighting portions of the main trend-line at the bottom we can drill down into the website performance monitoring data.

By choosing a single record we can even see what elements of the page are causing poor website performance.

In the near future we hope to roll out other useful tools, such as object trend-lines that will show how a given object has performed over time. We hope that you will find and share new and interesting ways to use website performance monitoring to make your website a better experience for your users.

Tweet This Post 

No tags

In case you missed our launch announcement on TechCrunch last Thursday I’m here to tell you that we are live. The new monitoring product is now available; take a look at our monitoring video overview.  I’ll be writing some more about the new features and what we are hoping to achieve with monitoring in the future. But for now go give it a try. You can run free monitoring jobs to see how it works.

Tweet This Post 

No tags