SNMPCOLLECTOR - DOUBTS

[Legacy User]

Hello Folks,

 

I'm checking the snmpcollector probe and have some doubts about architecture and features.

 

 

It is possible to disable probes like cisco_monitor, interface_traffic, etc and deploy SNMPCOLLECTOR on secundary hubs and configure SNMPCOLLECTOR on each secondary hub and then get alarms, qos, etc with ORIGIN from secondary hub? I do not like the idea to have one HUB only for SNMPCOLLECTOR.

 

It is possible to deploy SNMPCOLLECTOR on secondary hubs that have robots attached?

 

It is possible to change alarm messages as we did in probes like snmpget ?

 

It is possible to use only one SNMPCOLLECTOR hub to monitor 2000 devices and change the ORIGIN from hub with QOS_PROCESSOR probe ?

 

Regards,

Jean

[Prashantha.Nagaraju]

--Here is the answer to your query...--

 

It is possible to disable probes like cisco_monitor, interface_traffic, etc and deploy SNMPCOLLECTOR on secundary hubs and configure SNMPCOLLECTOR on each secondary hub and then get alarms, qos, etc with ORIGIN from secondary hub? I do not like the idea to have one HUB only for SNMPCOLLECTOR.

 

:- You can do this.. SNMPC does well compare to other network probes

It is possible to deploy SNMPCOLLECTOR on secondary hubs that have robots attached?

 

:- SNMPC works on agent level but ensure deploy discovery_agent if you wish to auto discover devices and automatically add devices into SNMPC through USM (discovery)

It is possible to change alarm messages as we did in probes like snmpget ?

 

:- use custom message field to create custom message for each metrics

It is possible to use only one SNMPCOLLECTOR hub to monitor 2000 devices and change the ORIGIN from hub with QOS_PROCESSOR probe ?

 

:- as suggested by CA, SNMPC can handle up to 3k profiles but require SSD storage & dual octa-core processor

[Legacy User]

Wherever you deploy the SNMPCollector, other robots should not be on that same hub. That adds many objects to the NISCACHE directory and slows everything down drastically.

You should learn how to use the Alarm_Enrichment to modify alarm messages with Origins, Source names, etc.

The QoS_Processor probe is practically useless. we use a simple SQL Update script that sets the Origin, Nim_origin, and Modifier in its place. That way you only have to run the script one time, not 24/7 like the QoS_Processor requires.

CA does a terrible job pointing things like this out...

We run the SNMPC on a physical system, 32Gb ram over 1500 profiles with no major issues.

CA does not consider taking 15 minutes to load the SNMPCollector Admin console as a Major issue, nor do they think that making one change requires it to reload again. You are out of luck if you need to make multiple changes. We have learned to modify the templates rather than deal with the Admin console. There are other tricks to setting it up and using it that CA hides...