This article was originally published in PC Pro and is reproduced with permission.
Oh, the irony! We write about a really nasty task - something that, frankly, we'd like to forget about - and it generates a record volume of email.
The nasty task referred to, of course, was that site monitoring system that ran on an NT box using the standard AT scheduler and lots of horrible DOS commands. Why this should fascinate so many of you, we have no idea. Anyway, in your emails many of you wanted to take up Paul on his glib offer to show how to extend this monitoring system to check the free disk space on the server as well as Web server failures.
In that article we used a batch file running every five minutes that checks for Web server problems, and we were using a freeware utility called wwwget to grab the pages, followed by the DOS 'find' command to check for errors. If we spotted a problem we used Blat! to send an email, which, by employing something like Cellnet's Genie service, we could route as an SMS message through to a mobile phone. For all the details, see RWC, Web Business, issue 63.
Why would we want to extend this system to check for free disk space? The answer is log files. Web server log files are like weeds in a garden pond: they start off fairly innocuously taking up very little space, then you turn your back and they've taken over. This is especially true for high-volume Web servers, which tend to be tucked away in the corner of a machine room just humming away, efficiently serving pages. There will be regular backups, but beyond that the machines will be left alone.
The problem is that every time a page or graphic gets served, it will add an entry to the end of the log file. Even a medium-load server will probably be generating log files of around 100Mb per day, and higher-volume servers might be generating a gigabyte or more. It doesn't take a mathematical genius to work out that a typical 30 to 40Gb RAID array will fill up rapidly at this rate, and once the drive is full the server will either stop logging or else stop serving pages.
So how do you add disk-space checking to your monitoring system? Well, because of the way we constructed the previous content-checking system, the easiest way would be to get the Web server itself to report on the free space, and then extend your content-checking technique to find and report on any problems discovered. This is easy to do if your Web server supports a scripting language. We'll show you an example using ASP/IIS on NT Server (or PWS if you run a workstation flavour of Windows), because most readers will have access to a Windows machine of some sort; those of you using different platforms should be able to adapt the code.
The first thing to do is dump the following ASP page onto the server somewhere. The more paranoid among you will probably give it an obscure name and password protect it - we tend to call it freespace.asp and dump it in the root directory.
<% response.write "The following drives have less than 1Gb free:" & chr(13) & chr(10)
Set fs = CreateObject("Scripting.FileSystemObject")
Set dc = fs.Drives
For Each d in dc
cc = freespace(d.driveletter)
if cc < 1024 then
response.write d.driveletter & ": - " & cc & chr(13) & chr(10)
end if
Next
function FreeSpace(drvPath)
Set d = fs.GetDrive(fs.GetDriveName(drvPath&":"))
if d.isready and d.drivetype = 2 then
freespace = int(d.FreeSpace/1024/1024)
else
freespace = 99999
end if
End Function
%>It's pretty easy to see what this is doing: it loops through all the drives on the machine, checks to see that they're hard drives and writes some output if the space left is less than 1Gb. That 'd.isready' call is important, as the FileSystemObject considers it an error to read the drive type of a CD-ROM if there isn't a CD in the drive. Silly, but easily coded around.
Note that this ASP script outputs plain ASCII text rather than HTML, as there are no <HTML>, <HEAD> or <BODY> tags, and lines are terminated with carriage return/line feed rather than <BR> or <P>. We do it this way because it makes it easier to process using our content-checking techniques, the code for which would be something along these lines:
del diskspace.txt
wwwget -a http://www.internet.site/freespace.asp diskspace.txt
find "-" content.txt
goto d%ERRORLEVEL%
:d0
echo disk space problems found
blat diskspace.txt -server mail.isp.co.uk -t user@sms.genie.co.uk -s disk_space
:d1What this does is request a copy of the page using wwwget, then uses Find to search for the "-" character. If one is spotted we know there's a disk space problem on at least one drive, so an alert message is sent.
You may have servers within your Web-hosting facility that don't actually have Web servers running on them - perhaps database servers or for controlling authentication. You might also have some Web servers running IIS3 rather than IIS4, and the FileSystem-Object within IIS3 won't be able to run this code. So what are the alternatives available? Well, if you stick to the rules laid out (see Web Business, issue 63), there are two main choices. One option is to stay DOS-based by using the NET USE command to create a network drive, request its directory listing and pipe the results through FIND to extract the free space figure shown at the end. Then use the NET command to delete the network drive again. You may be thinking 'That's stupid. Why not just get a directory listing using a UNC-style path?' Unfortunately, that won't work, as an UNC-style directory listing tells you everything except the free space: another of those annoying hiccups that are easy to code around.
Another option would be to use the often-overlooked Performance Monitor facility built into NT. Many people think this is just a way to display pretty graphs of CPU utilisation and so forth, but look closely and you'll find two important features: you can connect to other machines on your network, and Performance Monitor has an alert facility you can use to launch an application if a particular counter goes above or below some pre-determined level. You can use this to trigger Blat! and raise an alert if free disk space drops too low.
While you're poking around inside Performance Monitor, you might also set a few more alerts; CPU over 90 per cent, for example, or login errors. However, both of these techniques only work on local networks, whereas the beauty of our server-side script solution is that it will work on a server on the other side of the world. To do that with network drives or Performance Monitor, you'd have to use something like PPTP to tunnel though to the remote LAN.
So there you have it, server monitoring on a shoestring. For the sake of a few minutes setting up, you can rest assured that your e-commerce servers won't die through lack of disk space. It has to be said, there's a multitude of tools out there that do all of these tasks properly, and we'll cover some of these in a later issue. In the meantime, for the sake of our sanity, can we please consider the subject of DOS-based server monitoring closed?
All articles Copyright CST Group Limited ©1997-2024
Let's Talk
Whether you have a new or existing project, we’d love to hear from you.
Our experienced team thrive on problem solving and working with your business goals in mind.