SNMP Custom Table Sensor: Enable String Value Handling in Channels
As a Network Engineer monitoring multi-vendor network infrastructure,
I want the SNMP Custom Table sensor to support string value handling in its channels (e.g., mapping strings to sensor states or displaying them in the sensor message),
so that I can monitor all relevant data from SNMP tables - including string-based status fields, names, and descriptors, without needing to create individual string sensors or custom scripts for each OID.
Background:
In SNMP Custom Table sensors, it is currently not possible to evaluate string returns within channel strings. The user considers this a notable gap, because string returns are very common in SNMP-based network monitoring and not an exception.
Example OIDs / vendor context:
Aruba example table OIDs: .1.3.6.1.4.1.47196.4.1.1.3.15.1.2
Aruba example table OIDs: .1.3.6.1.4.1.47196.4.1.1.3.15.1.4
The Aruba OIDs show that many values are returned as strings rather than purely numeric values. This is standard practice in SNMP network monitoring.
AdminSasa Ignjatovic
(Admin, Paessler)
shared this idea
Hi there,
Great news! Your idea has been approved and moved to the next stage on Paessler.
Before we can commit to developing this idea, we need more input from the community. Your idea has the potential to significantly impact our users, and getting broader feedback will help us understand its full scope and prioritize it effectively.
Here's how you can help:
- Share your idea: Encourage other Paessler users to view, comment on, and vote for your idea.
- Elaborate on your suggestion: Add more details, use cases, or examples to your idea description.
- Engage with comments: Respond to questions and suggestions from other users.
The more engagement your idea receives, the better its chances of being fully implemented.
Thanks for your continued collaboration in making Paessler even better!
Best regards,
The Paessler Product Team
-
Heinz Meyer
commented
This is absolutely true. Especially when it comes to monitoring stacks and their members, an SNMP Custom Table Sensor really shines when it’s created by using a device template—for instance: Based on the table indexes, it determines how many sensors need to be created and then dynamically generates them for each stack member. However, it’s also a fact that many (including large) manufacturers, such as Aruba, now return the necessary information about status and so on as a plain string. The named OID's are perfect examples.
And that effectively rules out the SNMP Custom Table Sensor. The alternatives would be statically created SNMP string sensors, which would either have to be created manually for each stack member, or you would have to come up with complicated workarounds to obtain every relevant table index by other means.