[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] A few questions before moving from bbgen to Hobbit
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] A few questions before moving from bbgen to Hobbit
- From: henrik (at) hswn.dk (Henrik Stoerner)
- Date: Tue, 9 Aug 2005 12:56:14 +0200
- References: <42F87E92.1090102@steria.com>
- User-agent: Mutt/1.5.6+20040907i
Hi Frederic,
On Tue, Aug 09, 2005 at 11:59:46AM +0200, Frédéric Mangeant wrote:
> first of all let me thank you for continiously improving Hobbit :-)
My pleasure.
> I'm preparing the "big move" from bbgen to Hobbit on a large production
> setup, and I have a few questions :
>
> - as I'm running Cacti to graph my servers, is there a way to remove the
> "trends" colum for all hosts ?
> I've disabled the rrdstatus and rrddata tasks, added TEST2RRD="" and
> GRAPHS="" but the "trends" column still show up, empty
You can do it on a per-host basis with the "notrends" setting in
bb-hosts, and this can be set as a default using the ".default."
host entry in bb-hosts.
You cannot do it globally, except by tweaking the code in hobbitd.c
that adds this pseudo status.
> - in the Administration -> Enable/disable page, is there a way not to
> show the reason of the disabled tests ?
> With a few hundred disabled tests, the page gets difficult to read
No, not without a code change.
Note that the enable/disable page also works on subpages, and in that
case it only shows those hosts that appear on the subpage. It might
still be many, but perhaps it helps.
> - in the "info" page of each host, would it be possible to show tests
> with no alert rules ?
> With bbgen they were displayed as "Ex.Services"
It would be fairly easy to add a line at the bottom saying "No alerts
defined for: disk, msgs, conn" ... is that what you're after ?
> - do you plan to add file inclusions to hobbit-alerts.cfg, like with
> bb-hosts ?
> We're several people managing the BB/Hobbit server, and this would be
> very useful.
It's on my list of pending cleanups. It needs a bit of work because
there's some logic currently that avoids re-loading the configuration
unless it's changed - and that currently works by looking at the time-
stamp of the file. This obviously has to change, and I haven't yet
decided what the best solution is.
Regards,
Henrik