Why PERL is better for writing monitors.

I know I'm treading on religion here, but hey - it's PERL.

So why is PERL better for writing monitors? Let's start with looking at the alternatives.

1) VBScript - this is a good language, for Windows. You are required to have the Microsoft interpreter installed on all the computers where you want to execute the code. This is great for interacting with WMI and Perfmon counters.

2) WinBatch - This is also a good language, but it is really designed for interaction with the GUI and manipulation of the system. I have used it to write monitors before, but there was no direct interaction with WMI - only perfmon counters.

3) Batch - well, yes you can still write batch files for monitoring Windows servers - but it is so painful and out dated, I'm not going to talk about it.

4) Shell - Unix administrators have know the power of Shell for decades, then again Unix offers all of the performance and monitoring data from the shell - so it is a natural fit, but it too has limitations such as doing anything besides interacting with the Operating System - while possible, it is limited in doing things like interact with a database.

OK - so here is PERL. It has been around for many years, it has been ported to all major OS platforms (including Mac OS X) and the modules - oh yes, the modules. The modules are what gives PERL endless power. Given a base install of PERL on Unix and Windows, I have the required modules to interact with WMI and Unix Shell.

Let's go beyond the basic monitoring, let's take the data and through it in a database. Using the PERL DBI interface module, I can open a database - insert the data and verify it. The DBI code could be the same on Windows and Unix.

There are generally more people and companies comfortable with using PERL on production servers. It is still widely used in web sites today, so even more skills are available in many companies.

OK - let the flaming begin.