<font face="courier new,monospace"><br>Hi All,<br><br>We have 5393 hosts and 69452 services across 14 servers.<br><br>The monitoring is spread unevenly across the servers as most of them are in specific customer environments.<br>

We use Puppet (formally rsync) to distribute a standard set of "global" config (host / service templates etc) across all servers and each server has its own local config (hosts / services).</font> <br><br>We use SNMPTT passive checks for the networking kit, NRPE for most Nix hosts (some use SNMP checks) and NSClient++ with Microsoft servers. <br>

<font face="courier new,monospace"><br>All based on standard Nagios core and tied together with an horrid POC intergeneration software / MQ.<br><br>I did do some testing with Merlin but it was far from stable at that point and we have been waiting for Nagios 3.4.x to be released. So possible some time soon we will add Merlin.<br>

<br><br clear="all"></font>--<br>Ritchie<br><--Time flies like an arrow; fruit flies like a banana.  --><br>

<br><br><div class="gmail_quote">On Fri, May 18, 2012 at 8:33 AM, Simone Felici <span dir="ltr"><<a href="mailto:s.felici@mclink.eu" target="_blank">s.felici@mclink.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Impressive :)<br>
We're monitoring ~2000 hosts and ~10000 services, every 5 minutes.<br>
Architecture used: OPSView Community edition, the last free version before it started to make the<br>
distributed version commercial :/<br>
Two central servers (active/standby - drbd) as single point for management and collecting all<br>
passive checks executed by the slave servers. Performance data saved into rrd files as well on an<br>
external BIG database server. Configuration resides on a cluster MySQL installation (drbd).<br>
4 slave "datacenter installations" with 2 servers per "datacenter" in active/active load balancing.<br>
Traps handling supported on all servers with rules logic.<br>
Pros:<br>
- Open Source: at least until version 3 - for our setup. Simple single instance with fewer functions<br>
available as well on version 4.<br>
- Easy to manage: the prupose was to create monitoring system and then let the management to other<br>
people with less technical skills<br>
- distributed setup<br>
- RBAC<br>
Disadvantages:<br>
- no longer Open Source: see above<br>
- Central server suffering on cpu by GUI implementation and other bg jobs<br>
- Not all nagios parameters editable as we like: i.e. cannot customize same checks with different<br>
intervals without having to re-create new ones. Think on HTTP service on servers with different<br>
loads and the need to extend the retries on high load servers. no way expect creating "HTTP" and<br>
"HTTP High Load" services.<br>
Maybe there are more pros (and disadvantages), but it's not the right place.<br>
BTW I'll look forward to wait for this solution; seems interesting!<br>
<br>
Simon<br>
<br>
Il 17/05/2012 16:43, Max Schubert ha scritto:<br>
<div><div>> Hi,<br>
><br>
> I like it when people periodically post numbers and architecture<br>
> summaries, I am guessing with the distributed frameworks out now for<br>
> Nagios this thread might be seeing bigger numbers than past threads<br>
> have.<br>
><br>
> With our custom-built distributed Nagios-based monitoring system, we<br>
> are currently monitoring 18000+ hosts every 5 minutes and 100k+ active<br>
> services (plenty of passive services in addition to the actives) every<br>
> 5 mins as well.  We collect performance data from every check as well<br>
> and pass that on to a highly distributed and scalabe time-series data<br>
> warehouse another team in our organization has built (which is why we<br>
> have the 5 min interval requirement)<br>
><br>
> We also do trap ingest using SNMPTT with a few custom mods, but not<br>
> going to include those numbers as they never have required the<br>
> optimizations the polling has required.<br>
><br>
> This isn't a monolithic instance, we have 6 projects using instances<br>
> of our distributed Nagios-based software, called Racon (soon my<br>
> manager will give our team to package it as open source - so I hear at<br>
> least).  We built it on core Nagios with a custom database layer based<br>
> on a very very early version of Merlin's database abstraction layer<br>
> (thank you Andreas!) - we have a custom client/server network-based<br>
> notification framework in use (we will release that as well) along<br>
> with a custom NEB/perl based client-server framework (also releasable,<br>
> just need time scheduled) for sending and processing performance data<br>
> - the performance and notification framework are both horizontally<br>
> scalabe and network fault tolerant.<br>
><br>
> What kinds of numbers of hosts and services are you all monitoring?<br>
> Which add-ons / distributed frameworks are you using?<br>
<br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Nagios-users mailing list<br>
<a href="mailto:Nagios-users@lists.sourceforge.net" target="_blank">Nagios-users@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/nagios-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-users</a><br>
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.<br>
::: Messages without supporting info will risk being sent to /dev/null<br>
</div></div></blockquote></div><br>