On Thu, Dec 07, 2006 at 11:27:08PM +0100, Stef Coene wrote:
On Thursday 07 December 2006 23:01, Trent Melcher wrote:
Has anyone thought about or implemented a configuration database backend
for hobbit, primarily a database replacement for the hobbit-clients.cfg
and hobbit-alerts.cfg to start....these are a couple that I would like
to buils a webfront to and be able to give limited access to users so
they could modify thresholds and alerting capabilities when needed.
I did this about 4 years back for Big Brother using Informix, I was
able to setup thresholds and a replacement for the bb-host file inside a
couple tables in a database. However back then Big Brother was mostly
shell scripts and flat files for all its configuration. So adding hooks
into it for talking to a databse was easy. With hobbit its all compiled
code and Im not sure where to start, plus I don't have access to an
Informix database or the API's for it anymore so Im looking at mysql and
its api's for writing code in C.
We are thinking about using mysql for storing trends and status messages.
Be careful with the status messages, at least if you want to store the
current status in a DB. Historical status messages - those that are
currently stored in the histlogs/ directory - are OK, but for the
current status log I think that the overhead associated with updating
each status log in a DB every 5 minutes will be very high. And the
number of times you'll actually be retrieving these data will probably
be very small.
Copying the historical statuslogs (or the current ones) is very easy to
do with an extra Hobbit worker module hanging off the "status" or
"stachg" channels. You do not need to make any modifications to Hobbit
itself - you basically run "hobbitd_channel --channel=stachg MYDBPROGRAM"
and your program is fed all of the status messages on it's STDIN.
As for the trends data, I believe there are some patches to the rrdtool
library that will let you store the RRD files in a DB. Check the rrd-users
mailing list.
My personal favourite for a DB backend would be SQLite, since this
eliminates all requirements for an external DB ressource. You don't
want your monitoring to stop working when the DB becomes inaccessible.
Regards,
Henrik