This article is about our proprietary scripting engine. If you’re just looking for a simple and easy way to monitor your website, we have the perfect service for that, too. You can get alerts by phone call, SMS, XMPP and e-mail. Read about how it works or sign up for a free trial.
We use remote agents scattered all over the globe to perform our device checking functions. A basic feature of our scripting engine is the ability to generate scripts on the fly based on the choices you make when setting up your device. Behind the scenes, your choices result in a script being generated and sent to the remote agents. If the agents only supported these auto-generated scripts, they would hardly be worth talking about. They also support custom written scripts that interact with devices in ways unique to your situation. Imagine having a script that not only accessed your home page, but walked through several pages, supplying form variables along the way; exercising CGI scripts and database connections. Or how about a script to check your e-mail server by sending a test via SMTP and seeing if it arrives by contacting your POP3 interface. Our scripting language can do all this and much, much more.
The Scripting Language
Our scripting language is not an overly complex language and is similar in structure to the language used in MS-DOS batch files. Lets take a look at a few scripts and check out the capabilities.
dns "www.yahoo.com" tcp $HTTP_PORT http get "/"
This is a simple script that checks the home page of Yahoo.com. First, the script checks to make sure that the domain name, www.yahoo.com, can be resolved to an IP address. Next, the script checks connectivity to the port that the HTTP server is listening on. Finally, the script initiates an HTTP protocol connection and gets the home page. If any one of these operations fails, the script generates an error. The following script is a slight variation that also shows some of the error handling available.
dns "www.yahoo.com" on error goto tcp_error tcp $HTTP_PORT http get "/" goto exit :tcp_error set ERRMSG = $LAST_PROTO_MSG on error goto ping_error ping :ping_error error $ERRMSG :exit
This script adds a little refinement to the first script. In this one, if the TCP connection fails, the script immediately jumps to the tcp_error label. There we store the error message that was generated away for later, and then try to pingthe server; if the ping fails, we ignore its error message. Once the ping has completed we re-generate the original error so it will be reported back to our server. The nice thing about this script, is that once you have been notified that your site is down due to a TCP error, you can look at the check record through our Web site. If the ping command was successful you will know that your server is available on the Internet, but that the particular port is not.
Those first two scripts aren’t too revolutionary, and are close to the one generated automagically when you create a standard HTTP site and don’t select any of the optional features. Lets walk through the site a little.
dns "my.yahoo.com" tcp $HTTP_PORT http get "/" if not "2002 Yahoo" in $CONTENT then error "Content Error: Home page not correct" form user = "firstname.lastname@example.org" form pass = "1234" http get "/login" if "Error" in $CONTENT then error "Content Error: Unable to log in" if $LAST_EXEC_TIME > "5.0" then warning "Login time too long"
This script expands on the last to fully check out the user experience on the My Yahoo! site. It checks the home page and makes sure the given keyword can be found on it (“2002 Yahoo” appears at the bottom of the page). Next the script sets some form variables and then calls the login page. This time instead of checking for the existence of a keyword, it checks to make sure that the word “Error” isn’t found on the page. The script wraps up with a check of the amount of time it took to load the page. We keep track of any cookies sent by the server in response to HTTP requests. Those cookies are sent back to the server on any subsequent HTTP requests. This helps us replicate the activities a normal user would cause on your server.
The script shows another feature of our script-based agents, the ability to send a warning instead of always generating an error. Warnings result in alerts being sent out, but your site is not marked down. In this case, the contacts for this site are notified that the page isn’t loading fast enough, but the site is not down and doesn’t need to be marked as such.
Lets wrap up this brief look at the scripting language with a look at a fairly complicated script designed to fully test the functionality of an e-mail server.
set USER="testaccount" set PASSWD="testpw" set EMAIL="email@example.com" dns "mail.mydomain.com" tcp $IMAP4_PORT # Clear out any messages in the mail box imap clear $USER $PASSWD # Send a test message tcp $SMTP_PORT smtp sendmail "firstname.lastname@example.org" $EMAIL "Ignore: SMTPTest" "SMTP test message" wait 1 # Get the number of messages in the box, should be 1 tcp $IMAP4_PORT imap msgcount $USER $PASSWD # If at least 1 message found, then we are done if not $CONTENT = "0" then goto exit wait 2 imap msgcount $USER $PASSWD # If at least 1 message found, then we are done if not $CONTENT = "0" then goto exit wait 5 imap msgcount $USER $PASSWD # If no messages found, then throw an error if $CONTENT = "0" then error "Email not received" :exit imap clear $USER $PASSWD
The scripting capabilities of our remote agents allow you to test the capability of virtually any Internet connected device. We even include send and recv primitives to interact with any socket based device, even if it is not directly supported by a protocol command. Custom scripts can traverse web and FTP sites, interact with mail servers, and report unusual conditions without marking your site down. Our scripting language is also designed to be easily updateable with new Internet based protocols which allows new features to be added in a timely manner. This results in a rapidly increasing feature set for you the user.