Re: [nv-l] NV tuning for Data collection

[Leslie Clark <lclark@us.ibm.com>]

Startup of snmpCollect may be slow.
Turn on the tracing and watch what it is doing at startup, so you know
whether to worry or not. 

I've found snmpCollect to be pretty
efficient at collecting, and at minimizing its impact on the devices by
grouping stuff together. Where you may have trouble is with those per-interface
values on devices with lots of interfaces. There is a parameter for the
snmpCollect daemon for the maxpdu that controls how much data it will request
at once. It defaults to 100 somethings. I've sometimes changed it to 50
somethings, so snmpCollect breaks the request into smaller packages. This
avoids loss of data caused by the device refusing to deliver too-large
responses. 

There is also, under the Options....SNMP
Config, the timeout and retries  settings. I know this applies to
snmp requests from other parts of Netview, but I have never  been
sure whether it applied to snmpCollect or not.

You will also have trouble with some
of those interface counters if the interfaces are very high speed. Netview
currently will only collect 32bit values (Counter32), and for gig interfaces,
the values wrap much too quickly. So take a look at which instances you
really need, and what the rate of flow really is. There is no point collecting
it if it is bad data. Look for sub-interface instances with lower rates
of flow and see if that will give you what you need. 

When you update snmpCollect configuration
via the gui, it updates /usr/OV/conf/snmpCol.conf and stop/starts snmpCollect.
You can edit that file manually. If you find that you want to collect a
variety of different interface instances on each device, you could generate
that file programmatically. I'm suggesting that with large numbers of devices,
entering *.*.*.* or Routers just because it is easy is not always the best
choice. Try making fancy entries via the gui and then check the results
in snmpCol.conf. Then write a little script to generate the repetitive
parts. 

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking

"Liu, David" <david.liu@eds.com>
Sent by: owner-nv-l@lists.us.ibm.com

01/11/2005 03:53 AM

Please respond to
nv-l

To	"'nv-l@lists.tivoli.com'" <nv-l@lists.tivoli.com>
cc
Subject	[nv-l] NV tuning for Data collection

Hi list,

I've been reading nv-l archives for quite some times and benefit from them.
Now I post my first question to get your advice/help.

We are collecting quite a lot data every 15 mins (supposed to), but till
now
only part of the collection happened (everyday less than half i.e. 40
collections per definition per device, sometimes even null). My basic
question is: can NV handle that many collections? Because when I suspended
more than half of the collections (interface data). It seemed working fine.
If yes, how can I tune the NV? Where can I find the document for the tuning
(snmpCollect daemon settings)?

Here's some basic info.

NV 7.1.2 on Solaris 2.8.

Data collection of about 600 devices with

1) SysUptime for all of them

2) cpmCPUTotal5min for 400 devices (cisco)

3) ciscoMemoryPoolUsed for 400 devices

4) ciscoMemoryPoolFree for 400 devices

5) ifInUcastPkts, ifOutUcastPkts, ifInErrors, ifOutErrors, ifAdminStatus,
ifOperStatus, ifLastChange, ifInOctets, ifOutOctets, ifInDiscards,
ifOutDiscards, ifInNUcastPkts, ifOutNUcastPkts for about 200 devices with
lot of interfaces

6) Some latency data for 10 routers

Our current snmpCollect (daemon) settings:

Defer time:                
               
               
    60
Max PDU:                
                 
               
                 50
Config check interval:            
               
     1440 
Max concurrent SNMP sessions: 50
Verbose trace mode :            
               
      Yes
Polling interval for nvcold:          
      60

Thank you in advance.

Regards,
David