2 Replies Latest reply on May 18, 2012 7:29 PM by HemiTruck

    Poller Tuning on Cisco Devices


      Our NPM installation over the last year has grown more than I expected and we are now relying on it heavily and its near capacity. We can't afford an additional poller this year and my job load is 3408 and these are my stats:


      Elements  15984 
      Network Node Elements957
      Volume Elements1782
      Interface Elements13245
      Polling Rate125% of its maximum rate. Polling intervals increase if the polling rate exceeds 100% of the maximum rate. Add Poller » Learn more


      I've added many Cisco devices over this last year and I'm wondering how I can tune those monitors to allow the best performance for my single poller. I'm wondering if I can remove less important interfaces from monitoring completely? Change the polling intervals on certain port/interfaces. Has anyone done this or can give me some advice on how to proceed with tuning for these Cisco interfaces?



      Sacramento, CA

        • Re: Poller Tuning on Cisco Devices


          I do not monitor as much as you do, roughly 485 devices. I am only interested monitoring WAN and LAN links. Not too fussed about pc`s and printers. Due to internal politics, I steer away from servers too.

          I use a single poller too, NPM, NCM, Netlow< IPSLA and APM (just for the SW box

          64bit 2003 with 1TB disk space, 30Gb Ram



          • Re: Poller Tuning on Cisco Devices

            it all depends on what you can give up detail on.

            if you can accept polling volumes once per hour that will relieve some of stress

            but the fastest and quickest way you can affect this is to increase your polling interval on interfaces since you have 13245 of them

            interfaces that go to users are usually a good place to start, that way you can keep the faster polling for the wan interfaces

            the effect this has is that you will have flatter graphs on the utilization losing some detail in where data spiking might be occuring.

            slowing your statistics on interfaces to 14 min will give you some breathing room and then you can think about slowing the status polling on less important interfaces to 4 min intervals.

            Like i said in the first line it all depends on what you can give up in details.