Hi,
I'm wonderng about a "missing feature", that is a daily one in working with snmp-traps - from my not very deep knowledge about snmp. Maybe it is also there but I do not know how to manage it.
My scenario: I have a communication server managing about 10 "dial"-connections to different partners, FTP, OFTP and so on. For each of it I'd like to know when there is a failure, sensor-state on error or warning. After the connection was established without problems again, the error-state should be deleted back to "ok".
I would expect the following from this feature: I setup the SNMP trap receiver. For the receiver, I configure different channels as different trap-codes (one trapcode for each connection). Then I'D need to configure what state the sensor should take on which message in the trap (set error, set warning, unset error, do nothing but log and so on).
After try-and-error for a while it looks as this could only be done with setting up a whole bunch of trap-sensors, one for each single trapcode, that would have to contain information about the connection and the state of the connection, but this looks as a very nasty solution, do it?
Hopefully you can understand what I'd like to do and give me a hint how to do such things.
Best regards Dominic
Article Comments
Hi,
I'm aware of the limitation of a single OID. This is not a problem for my situation, because all traps beeing send by the source comes with the same OID, but different trap-codes / messages. So different reactions for different message contents (same OID) would also help in my special scenario.
I'll keep this on sight and would be glad to find some day notices about improvements of the trap-receiver-sensor in the update-log :) Br
Jun, 2013 - Permalink
At the moment, the SNMP Trap Receiver sensor can only process one explicit OID. As such, you are correct in that you would need to add one Trap Receiver sensor per trap you want to receive (please have a look at How can I use PRTG’s trap receiver and what are its limitations?
We are already working on a new, more flexible technology, but cannot yet say when the same will be implemented. This will, most likely, still take some time. Please bear with us.
Jun, 2013 - Permalink