[hobbit] CPAN Modules

[Buchan Milne]

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 all
> or 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 server
> databases
>         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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Client.pm
Type: application/x-perl
Size: 3482 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100609/4a635318/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bb.pl
Type: application/x-perl
Size: 848 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100609/4a635318/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get.pl
Type: application/x-perl
Size: 1033 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100609/4a635318/attachment-0002.bin>