Feature Request - Updated SNMP Trap Receiver sensor

Trap messages are potentially very long, and PowerShell can only cope with 1852 characters as parameters, URLs can be 2083 chars long - so there would really be no point in implementing this. Reports are also unlikely to be implemented, as the messages tab can be used to retrieve messages. If reporting is really necessary, other solutions such as ELK LogStash, Splunk or Graylog are probably the way to go :)

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

There's got to be better, more modern way of handling SNMP traps. Email is so 1990s. Please allow other notification types like SMS and Slack, and truncate the messages to fit, if needed.

SMS is unlikely to ever happen, simply due to the length constraints. Slack or MS Teams might be something to think about, though. I'll forward it to our dev team.

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

In PRTG we also are able to use Python. Would that not take away the limitations of Powershell?

Limitations also apply to python, depending on the operating system it runs on. But from what I can tell from a quick search, it's indeed larger than PowerShell. However, there's no python wrapper for notifications, i.e. only EXE, PS1, VBS and PowerShell are supported here.

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

I'd like to have the trap-receiver manage the paused-status of snmp traffic- and rmon sensors. If a "port-up" trap is received the given sensors may be unpaused and in return paused on "port-down" trap, so any unused (down) port on a switch will not be monitored while it is down (may save sensor count on unused ports and as well polling snmp on those).

(I'm currently unpausing those ports by using the prtg api and an external trap-receiver, but the api isn't well for this, as I have to query a lot of things before I can pause the sensors)

Hi Nogalj

That's actually the way we tell customers to do it when they'd like to keep the SNMP Trap Sensor in an erroneous state in case a certain trap is received. You might want to check PRTGapi in my signature in order to streamline the process. We're not going to have Sensors manage one another like requested I'm afraid, so API is the way to go here I assume.

PRTGapi | Feature Requests | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team