[hobbit] Hobbit versus Unicenter/TNG

[Gary Baluha]

>
> I'm not particularly worried about it. This issue has been there ever
> since we started using BB almost 6 years ago. The only reason why it's
> on the agenda now is that I have a new boss who has decided that we
> should get this issue resolved once and for all - he will not accept
> that Hobbit has this "second class" status in our NOC.


What is it about upper-management not embracing free-to-low-cost software
that does the job better and more efficiently than high-priced, bloated
commercial software?

And yes - this is all about politics. The Unicenter group is also the
> group responsible for manning our NOC - and given that it takes about 20
> people to run Unicenter here versus 0.5 (me) to run Hobbit, they are
>
somewhat reluctant to embrace it.


We occasionally run across the argument of whether we should use Hobbit or
Sitescope (very much NOT freeware) to monitor the status of several of our
websites. The argument that seems to come up frequently for us is the
misinformation that Hobbit isn't giving accurate results, and either not
paging out when it should, or paging out too often.  This is almost entirely
a political issue, since Sitescope is ALWAYS giving out false alerts.

> *  Be prepared to accept using both tools is fine.
>
> That is what we've been doing so far. I've always insisted that the
> thing we can monitor with TNG *will* be monitored by TNG - e.g. we never
> put "disk" alerts on the Hobbit critical-systems view, because those are
> supposed to be handled by TNG. (Whether TNG actually detects the problem
> then is another matter entirely).


To Sitescope's credit, it does do website content checking fairly decently,
out of the box.  While I can get similar functionality from Hobbit, some of
the more advanced content checks require external scripts to be written.
But it also seems that Sitescope's configuration sometimes gets corrupted,
and ends up sending out false alerts because even though the thresholds are
set correctly, it is using some other values other than what the web
interface shows.

It seems to be a common situation for multiple monitoring software to be
used, at least partly because some people just refuse to switch to another
(possibly better) monitoring solution.

> *  Anticipate the issues the PHB will "throw at you."  Sure hobbit is
> > great, but what if you leave Henrik?  No one else in the company/world
> > knows hobbit like you, that creates risk to the organization.
>
> This was/is a major reason for releasing Hobbit as Open Source. I
> frequentely point out how many people are downloading Hobbit, and the
> amount of traffic on the mailing list to show that it's "not just me in
> my basement". The list of companies using Hobbit that was put together
> last year is useful. And just a couple of days ago I received a mail
> from IBM, where they asked for permission to include some Hobbit
> documentation into one of their z/VM guides - this will also be handy to
> show that Hobbit is more than just my personal project.
>
>
In our case, there are occasional rumblings that since Hobbit isn't
commercial software, we can't get guaranteed response times for support of
the product.  The ironic thing is, nearly all of the Open Source software we
use provides FAR BETTER response times, and actually useful help from
various mailing lists and other community support forums than any of the
commercial products we use.

I am more or less turning into the resident Hobbit expert, and as I work
with Hobbit more and more, I realize just how easy it is to maintain, and
just how much you can do with it with just a little creativity in external
script writing.  While I do most of the modifications to the Hobbit
configurations here, it wouldn't take much effort at all for someone else to
pick up where I am.  Between this mailing list and the Hobbit man & help
pages, the information is far more readily accessible than any commercial
software I've used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20070209/fe754aeb/attachment.html>