[hobbit] out-of-inodes hobbit conn error for all 300 systems

Scott Walters 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  
> little
> project if someone wants to dip into the Hobbit code (hint!). You  
> could
> easily turn off saving the file-based status logs (there's a
> hobbitserver.cfg setting for that), and a module for storing the  
> status
> 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 mailing list