[c-nsp] Re: cisco-nsp Digest, Vol 39, Issue 95

Jon Dustin jdustin at usm.maine.edu
Thu Feb 23 10:05:46 EST 2006

RTG may not be very polished, but is the only serious contender I have
found to specifically address the performance issue. The poller is
written in C, with a MySQL client built-in for speedy inserts. The
schema has also been designed for speed, rather than simplicity (three
tables for each device - InOctets, OutOctets, Errors). 

BUT - All this attention to speed gives some flexibility in deployment,
as you may split apart the polling, graphing, and storage functions if
you wish. And the graphing function only takes CPU cycles when someone
wants to view (rather than Cacti/MRTG that constantly generate graphs).

We run RTG with a 5-minute poll cycle for over 300 devices and around
11000 ports. The entire poll cycle takes about 30 seconds, and is
running on a Xeon 2.8GHz cpu with lots of other tasks to do.


Message: 7
Date: Thu, 23 Feb 2006 09:47:18 -0500 (EST)
From: Dave Temkin <dave at ordinaryworld.com>
Subject: RE: [c-nsp] Monitoring GUI for Cisco network
To: Chris Hale <chris-lists at pipelinewireless.us>
Cc: cisco-nsp at puck.nether.net 
Message-ID: <Pine.LNX.4.58.0602230946590.2534 at ordinaryworld.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

>From looking at this it looks like it would take some serious
customization to get it to do anything other than 5 minutes, or am I
missing something?


On Wed, 22 Feb 2006, Chris Hale wrote:

> OpenNMS can do this at whatever intervals you want.  It becomes a
matter of
> disk i/o and CPU if you want to poll a large network in a very short
> of time.
> We use it to poll our core devices every minute, graph every 5, and
> poll/graph standard nodes every 5 minutes.
> It also is our Syslog/trap server, notification/paging system, etc.
> Chris


Jon Dustin - Network Specialist
University of Southern Maine
Portland, ME

More information about the cisco-nsp mailing list