Max number of services that can be monitored ?

[Rafael 'Dido' Sevilla]

misc at viceconsulting.co.nz wrote:
> I was wondering, with 256MB ram and a 2.8GHz P4, should I be maxing out
> Nagios at 1000 services?  I was thinking this seems a little low, and
> thought I could probably be monitoring around 10,000 services before
> worrying about maxing out the machine's resources...
> 

That depends on what service checks you are using.  If it's something
complicated, things are a little messy.  Different service checks have
got different requirements so it's fairly difficult to state a rule of
thumb.

> What other hardware / number of services are people using / monitoring
> without maxing out their server's resources?

Now, we're running a distributed Nagios cluster with seven DSes,
monitoring a total of some 30,000 services, giving each DS an average of
about 4285 services (mostly ping and SNMP interface status).  The CPU on
these boxes maxes out every so often but later enters a period of
quiescence; from an auxiliary Nagios grapher that we use to watch trends
in their behavior, it appears to be cyclic (corresponding, no doubt to
the check execution/service reaper cycle of Nagios).  Each DS is a Xeon
2.8 with 1 GB of RAM though.  Maybe it's thrashing you're experiencing,
as memory is always maxed out on our boxes, but fortunately, it only
very seldom uses swap.

-- 
True compassion is more than throwing a coin to a beggar. It demands of
our humanity that if we live in a society that produces beggars, we are
morally commanded to restructure that society.
http://stormwyrm.blogspot.com/


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null