You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Case1: There is little control on how to limit what sc4snmp is polling and how often.
Ideally you want to run a full walk on all devices once per day, then filter the important interfaces/elements based on custom code and finally get the metrics you want on small intervals on the specific smaller subset of interfaces.
At the moment all devices and all their interfaces have to be polled causing a high amount of requests from sc4snmp which translates into hardware requirements.
Case2: You want to poll something more complex. Like quality of service on some specific interfaces. Again you have to run the entire MIB, collect everything and then filter/correlate it when it comes into Splunk. The option of adding some snippet code that can filter/work before sc4snmp starts polling would solve this problem as well.
Every company and every usecase requires different kind of collection. Assigning this filtering at the end of the collection and in Splunk it is not ideal for all cases. This feature can also kickstart a more organized directory of snippet codes that different companies/people have developed to serve a specific purpose. Or it can even be implemented into sc4snmp in the form of "modes" that will be different than varBinds that exist now.
The text was updated successfully, but these errors were encountered:
Case1: There is little control on how to limit what sc4snmp is polling and how often.
Ideally you want to run a full walk on all devices once per day, then filter the important interfaces/elements based on custom code and finally get the metrics you want on small intervals on the specific smaller subset of interfaces.
At the moment all devices and all their interfaces have to be polled causing a high amount of requests from sc4snmp which translates into hardware requirements.
Case2: You want to poll something more complex. Like quality of service on some specific interfaces. Again you have to run the entire MIB, collect everything and then filter/correlate it when it comes into Splunk. The option of adding some snippet code that can filter/work before sc4snmp starts polling would solve this problem as well.
Every company and every usecase requires different kind of collection. Assigning this filtering at the end of the collection and in Splunk it is not ideal for all cases. This feature can also kickstart a more organized directory of snippet codes that different companies/people have developed to serve a specific purpose. Or it can even be implemented into sc4snmp in the form of "modes" that will be different than varBinds that exist now.
The text was updated successfully, but these errors were encountered: