Hobbit versus Unicenter/TNG 🔗 link

I'm currently arguing with some PHB's who insist that Unicenter/TNG is
the "standard" monitoring tool and we're supposed to use that
exclusively.

Since I have the users on my side I do expect to win that struggle, but
if any of you have compared Hobbit with Unicenter/TNG I would be
interested to hear about it. Especially features you've found that 
Hobbit has, but TNG doesn't. I know of quite a few, but any ammunition
is welcome.

If you prefer, contact me directly instead of through the list.


Regards,
Henrik

On 2/7/07, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:

Last time I looked at TNG's Web Monitoring Option, it sucked big time.
 The agent would crash if you clicked the icons in the agent view too
quickly; when restarted, the agent would automatically re-enable all
disabled checks; in the Event Console, the reports would all be
labelled with the agent's nodename instead of the nodename that had
the problem.  I could go on...

I have a bunch of shell scripts that monitor a variety of web pages -
several airlines, travel companies, etc.  I'm using Hobbit for
displaying the results, because TNG just doesn't have the same
capabilities.  I can insert bits of web pages into the reports, links
for manual checks, and so on.  The monitoring folks then click through
the red/yellow dot to see what I found that was bad or missing, then
click through the link to try it for themselves before waking people
up.  While it might be possible to configure TNG to show the messages,
at present it wouldn't show a url as a clickable link.

Possibly the biggest point in Hobbit's favour around here is that you
can access it through a web browser - any web browser on any OS.  I
don't think TNG has that option, unless it was recently added.  If I'm
at home and get a call about it, I can VPN to the company network, pop
up a browser and take a look.  I don't have to have about 100Mb of TNG
installed to be able to view the pages.

I don't know about the recent versions of TNG, but back in 1998
TNG-2.1 (2.0 maybe?) took around 40 minutes to bring up the 2D map.

I'm running Hobbit in RedHat 7.2 on a single-cpu 733MHz DL380, picking
up about 2500 reports on 650 hosts.  I doubt TNG could manage that.  I
only have Hobbit's client-side running on a few of my own servers,
because my own PHBs have decreed that TNG is the only monitoring tool
to use.  Oh, and NetCool.  Oh, and BMC Patrol  Oh, and HPOpenView.
Oh, and Mercury.  Oh, and OnCentauri...

Ralph Mitchell

user-00a5e44c48c0@xymon.invalid 02/07/07 9:50 AM >>>

Still does, at least as recent as about 6 months ago.

TNG's reporting capabilities are horrible.  

Possibly the biggest point in Hobbit's favour around here is that you can access it through a web browser - any web browser on any OS.  I don't think TNG has that option, unless it was recently added.  If I'm at home and get a call about it, I can VPN to the company network, pop up a browser and take a look.  I don't have to have about 100Mb of TNG installed to be able to view the pages.

Yep!! Light on the server side and light on the client side.  TNG/Unicernter is unbelievably gigantic, enourmous, and otherwise unecessarily complex.  It takes a team of engineers and more than a few servers to get even close to some of the functionality and usefulness of Hobbit.

It only takes about 20 minutes now, and it defaults back to the view it wants to show you every time.

Funny that should come up.  We've gotten BB (and slowly introducing Hobbit) and Netcool very well integrated.  It makes the PHBs happy, both because they don't have to spend tons of cash to replicate BB/Hobbit, and they get their golf outings and other unnamed perks paid for by the vendors.

I know at a previous job, I was told the only reason we went with software from vendor X rather than vendor Y is because vendor X could get us tickets to every home Baltimore Orioles game.  I couldn't

believe someone was willing to actually say that.

Paul

Why does it seem that all hobbit administrators are instantly rebelling?
Our monitoring solutions are supposed to be Nagios and Big Brother, they
are what the corporate gurus sitting on their chair decree and what
we...ignore.  I digress, but the point is that my predecessor did some
research into various monitoring solutions (and while I don't have his
notes) he chose hobbit because of the community, Henrik's willingness to
lend a hand when needed and of course it's free (an easy way to make a
manager sign-off on it :) ).

The point is that now my company is adopting hobbit as part of the
global monitoring project because it is so extendable, efficient and
easy to use and while it is not expected to be used in North America it
will be used on all other sites (well...eventually) so what started as a
6 site rebellion is fast becoming a global standard across ~20-30 sites.

One other thing I am confused about is that companies invariably benefit
from expertise in their company, especially when using a utility such as
hobbit - which is why I was afforded the luxury of reading through some
of the hobbit man-pages when I first started, so ask yourself this who
knows more about a program than the person who programmed it?!? So
surely your company benefits a lot more from your input/expertise than
mine, and mine has helped a great deal, or so I am told.

Jason.

-----Original Message-----
From: Ralph Mitchell [mailto:user-00a5e44c48c0@xymon.invalid] 
Sent: 07 February 2007 14:51
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit versus Unicenter/TNG

On 2/7/07, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:

Last time I looked at TNG's Web Monitoring Option, it sucked big time.
 The agent would crash if you clicked the icons in the agent view too
quickly; when restarted, the agent would automatically re-enable all
disabled checks; in the Event Console, the reports would all be
labelled with the agent's nodename instead of the nodename that had
the problem.  I could go on...

I have a bunch of shell scripts that monitor a variety of web pages -
several airlines, travel companies, etc.  I'm using Hobbit for
displaying the results, because TNG just doesn't have the same
capabilities.  I can insert bits of web pages into the reports, links
for manual checks, and so on.  The monitoring folks then click through
the red/yellow dot to see what I found that was bad or missing, then
click through the link to try it for themselves before waking people
up.  While it might be possible to configure TNG to show the messages,
at present it wouldn't show a url as a clickable link.

Possibly the biggest point in Hobbit's favour around here is that you
can access it through a web browser - any web browser on any OS.  I
don't think TNG has that option, unless it was recently added.  If I'm
at home and get a call about it, I can VPN to the company network, pop
up a browser and take a look.  I don't have to have about 100Mb of TNG
installed to be able to view the pages.

I don't know about the recent versions of TNG, but back in 1998
TNG-2.1 (2.0 maybe?) took around 40 minutes to bring up the 2D map.

I'm running Hobbit in RedHat 7.2 on a single-cpu 733MHz DL380, picking
up about 2500 reports on 650 hosts.  I doubt TNG could manage that.  I
only have Hobbit's client-side running on a few of my own servers,
because my own PHBs have decreed that TNG is the only monitoring tool
to use.  Oh, and NetCool.  Oh, and BMC Patrol  Oh, and HPOpenView.
Oh, and Mercury.  Oh, and OnCentauri...

Ralph Mitchell

On 2/7/07, PAUL WILLIAMSON <user-b9fa55f5c833@xymon.invalid> wrote:

user-00a5e44c48c0@xymon.invalid 02/07/07 9:50 AM >>>

To be fair, we did have about 40,000 objects in the database.

I set up BB (v18b3) when I sat on the monitoring desk for a while.
The officially blessed tool is TNG, so it would be a question of
integrating BB/Hobbit reports into TNG, rather than the other way
around.  If I *really* had to do it, my scripts could write a log file
for TNG to watch, instead of sending the the Hobbit status message.

I've heard of golf games changing PHBs minds.

Ralph Mitchell

On 2/7/07, Jones, Jason (Altrincham) <user-ee957b46acd2@xymon.invalid> wrote:

Around here, it's a question of "if it breaks, who can we blame??"
However, my recently-ex manager's attitude was "whatever it takes to
get the job done".  She asked me to work the monitoring desk for
awhile, at a time when the web checks consisted of a list of URLs to
visit twice per shift.  It didn't take many nights to get some scripts
together to feed BB, thereby saving about 1/2 head per shift and
running the checks every ten minutes.  That was back in 2000.  My old
DL380 has gone down 3 times since then - once to move it, once was a
kernel crash, once when it blew its power supply - whereas the TNG
infrastructure seems to need booting and/or reinstalling regularly.
That power supply blowout was my excuse to switch to Hobbit - I had a
working Hobbit server being fed by BB, with all the scripts almost
ready to run.

We're an IT outsourcing company.  I'm not anywhere near the sales
side, but I've heard that prospective clients generally want to know
how we're going to monitor their stuff.  I suppose they get a nice
warm fuzzy feeling when the sales critter tells them about the
multi-million-dollar monitoring solutions we have available.  Telling
a customer the monitor is free and light enough to run on a 486
w/FreeBSD just isn't going to win contracts... :)  The word slowly
seeps out, though.  BB, and now Hobbit, regularly catches things that
TNG doesn't see, including excessive cpu use in some TNG boxes - yep,
I'm running snmpwalk against some TNG infrastructure and feeding
Hobbit the results.  Seems like TNG isn't so hot at watching itself
for some reason...

Ralph Mitchell

Back when we had an IBM mainframe, CA was desperately trying to find
ways to "give" us Unicenter, until our VP told them that he'd drop them
as an accepted vendor if he saw another proposal in the next six months.

So -- we never did Unicenter.

We did BMC Patrol on AIX -- and never could get viable alerting from the
product.

I have yet to see ANY of the vendor-provided tools that work with a
lightweight client for viewing the current status. Hobbit lets me check
things with any browser, on any OS -- and when you've only got dial-up
access to work with, this is *critical*. I don't have the time to load a
big honkin' java application (tivoli) or an ugly X-windows app (BMC)
over dialup to see what's down.

Big Brother and Hobbit and a handfull of home-brew scripts dropped BMC
out of our shop and saved us over $40,000 per YEAR in licensing.

Tom Kauffman
NIBCO, Inc

-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: Wednesday, February 07, 2007 4:15 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] Hobbit versus Unicenter/TNG

I'm currently arguing with some PHB's who insist that Unicenter/TNG is
the "standard" monitoring tool and we're supposed to use that
exclusively.

Since I have the users on my side I do expect to win that struggle, but
if any of you have compared Hobbit with Unicenter/TNG I would be
interested to hear about it. Especially features you've found that 
Hobbit has, but TNG doesn't. I know of quite a few, but any ammunition
is welcome.

If you prefer, contact me directly instead of through the list.


Regards,
Henrik

CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.

Henrik,

  I am so sorry to hear about your situation.  I hope sanity will
reign in the end.  Here are some of my suggestions:

*  Don't immediately turn the issue into a technical battle of TNG vs.
Hobbit.  If you have the time, read "Getting to Yes" a book on
negotiations.  Start with identifying what "monitoring" is supposed to
do in PHB-speak: maximize service availability to customers, provide
technicians the ability to quickly diagnose problems, ensure the
functionality of the environment after changes.  The point being, try
to establish the goals everyone can agree on.  You will lose the PHB
vs. technician fight based solely on "features."

*  Be prepared to accept using both tools is fine.  Even recommend it,
especially if the organization is prepared to do "cost-benefit"
analysis for the effort with NPV or ROI.  Practically speaking,
running both tools together would be much better than just TNG.

*  Ask about the process to get hobbit on the "approved software"
list.  If your company has IT Governance, they might be a good spot to
start.

*  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.   Big
tools are "certified" for security, hobbit is a "bunch of people in
their basements."  Craft the replies in business and financial terms
that are quantifiable.  Yes, I am the author of hobbit, with a
development and user community of over X,XXX.  The code is written in
C, a standard for all Computer Science programs, with XXX,XXX
programmers in the world.

That's all for now.  For the sake of the entire hobbit community, good luck!

Scott

On 2/7/07, Kauffman, Tom <user-3feba9e60a8b@xymon.invalid> wrote:

On Wed, 2007-02-07 at 13:16 -0500, Kauffman, Tom wrote:

I've even written an app to display the red alerts on my Cisco IP phone!
#!/usr/bin/perl

use Cisco::IPPhone;
my  $mytext = new Cisco::IPPhone;


my @redboard = `bb localhost "hobbitdboard color=RED
fields=hostname,testname"`;
my $niceline;
foreach my $red (@redboard) {
        $niceline .= join(",",split(/\|/,$red))."\n";
};

$mytext->Text( { Title => "Red Alerts", Prompt => "Red Items in Hobbit",
                           Text => $niceline});
$mytext->AddSoftKeyItem( { Name => "Update", URL => "SoftKey:Update",
                           Position => "1" });
$mytext->AddSoftKeyItem( { Name => "Exit", URL => "SoftKey:Exit",
                           Position => "2" });
print $mytext->Content;


I could, if I were willing to do a little bit of work, get it to
acknowledge the alerts with the touch-screen... Let's see CA do that!

CA is the only "official" monitoring solution here too, but nobody has
got it working.  In the mean-time I have real-time displays of my hobbit
system (and my hobbit-based bbmap) at the NOC.

-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX
Austin Energy
http://www.austinenergy.com

On Thu, Feb 08, 2007 at 08:01:08AM -0500, Scott Walters wrote:

<big snip>

Thanks - I appreciate your comments, and they do match up pretty well
with my own thoughts about how to tackle this.

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.

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.

(The 0.5 is only for running Hobbit - developing Hobbit is another
issue, but that happens mostly in my spare time).

You will lose the PHB vs. technician fight based solely on "features."

The only reason Hobbit exists is that I secured the support of some
fairly high-up people as well as a lot of customer-contact people (and
external customers, even) right from the start. When two of our top-3
customers insist on having access to Hobbit as a requirement for
renewing their contracts, I have a pretty strong case.

When I do use the "feature" argument, I know I have to focus on the
features that bosses understand. There are lots of neat tech stuff
in Hobbit, but that doesn't sell Hobbit - the abundance of graphs
and (SLA) reports do, as well as the positive feedback the boss gets
from our customers.

*  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).

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.

For the sake of the entire hobbit community, good luck!

Thanks, I'll let you know how it works out.


Regards,
Henrik

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

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.

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.

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.

Figure out ways to explain how Hobbit will make their jobs and life
better.  Hobbit is better than XYZ won't be an effective
"sell."  Example:  Could using Hobbit mean they get less phone calls in the
middle of the night?

| Thanks, I'll let you know how it works out.

Cool.  And if any of your bosses/decision makers play golf, if they ever
make it to the NYC/Philly area, I'd be happy to take them out for 18.

My name is Scott, and I am a golfer.

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
user-6a0b8b0f0ae1@xymon.invalid

user-6a0b8b0f0ae1@xymon.invalid 02/15/07 8:39 AM >>>

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.

What is meant by "different data points" ?

When we got into that discussion here, I just did a sort unique on the test column.  That alone was over 300 items.  After that, the vendor hung their head and left.

PAUL WILLIAMSON wrote:

Honestly, I'm not sure what they meant when they said that.  I take it to mean a total count of all the individual pieces of data that are recorded in an rrd or status display during a round of testing, both from network tests, server side tests, and client side tests.  My mysql monitoring script alone collects 83 different data points each run, and that's just one of a handful of custom scripts we are using to watch our operations.  I know I have an *incredible* amount of data and way more than anyone else is going to be able to collect with an off the shelf tools.

If there were some easy way to see how many different values were inserted into my rrd files in about a 5 minute period, I'd be golden.

When we got into that discussion here, I just did a sort unique on the test column.  That alone was over 300 items.  After that, the vendor hung their head and left.

I'm sure I could do the same, given the chance.  ;)
-- 
Tom Georgoulias
Systems Engineer
McClatchy Interactive
user-6a0b8b0f0ae1@xymon.invalid

On Thu, Feb 15, 2007 at 08:39:33AM -0500, Tom Georgoulias wrote:

The "easiest" way is to look at the size of the RRD files. An RRD file
has a fixed size, and a 2-dataset RRD file is double the size of a
1-dataset RRD file. So if you add up the size of all the RRD files and
divide by the size of a 1-dataset RRD file (like the la.rrd files), you
have the number of datasets you're tracking for graphs.

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.

The only really interesting statistic in the "hobbitd" column is the
"Incoming messages/sec" value: This tells you how many test results are being processed by Hobbit every second, so to your boss this would be your
"sustained transactions/second" (TPS) number.

Another useless number to throw around is found on the "bbgen" column
statistics: The "Status messages" number there are the total number of
individual status "dots" on your web display: A "disk" status, a
"memory" status, an "http" status and so on.


Regards,
Henrik