Buchan Milne <user-9b139aff4dec@xymon.invalid> wrote on 09/06/2010 07:10:54 PM:
[image removed]
Re: [hobbit] CPAN Modules
Buchan Milne
to:
hobbit
09/06/2010 07:15 PM
Cc:
david.peters
Please respond to hobbit
On Wednesday, 9 June 2010 00:24:27 user-1ccd046c8510@xymon.invalid
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?
Agreed. Is already in svn just in a different repository. Happy to move it.
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.
We do that here via the database interface. Eg by owner and location and application.
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.
sorry I meant running bbgen using the config parameters out of hobbitserver.cfg,
which is useful after updating various files or acknowledging events.
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,
itshould be
dumped out, so that no matter what happens to the database, monitoring
will
work.
Sorry, Xymon is not tied to the database in any way other than that the database
is used to create the bbhosts file when a change is made. And the info screen for a server
contains a link to a web view of the data. Perhaps some diagrams and screenshots were
in order.
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).
the bbhosts creation routine generates pages based on things such as application/service.
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.
Agreed most of the work required from a xymon public perspective is design and integration,
not coding.
The trick I guess is to get from a working system here to a publicly available group of add-ons.
Regards,
Buchan
[attachment "Client.pm" deleted by David Peters/DII/NSW] [attachment
"bb.pl" deleted by David Peters/DII/NSW] [attachment "get.pl" deleted by David Peters/DII/NSW] To unsubscribe from the hobbit list, send an e-mail to
user-095ef1c764a2@xymon.invalid
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of their organisation.