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.