Settings and activity
3 results found
-
20 votes
Hi everyone,
Thank you all for voting on this idea.
Before we can commit to developing this idea, we need more input from the community.
We want to clarify: filtering/controlling which interfaces are monitored by the SNMP Traffic sensor during Auto-Discovery has actually been possible in PRTG for quite some time, by editing the ODT file: https://helpdesk.paessler.com/en/support/solutions/articles/76000041645-how-can-i-include-and-exclude-sensors-from-device-templates-
Since version PRTG .118, it has also been feasible with the SNMP Traffic v2 sensors.
That said, we understand that manually editing ODT files is not the most intuitive experience, and we suspect that's exactly the pain point many of you are hitting.
To help us prioritize the right improvements, we'd love to hear from you:
- What is your specific use case? (e.g., filtering by interface name, speed, type, etc.)
- What makes the current ODT-based approach difficult or impractical for you?
- Would a graphical UI for managing these filters solve your problem?
Thanks…
An error occurred while saving the comment Joshua Moore supported this idea ·
An error occurred while saving the comment As a PRTG admin, I need to be able to control what types of SNMP Traffic sensors are auto-discovered. We should be able to templatize the SNMP Traffic criteria based on ifAdminStatus, ifOperStatus, ifSpeed, ifType, etc.
As things are today, if a device has thousands of virtual interfaces and only dozens of physical interfaces, and all I care about monitoring are physical interfaces, there's no way to have auto-discovery only discover and add physical interfaces. Other NMSes allow the admin to filter on ifType for this functionality. Same thing if we want to layer on business logic like "only enabled interfaces" which would be for a particular ifAdminStatus. Same for "only 10G interfaces" which would be ifSpeed...
The use cases go on and on for how helpful this can be with decluttering PRTG and improving performance.
-
4 votes
-
25 votes
An error occurred while saving the comment I will add that we have been told by Paessler support that if a description is not present in the SNMP OID on initial SNMP Traffic sensor creation then future description updates on the device will not work without deleting the SNMP Traffic sensor and adding it back again. We don't understand why this logic is necessary and much rather prefer to always scan for description from the device and update PRTG's sensor if it's different in PRTG.
An error occurred while saving the comment I will also add that interface status (up or down administratively or operationally) should not have any bearing on this feature. PRTG should always poll and update regardless of interface status.
Hi, I just want to point out that article you listed explicitly calls out:
Important: The behavior of the SNMP Traffic sensor is different. For details, see How does auto-discovery with SNMP Traffic sensors work?
Then on this page:
https://helpdesk.paessler.com/en/support/solutions/articles/76000063335-how-does-auto-discovery-with-snmp-traffic-sensors-work
It states:
The auto-discovery always creates SNMP Traffic sensors for all interfaces whose SNMP traffic counters are above 0. As a result, every interface that has had traffic since the last restart of the monitored device is added, even if it is currently disconnected or disabled.
This leads us to believe that filtering logic does not work with SNMP Traffic sensors. The documentation conflicts with this feature request. Can you confirm?