snmpcollector Installation Considerations, Performance and Scalability Considerations:
Excerpt from the Help doc on Performance and Scalability Considerations and additional notes from Support/Field.
The snmpcollector probe uses a large amount of memory and disk resources. For the best performance and scalability:
1. Install the snmpcollector probe on a remote hub. Do NOT install it on a robot and do NOT install it on the Primary hub. The hub that you use for SNMP data monitoring can have a significant impact on the performance and scalability of the probe. snmpcollector should be run from a hub because the spooler probe process is multi-threaded on hub. Use manually configured hub queues to get the snmpcollector data back to the primary hub. (Configure local ATTACH queue(s) on the remote hub, and configure GET queue(s) on the Primary)
2. Allocate sufficient memory and disk space to support your data collection requirements. The monitoring capabilities of the snmpcollector probe are limited if you install the probe on a small scale system with a limited amount of resources. For more information about the minimum hardware requirements, see snmpcollector Hardware Requirements.
Open the probe in Raw Configure mode, navigate to startup->opt and increase the memory settings on snmpcollector.
Small to medium environments:
3. Only install snmpcollector with other monitoring probes if the other probes do not consume a large amount of system resources.
For example, you can install the cdm and ntservices probes if the hub has sufficient resources. We do NOT recommend installing snmpcollector on a hub with other probes that can also consume a large amount of system resources. Some examples of these probes are vmware, icmp, and ibmvm. Use filters as much as possible rather than creating multiple templates. Filters let you control how the probe applies monitors based on attributes of the target device. Every template that you create is read separately by the probe. The probe uses a large amount of system resources to read EACH template.
If you don't have the required system and available resources in your environment, you might see a slowdown in data processing or failures in QOS collection.
In terms of what you plan on monitoring, please consider what metrics provide actual value for your environment/what metrics people will actually need to see and/or use in reports/dashboards. A sound strategy would include best practices/KPIs for given devices, e.g., routers, switches etc.
Routers and Switches:
- Memory Utilization
- Buffer Hit Stats
- Availability and Responsiveness
- Concurrent Sessions
Connections per second
For a discussion of polling and polling intervals:
Symptoms of a polling interval that may be too short might include include when polling is taking > 5 minutes when the interval is already set to 5 minutes, and it causes the data points to be more than 5 minutes apart.