[hobbit] scalability of hobbit/xymon ?

[Shaun Phillips]

Although I'm far from knowing what hobbit can do but doesn tthis paragraph

Quote : http://www.hswn.dk/hobbit/help/about.html
*Xymon can handle monitoring lots of systems.
*

*Big Brother is implemented mostly as shell-scripts, and performance suffers
badly from this. In large networks where you need to monitor hundreds or
thousands of hosts, processing of the data simply cannot keep up. Another
problem with BB is that it stores all status-information in individual
files; when you have lots of hosts and statuses, the amount of disk I/O
triggered by this severely limits how many systems you can monitor with one
BB server.
Xymon avoids these performance bottlenecks by keeping most of the
ever-changing data in memory instead of on-disk, and by being implemented in
C rather than shell scripts.*

I'd imagine if the above statements is correct the power of the server and
available memory is the only thing holding you back?

On Wed, Jul 8, 2009 at 2:31 PM, nico <nico at crysto.org> wrote:

>
> Hi,
>
> In my company, we are currently monitoring ~7000 devices (unix, microsoft,
> network, firewall, storage) in 13 datacenters in different countries
> (Spain, Italy, Germany, Belgium, France, Amsterdam, Belgium, UK).
>
> The architecture is simple:  one hobbit cluster using Heartbeat in each
> datacenter (= 13 clusters)  reporting to a central cluster by bbproxy and
> some custom scripts to concatenate/consolidate the bb-hosts files
> correctly.
>
> My question is for the future, we need to support 20 000 devices and i
> would like to know if hobbit is able to do that. (scalability).
> Indeed, my company doesn’t trust that it’s possible, and they want to
> move to HP BSM or EMC Smarts .... :-(
>
> Any experience about that is welcome.
>
> Regards,
> Nico
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20090708/8a7105fe/attachment.html>