Re: {bb} An idea for a future release

[Henrik Olsen <henrik@iaeste.dk>]

On Tue, 30 Nov 1999, Nick Metrowsky wrote:
> Folks,
> 
> We were talking here about an improvement to BB, which could help ease
> management of clients, especially when new releases of BB are
> introduced. This idea may have been discussed before, in some form, on
> BB list. The idea is to modified the server bbd so it can "manage" all
> clients from a single file.  
> 
> I suggest creating a file (bb-services) on the main BB server, which is
> read by bbd into memory at each BB cycle. bb-services is designed to
> contain threshold parameters for various services. Usually, bb-dftab,
> bb-proctab and /etc/bbdef.sh need to modified on each client, if the
> thresholds vary from one client to another. The bb-service file would
> contain the following:
> 
>                                Thresholds
> hostname|monitored service|green|yellow|red|monitored item 
This idea has merit, but isn't quite there yet.
There are too many tests that don't work by comparing numbers for this to
work in the way described.

Instead I think a way for the client to request parameters for a
host.service would be a better solution, that way the server won't have to
know anything about the way the test is actually done.
Eg.  
adagger,colorado,edu.disk
/usr:92:98
/home:88:93
/db:100:101

Or:
adagger,colorado,edu.procs
sendmail|bbd
http

> example:
> 
> localhost|cpu|85|90|95|
> localhost|disk|85|90|95|
> localhost|swap|25|20|15|
> localhost|msgs|1|2|3|
> localhost|procs|1|2|3|
localhost don't make sense unless it's meant to be the default value and
even then it should be named so.

> adagger.colorado.edu|cpu|80|90|95|
> adagger.colorado.edu|disk|80|90|97|/usr
> adagger.colorado.edu|swap|20|15|10|
> adagger.colorado.edu|procs|1|2|3|xeon
> adagger.colorado.edu|procs|1|2|3|zephyr
> 
> Because bbd receives information from the clients bb-local via its' bbd,
> the bbd on the server can parse the information from the client, compare
> it to the above parameter file, and then do its normal processing. The
> main change is that the client will just send back the timestamp, host
> name, monitored service, and the results of the command ran from
> bb-local. That is, the clients bb-local will just become a raw data
> gathering tool, it will:
> 
> 	1. Perform a df.
> 	2. Perform a ps (full listing depending on your UNIX) to
>            get process information.
> 	3. Review the messages file and send back what it found.
> 	4. Obtain the CPU data as it does now.
> 	5. Perform whatever extensions you may have, we have a
> 	   swap space utilization script.
> 
> Also, if a host is not specified, the "localhost" host name can be used
> for defaults or something else of the author's choosing.
> 
> In the server's bbd, it would scan the information sent back from the
> client (compare it to the information read into memory from
> bb-services), generate the status, and then continue to perform its
> existing functions. The clear and purple status will be generated as it
> is today.
> 
> So, this proposal to to make the server bbd smarter and to make the
> clients nothing more than data gatherers. The end result, the client
> would require a minimum of files for BB and the management of BB will be
> centralized.
> 
> Contribution and expansion of this idea are most welcome; please send
> your comments to bb@bb4.com so everyone can view this discussion.
> 
> Nick
> 
> 

-- 
Henrik Olsen,  Dawn Solutions I/S       URL=http://www.iaeste.dk/~henrik/
  (Gulliver visits some places.)
  Lilliputian:We're small.  Brobdingnagian:We're big.  Horse:We can talk.
  (Gulliver goes home.)           Gulliver:Humanity sucks. I hate people.
              Gulliver's Travels by Jonathan Swift; Book-A-Minute version

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list, or to subscribe to the bb-digest list
send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
subscribe bb-digest in the BODY of the message.