Want this feature implemented, too? Please upvote by clicking Thumbs up!
(Posts as a reply won't be published in this feature request thread. Read Me!)
User Story
As a PRTG User, I want to have improved functionality for the way PRTG handles SNMP tables and SNMP in general:
SNMP tables create many sensors and cannot handle dynamic tables (tables that have entries being added or removed, for example clients associating with an access point). I would like for PRTG to be able to handle strings in tables as well, a lot of information in some SNMP tables cannot be read by PRTG, because it is in string format. I would also like to see this being implemented in a single sensor for the entire table, perhaps channels being added or removed depending on how many rows a table has. Channels should be dynamically removed or added as rows are being added or removed from the snmp table.
It would also be nice if there was a sensor in PRTG that could perform an SNMP walk. Instead of channels it could just output that walk in a window.
Details of User Story
We are currently running into a change management problem with our switches. We document everything manually and we don't want to add another tool just to keep the switch port mapping up-to-date. It costs a lot of time and effort to keep all our configuration manually updated. We are already placing probes at the locations of our customers and we want to use PRTG for switch port mapping. Improving the functionality of SNMP in PRTG should be enough for this, as it does not have to be an entirely new feature in PRTG, just better functionality of existing sensors. Reducing the number of sensors the SNMP custom table sensor creates is necessary to be able to see all the information of a table in a single sensor.
We have also looked into scripting options with Python etc, but this will take too much time to implement, unless there is a way for PRTG to exchange scripts automatically between the core server and its probes.
Acceptance criteria
- Criterion #1 SNMP custom table sensor can handle strings.
- Criterion #2 The SNMP custom table sensor does not create a sensor for every row in the table, instead it should all be in a single sensor.
- Criterion #3 The SNMP custom table sensor should be able to handle dynamic SNMP tables like the example given.
- Criterion #4 Adding SNMP commands directly to PRTG would be convenient, we would no longer have to use a seperate tool to perform snmp commands. Even better would be the ability to directly setup an SSH connection or something similar to a network device from PRTG (router/switch etc.). A redirection to a program like Putty woud suffice.
Status
Open