[hobbit] big brother replacement
Mark.Deiss at acs-inc.com
Fri Nov 2 11:45:30 CET 2007
For a vanilla BB environment, you can have multiple BBDISPLAY entities but
the recommendation is that there is only one BBNET entity. A BBNET server
that is generating the pings out to the clients will be sending the ping
results to all of the BBDISPLAY entities (as defined on the BBNET host). If
you have multiple BBNET entities that ping the same servers, you will be
sending duplicated results as far as the individual BBDISPLAY servers are
concerned (the connection messages will be renamed to the host being
pinged). To support multiple BBNETs in a non-race environment requires
additional coding to carefully direct the BBNET results to not trip over
each other. The default behavior is to pump them out to whatever BBDISPLAY
is listed - you get the race conditions when you want all the BBDISPLAY
servers to monitor all of the BBNET hosts (i.e. want BBNET to send their
client-side tests to the BBDISPLAY entities - this will result in the BBNET
poll messages going out to all the BBDISPLAY entities also).
It's doable, hacked the heck out of the BB code base years ago to support
three separate BBDISPLAY/BBNET servers that provided redundant monitoring
over a client base and over each other. The goal in this case is the BBNET
directs its status messages to only a defined group of BBDISPLAY servers -
that will only have the one source of BBNET message traffic. The rest of the
BBNET's tests would be allowed to go to a wider distribution of BBDISPLAY
servers. These other tests would be keyed to the BBNET's server name so
there would not be a race or conflict conditions occurring on the BBDISPLAY
The BBNET race condition may seem minor - but then think about what is going
on with any RRD database entries - you would be updating if from all the
BBNET entities in a given time window. Resulting trends can get really
bizarre if the BBNET polls are originating from different network segments
with different response times. Bad times from one segment getting masked in
the trends due to updates occurring from another segment etc.
Main difference in the commercial version of BB over the BTF version is that
they added support for encrypting the communications from the clients to the
servers. I would place some value on that as some sites are running external
tests that are sending sensitive client information to the BBDISPLAY boxes.
There may be a difference in the level of included documentation - but who
reads the documentation anyways.....
Maybe Mr. Croteau and Mr. MacGuire will do a LBO and take BB private again.
From: Sloan [mailto:joe at tmsusa.com]
Sent: Thursday, November 01, 2007 8:05 PM
To: hobbit at hswn.dk
Subject: Re: [hobbit] big brother replacement
Josh Luthman wrote:
> That would be relative to Hobbit's bbtest I believe - someone correct
> me if I'm wrong, I'm just guessing here!
> I don't see any reason to think that script wouldn't work with some
> variable changes like BBNET=`$GREP BBNET $BBHOSTS | $GREP "^[0-9]" |
> $GREP -v "^\#"` but I am not an expert by any means!
Well, depending on what I hear on this list in the next day or so,
taking a crack at adapting the old bb failover script may be my best
> Getting back to the version 3.3 - after 1.9btf Quest starting selling
> the product. I don't know the exact history behind it but 1.9btf is
> what you get without paying for anything. I have worked with and
> continue to monitor a network with 3.1 or 3.2 (they decided to revert
> from 3.3 as it looks quite a bit different on the BBDISPLAY) and I
> honestly don't see what they've changed between 1.9 and 3.2. Most of
> the features of BB I heard of or read were not only already in Hobbit
> but were even better then what I had heard. Not to mention the dozens
> of BB scripts that can be relatively painless to migrate.
Ah, interesting - I always had the feeling that quest didn't do much of
anything with the code except put in some verbiage and legal warnings,
and tried to push their own proprietary and non linux-friendly stuff and
left the bb code base to slowly decay.
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xymon