BF on CF
Probe Your Servers
Probe Your Servers
Aug. 31, 2001 12:00 AM
For ColdFusion to work properly lots of bits and pieces have to be in place and functioning correctly. Web servers need to be up and running, database servers need to be accessible, any external components need to be reachable, and, of course, ColdFusion must be functioning properly.
If any of these fail, so will your applications; if failure does occur, you need to know as quickly as possible, preferably before end users find out. Which brings us to the subject of probes.
Understanding Probes
There are lots of ways to check that code or services are working, but the simplest is to just give it a try - if an error is generated, what you're testing is broken. For example, to test that a database is accessible you could run a simple query against it using ColdFusion <CFQUERY>. If <CFQUERY> returns an error, you'll know that the database was not accessible - simple as that.
Now imagine you had a way to automatically execute that simple query at regular intervals, perhaps every few minutes. Also imagine you had a way to examine any output generated by the query and could take some action based on what it contained. Well, don't imagine. That's exactly what a probe is, and ColdFusion has them built right into the product.
The basic principle behind probes is very simple. You tell ColdFusion what to execute and how often, how to recognize a failure condition, and what to do when one occurs - ColdFusion does the rest. You can create as many probes as you need, and you can edit and remove probes too, all using the ColdFusion Administrator.
Note: Probes are only supported in ColdFusion Enterprise, not in ColdFusion Professional.
Standard Probes
Before we discuss writing your own probes, it's worth mentioning that ColdFusion has several standard probes built right into the product, and you can use these without defining or creating anything. To access these, open the ColdFusion Administrator, select the Tools tab, and select Alarms from the Server Monitoring options. You'll see a screen like the one shown in Figure 1, which lets you specify the e-mail address (or multiple addresses separated by commas) to which alarms should be sent if any of the following events occur:
Web server is inaccessible
Web server is busy
Load balancing server (if one is being used) is inaccessible
You may also specify which e-mail address to use for notification if any other probes fail, as well as the SMTP server to use to send the mail.
Creating Probes
The real fun (okay, so fun may be a bit strong, but bear with me) is in creating your own probes. To do this go to the Server Probes page in the ColdFusion Administrator by selecting the Tools tab, and then System Probes from the System Monitoring options. As seen in Figure 2 this page displays a list of probes along with their status (green if okay, red if failed, yellow if temporarily suspended), along with buttons that allow you to create, edit, or delete probes.
To create a probe click the New button to display the Server Probe Setup screen seen in Figure 3. You'll be prompted for two settings: Probe Settings, which define the probe itself, and Failed Probe Response Settings, which specify the actions to be taken upon probe failure.
First you must define the probe type and you have two choices: Default Probe executes a URL (usually a CFM page, but it doesn't need to be so) that allows you to inspect the generated results; Custom Probe executes an application (an EXE file, for example) that allows you to take action based on return values. You'll also need to name the probe using any unique name, and specify either the URL (if creating a Default Probe) or application name (if creating a Custom Probe to be executed).
Next comes the important part - you'll also need to tell ColdFusion what to look for to determine success or failure, and this too differs based on the probe type. If you're creating a Default Probe specify a string of text to search for (the match is case-sensitive); if you're creating a Custom Probe specify the return value that's expected upon success. Either way, each time the probe has been executed Cold-Fusion will be able to determine success or failure by inspecting the results.
You may also specify a frequency (how often the probe should be executed, default is every 60 seconds) and a timeout (when should ColdFusion give up and assume the probe is failing, default is also 60 seconds). Be careful not to specify too low a frequency; you wouldn't want all those requests being executed unless you absolutely need that level of monitoring.
Having defined the probe you'll then need to tell ColdFusion what to do when a failure occurs. You have several options here:
- Specify a server against which actions should be applied
- Restrict traffic (preventing further access) to a server
- Execute a script or file of your choice
- Restart ColdFusion (this option is only available if creating a Default Probe)
- Log that ColdFusion was restarted (this option is available only if creating a Default Probe)
And of course, if you specified an e-mail address in the alarms page (see Figure 1), an e-mail will be sent as well.
What to Probe
Now you know how to create probes. But what should you probe? Here are some suggestions:
- You should have one global probe to check that your site is up. Have it request your home page, or any other page of your choice, to check that the site is up and responding.
- Monitor your databases. Either retrieve no rows (write a query that returns nothing) or execute a stored procedure - the data re-turned is not important, you just need to make sure no errors are returned. To do this, wrap the query in a block and output either SUCCESS or FAIL-ED (and set the probe to check for SUCCESS).
- If you have a production site and aren't expecting code changes, monitor the file and directories (traverse the tree finding date and time stamps and compare them to known values). You don't want to execute code like this too often, but running it periodically will let you know that someone has been up to no good. You could even specify an action that would restore the server to a prior known state (self-unhacking, now that's a cool idea!).
- If your DBMS or any other system has diagnostic utilities, set up Custom Probes for them to ensure it's up and running.
- You could even create a special probe page that performs all sorts of tests and sets results as needed. This way a single defined probe could test for multiple potential problems, and you'd be able to update the list easily without even having to access the ColdFusion Administrator.
Give it some thought, you'll have no problem coming up with a list of items or services to probe.
Summary
Exactly what you probe is up to you, as well as where you probe it from (using Default Probes you can probe remote servers just as easily as you could local servers), and what you do when a failure occurs. Probes are not just the 24/7 eyes and ears monitoring the health of your servers, they're also the toolkit you can utilize to correct problems when they occur. If you're not using probes yet, you should...and quickly.
About Ben FortaBen Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.