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.

Since a similar discussion is being held where I work. Never thought that would happen given the success we've had with Hobbit and the massive customizations I've added, but that is another discussion entirely.

Anyway, one of the useless stats that is being thrown about by a third party is the number of different data points they will monitor, and I was asked to provide a similar number of my own. I have about 9 custom scripts mixed up on the server and client sides, each of which gather anywhere from 4 to 40 data points per script.

Looking at the data under hobbitd, is there an easy way to determine how much data (in the form of individual data points going into an RRD file) monitored coming in from the clients? I found the network tests data under the bbtest column, but figuring out what really matters under the hobbitd column is a bit more challenging. Most of my client data comes in the "status" channel, but some is also going into the data channel.

If it helps at all, here are my current hobbitd stats:

Statistics for Hobbit daemon Up since 13-Feb-2007 07:59:08 (2 days, 00:30:01)

Incoming messages : 1980761

• status : 1694626
• combo : 240323
• page : 5924
• summary : 0
• data : 33464
• client : 1031
• notes : 0
• enable : 3
• disable : 19
• ack : 0
• config : 0
• query : 1160
• hobbitdboard : 2850
• hobbitdlog : 697
• drop : 8
• rename : 0
• dummy : 580
• ping : 0
• notify : 22
• schedule : 44
• download : 0
• Bogus/Timeouts : 10 Incoming messages/sec : 11 (average last 300 seconds)

status channel messages: 1691796 (1 readers) stachg channel messages: 3621 (1 readers) page channel messages: 2327 (1 readers) data channel messages: 33472 (1 readers) notes channel messages: 0 (0 readers) enadis channel messages: 0 (0 readers) client channel messages: 935 (1 readers) clichg channel messages: 0 (1 readers)

-- Tom Georgoulias Systems Engineer McClatchy Interactive tomg at mcclatchyinteractive.com