Definitly use a proven product (++Roger :-); I suggest nagios (ex NetSaint).

• scales well (one machine checking itself to multiple nagios-machines checking multiple networks and each-other)
• easily extended using perl :-)

I second the vote for Nagios, it's really a great piece of open source software. We love it up at school, and I've heard rumors of a few local communication companies using it as well.

:)

You'll need to run your script via a scheduler like cron (a UNIX daemon, but available for Windows, which has its own scheduler called "Task Scheduler", IIRC), or set up your program as a service (in Windows) or a daemon (*nix). If you choose to do the latter, have a look at the thread "Install a perl script as a Win NT/2000/XP service.". I would strongly recommend you set up your script using the scheduler.

I've monitored services in several previous gigs. That included using off-the-self products like mon, big brother, and mrtg, and products written from scratch, which either ran 24/7 or ran from cron. Sometimes the monitor ran on the same box that performed the service - and sometimes the monitor was a spin in a web, monitoring services of a range of machines. Sometimes, all they did was producing graphs, some products send out messages to pagers and phones, some tools tried to fix problems instead of reporting them, and sometimes they did all three. And I've written monitors to monitor my monitors.

I've written scripts as simple as:

#!/bin/sh
if ping -c 1 'xxx.xxx.xxx.xxx'
then :
else /etc/init.d/network restart
     echo "Restarted the network"
fi
[download]

Abigail

About four years ago while at a certain acronymed telephone company, we implemented a system from scratch using a mixture of Sybase, Perl, and a Servlet front end. At the time, I thought it was really cool. Then I realized how many products were out there that did this better.

The awkwardness of collating all of this data, constructing packets, and writing a daemon to collect these packets led to some complexity that could be avoided by using more mature products.

However, it did have some good things going for it. It used one-way communication using UDP from the monitored servers back to the "reporting" server. No TCP, No database connections, from the production servers to the monitoring station. Perhaps it was limited in functionality, but it was stable and used very low resources.

If I had to reimplement a system from scratch again, I'd probably still use a UDP-like system, but would consider serializing data (YAML possibly) and putting the monitoring process on a crontab rather than running it as a daemon.

Anyhow, long story short, it was a pretty successful project, but we reinvented a lot of wheels and it wasn't the most extensible system when we got through with it. Picking up an off-the-shelf product would have probably been a better idea. At the time, though, I doubt many (free) solutions were ready for prime-time, especially on the obscure platforms we supported.