[hobbit] out-of-inodes hobbit conn error for all 300 systems
scott at PacketPushers.com
Sun Dec 18 16:28:17 CET 2005
> I dont have any immediate plans for this, but it would be a nice
> project if someone wants to dip into the Hobbit code (hint!). You
> easily turn off saving the file-based status logs (there's a
> hobbitserver.cfg setting for that), and a module for storing the
> logs in a DB would be fairly trivial to implement as a Hobbit worker
> module hanging off the "stachg" (status change) channel. Apart from
> that, there's a simple change to pick the status log from the DB when
> viewing it, and that's all.
Ahhh the BB/Hobbit, "How about a DB backend question ;)"
I've always been amazed that BB and Hobbit could use a filesystem as
a database and not kill a server much *sooner*. hobbits use of
memory for bbvar/logs is a huge win . . . .
Ideally the backend for most, if not all, of the state/history
information for events would be a database. Problem is, that
introduces a dependency of the product (hobbit) an another tool
(Database). This can very easily become a nightmare from a support/
integration point of view. Not to mention you raise the bar for
entry level admins ability to 'tinker' with the product.
Unless the entire hobbit tool were re-architected to have DB back-
end, I don't think it would be worth the overall effort for keeping
the histlogs area small.
That's *not* to say it isn't a good idea or it *wouldn't* be a great
coding project for someone.
But I think it would be a better use of resources and benefit more of
the user community if hobbit could internally, archive and retrieve
this data. The history data is *extremely* useful and having it
around is a wonderful asset for problem history/determination.
Henrik, I was thinking along the lines of every month or so archive
the histlogs into a single large file, or one file per host, and then
introduce logic into the show history that could determine if it
needed to expand the archive to get it.
More information about the Xymon