On Wednesday, 9 June 2010 00:24:27 david.peters at industry.nsw.gov.au wrote:
As I use perl mostly for interfacing to hobbit for tests, reports etc I have quite a number of perl modules floating around.
Given that CPAN is the easiest way to upload, install manage etc, I have installed the modules there.
Well, it's fine for distribution, installation is debatable (I usually use the distro package manager, but my distro has > 2000 CPAN modules).
However, where should the VCS for this be? How about a perl subdirectory on xymon svn on SF?
I have created a top level Module called Xymon which is simple a place holder.
So far I have uploaded Xymon::Client which provides a perl interface to sending status updates:
I started on one a few months ago, but no one seemed interested at the time. The next thing I needed for myself was an interface to parsing bb-hosts to a page structure.
I've attached what I had.
#!/usr/bin/perl
use Xymon::Client;
my $xymon = Xymon::Client->new(.......);
$xymon->send(.....);
Documentation for this is included on cpan and when you install the module.
The other module I have installed is Xymon::Monitor::Informix which tests connectivity to remote Informix Databases This updates a test called database for servers that run informix databases and lists the status of each database on the status screen.
How does this compared to dbcheck.pl from http://hobbit-perl- cl.sourceforge.net/ ?
I have quite a few more to add but I was hoping that anyone else that has perl scripts, May add them there as modules. If help is required I can assist.
Well, I was aiming to port some of mine to my Xymon::Client module.
Some of the upcoming releases of modules include: Xymon::Server which provides an interface to the various server environment variables + some utility functions such as redrawing the screen.
I don't know if it should draw the screen, however if it can parse various config files and provide structures that can be used to compose a view in a templating system, that would be better.
For example, to provide an Ajax view, redrawing the screen itself in perl is useless, but providing the structure in JSON is useful ....
Xymon::Server::History which returns a hash of all events for allor selected servers - I currently use this for generating excel reports. Xymon::Server::Clients which provides an interface to the hobbitclient.cfg file and includes a web interface. Xymon::Server::Alerts which provides an interface hobbit-alerts.cfg
Xymon::Monitor::MSSQL which provides a status test for sql serverdatabases Xymon::Monitor::Oracle which provides a status test for oracle servers Xymon::Monitor::SunContainer which provides a way fo testing Containers running on a Solaris node.
There are a few others that I have but that is enough for now.
BTW we still use a database to store all information about our servers and routers and then use this to generate the bbhosts and include files. This includes a screen under INFO for a host that provides this information within hobbit.
Well, in devmon, I have some work in my local checkout which populates some discover-related information into a database (e.g., cdp neighbours, IPs, routes).
Allows us to do advanced searching based on other parameters, using an advanced search web screen within hobbit.
Last time I spoke of the database there seemed to be very little interest in it so it has stayed where it is and hasn't been used anywhere else.
I think having a database is useful. I think there was resistance to having all the monitoring depend on a database.
For example, if configuration information is to be in a database, it should be dumped out, so that no matter what happens to the database, monitoring will work.
We have applications tied to servers in the database
Well, service dependency information should be captured, in order to easily provide a services view. While this can be hacked in at present with the combo-test, a better view is required (amongst other issues).
and use it for a web based outages application. When an outage is logged, not only does it send an email to subscribed users with details of the servers and the applications, it also automagically disables that host(s) in hobbit for the period of the outage.
Well, this should probably be migrated onto the developer list, and I think we should discuss the goals before finalising requirements/design etc.
Regards, Buchan