Hi Awesome PRTG Developer Team,

At the moment, the SNMP Trap Receiver sensor is limited to displaying filtered trap messages (%trapmessages) inside the body of an email notification. There is also no way of exporting messages into a pretty PRTG report.

It would mean so much to be able to:

- Utilise the %trapmessages placeholder for other methods of notifications such as 'Execute HTTP Action', 'Execute Program'.

- Export the trap messages into PRTG generated reports.

Kind Regards, George

Article Comments

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


Nov, 2018 - Permalink

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.


Dec, 2018 - Permalink

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


Dec, 2018 - Permalink

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


Dec, 2018 - Permalink

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


Dec, 2018 - Permalink

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)


Jul, 2019 - Permalink

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


Jul, 2019 - Permalink