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

[Scott Walters]

>
> 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.

scott