<br>
<br><tt><font size=2>Buchan Milne <bgmilne@staff.telkomsa.net> wrote
on 09/06/2010 07:10:54 PM:<br>
<br>
> [image removed] </font></tt>
<br><tt><font size=2>> <br>
> Re: [hobbit] CPAN Modules</font></tt>
<br><tt><font size=2>> <br>
> Buchan Milne </font></tt>
<br><tt><font size=2>> <br>
> to:</font></tt>
<br><tt><font size=2>> <br>
> hobbit</font></tt>
<br><tt><font size=2>> <br>
> 09/06/2010 07:15 PM</font></tt>
<br><tt><font size=2>> <br>
> Cc:</font></tt>
<br><tt><font size=2>> <br>
> david.peters</font></tt>
<br><tt><font size=2>> <br>
> Please respond to hobbit</font></tt>
<br><tt><font size=2>> <br>
> On Wednesday, 9 June 2010 00:24:27 david.peters@industry.nsw.gov.au
wrote:<br>
> > As I use perl mostly for interfacing to hobbit for tests, reports
etc I<br>
> > have quite a number of perl modules floating around.<br>
> > <br>
> > Given that CPAN is the easiest way to upload, install manage
etc, I have<br>
> > installed the modules there.<br>
> <br>
> Well, it's fine for distribution, installation is debatable (I <br>
> usually use the <br>
> distro package manager, but my distro has > 2000 CPAN modules).<br>
> <br>
> However, where should the VCS for this be? How about a perl subdirectory
on <br>
> xymon svn on SF?<br>
> <br>
</font></tt>
<br><tt><font size=2>Agreed. Is already in svn just in a different repository.
Happy to move it.</font></tt>
<br>
<br><tt><font size=2>> > I have created a top level Module called
Xymon which is simple a place<br>
> > holder.<br>
> > <br>
> > So far I have uploaded Xymon::Client which provides a perl interface
to<br>
> > sending status updates:<br>
> <br>
> I started on one a few months ago, but no one seemed interested at
the time. <br>
> The next thing I needed for myself was an interface to parsing bb-hosts
to a <br>
> page structure.<br>
> </font></tt>
<br>
<br><tt><font size=2>We do that here via the database interface. Eg by
owner and location and application.</font></tt>
<br><tt><font size=2><br>
> I've attached what I had.<br>
> <br>
> > <br>
> > #!/usr/bin/perl<br>
> > <br>
> > use Xymon::Client;<br>
> > <br>
> > my $xymon = Xymon::Client->new(.......);<br>
> > <br>
> > $xymon->send(.....);<br>
> > <br>
> > Documentation for this is included on cpan and when you install
the<br>
> > module.<br>
> > <br>
> > The other module I have installed is Xymon::Monitor::Informix
which tests<br>
> > connectivity to remote Informix Databases<br>
> > This updates a test called database for servers that run informix<br>
> > databases and lists the status of each database on the status
screen.<br>
> <br>
> How does this compared to dbcheck.pl from </font></tt><a href="http://hobbit-perl-/"><tt><font size=2>http://hobbit-perl-</font></tt></a><tt><font size=2><br>
> cl.sourceforge.net/ ?<br>
> <br>
> > <br>
> > I have quite a few more to add but I was hoping that anyone else
that has<br>
> > perl scripts, May add them there as modules. If help is required<br>
> > I can assist.<br>
> <br>
> Well, I was aiming to port some of mine to my Xymon::Client module.<br>
> <br>
> <br>
> > Some of the upcoming releases of modules include:<br>
> >         Xymon::Server which provides an interface
to the various server<br>
> > environment variables + some utility functions such as redrawing
the<br>
> > screen.<br>
> <br>
> I don't know if it should draw the screen, however if it can parse
various <br>
> config files and provide structures that can be used to compose a
view in a <br>
> templating system, that would be better.<br>
> </font></tt>
<br>
<br><tt><font size=2>sorry I meant running bbgen using the config parameters
out of hobbitserver.cfg,</font></tt>
<br><tt><font size=2>which is useful after updating various files or acknowledging
events.</font></tt>
<br>
<br><tt><font size=2><br>
> For example, to provide an Ajax view, redrawing the screen itself
in perl is <br>
> useless, but providing the structure in JSON is useful ....<br>
> <br>
> >         Xymon::Server::History which returns
a hash of all events for all<br>
> > or selected servers - I currently use this for generating excel
reports.<br>
> >         Xymon::Server::Clients which provides
an interface to the<br>
> > hobbitclient.cfg file and includes a web interface.<br>
> >         Xymon::Server::Alerts which provides
an interface<br>
> > hobbit-alerts.cfg<br>
> > <br>
> >         Xymon::Monitor::MSSQL which provides
a status test for sql server<br>
> > databases<br>
> >         Xymon::Monitor::Oracle which provides
a status test for oracle<br>
> > servers<br>
> >         Xymon::Monitor::SunContainer which
provides a way fo testing<br>
> > Containers running on a Solaris node.<br>
> > <br>
> > There are a few others that I have but that is enough for now.<br>
> > <br>
> > BTW we still use a database to store all information about our
servers and<br>
> > routers and then use this to generate the bbhosts and include
files. This<br>
> > includes<br>
> > a screen under INFO for a host that provides this information
within<br>
> > hobbit. <br>
> <br>
> Well, in devmon, I have some work in my local checkout which populates
some <br>
> discover-related information into a database (e.g., cdp neighbours,
IPs, <br>
> routes).<br>
> <br>
> > Allows us to do advanced searching based on other parameters,<br>
> > using an advanced search<br>
> > web screen within hobbit.<br>
> > <br>
> > Last time I spoke of the database there seemed to be very little
interest<br>
> > in it so it has stayed where it is and hasn't been used anywhere
else.<br>
> <br>
> I think having a database is useful. I think there was resistance
to having <br>
> all the monitoring depend on a database.<br>
> <br>
> For example, if configuration information is to be in a database,
itshould be <br>
> dumped out, so that no matter what happens to the database, monitoring
will <br>
> work.<br>
> <br>
</font></tt>
<br><tt><font size=2>Sorry, Xymon is not tied to the database in any way
other than that the database</font></tt>
<br><tt><font size=2>is used to create the bbhosts file when a change is
made. And the info screen for a server</font></tt>
<br><tt><font size=2>contains a link to a web view of the data. Perhaps
some diagrams and screenshots were</font></tt>
<br><tt><font size=2>in order.</font></tt>
<br>
<br>
<br><tt><font size=2>> > We have applications tied to servers in
the database<br>
> <br>
> Well, service dependency information should be captured, in order
to easily <br>
> provide a services view. While this can be hacked in at present with
the <br>
> combo-test, a better view is required (amongst other issues).<br>
> <br>
</font></tt>
<br><tt><font size=2>the bbhosts creation routine generates pages based
on things such as application/service.</font></tt>
<br>
<br>
<br><tt><font size=2>> > and use it for a web<br>
> > based outages application. When an outage is logged, not only
does it send<br>
> > an email<br>
> > to subscribed users with details of the servers and the applications,
it<br>
> > also automagically disables that host(s) in hobbit for the period
of the<br>
> > outage.<br>
> <br>
> Well, this should probably be migrated onto the developer list, and
<br>
> I think we <br>
> should discuss the goals before finalising requirements/design etc.<br>
> <br>
</font></tt>
<br><tt><font size=2>Agreed most of the work required from a xymon public
perspective is design and integration,</font></tt>
<br><tt><font size=2>not coding.</font></tt>
<br>
<br>
<br><tt><font size=2>The trick I guess is to get from a working system
here to a publicly available group of add-ons.</font></tt>
<br>
<br><tt><font size=2>> Regards,<br>
> Buchan<br>
> [attachment "Client.pm" deleted by David Peters/DII/NSW]
[attachment<br>
> "bb.pl" deleted by David Peters/DII/NSW] [attachment "get.pl"
<br>
> deleted by David Peters/DII/NSW] To unsubscribe from the hobbit <br>
> list, send an e-mail to<br>
> hobbit-unsubscribe@hswn.dk<br>
</font></tt>
<p style="font-family:Arial;font-size:9px;font-style:normal;font-weight:normal;text-decoration:none;text-transform:none;color:000000;"><br><br>
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.<br><br>
</p>