Alert on 30% traffic increase

Dear Kurt

Notifications can only be triggered by absolute values, not by "increase of X% over Y amount of time".

If you absolutely need this function and if CPU utilization is no issue, you could write a script which is run as sensor using the "Exe/Script sensor". That script could query historic data using the PRTG API and compute the derivation to return a value on which you set a limit in the channel configuration to trigger a notification.

The PRTG API documentation is integrated into the PRTG interface, menu Setup / PRTG API. The tab "HTTP API" describes how to pass the login credentials, the tab "Historic Data" shows how to query historic data as either CSV or XML.

Please note that PRTG allows only up to five historic data API requests per second to keep the CPU and I/O load at a reasonable level.

Yes, I thought of the script solution myself, but wanted to check if there is a 'hidden' feature I might have missed....

Would that be a feature you are interested to add?

>Please note that PRTG allows only up to five historic data API requests per second to keep the CPU and I/O load at a reasonable level.

Is that a limit per client IP or per PRTG core server? What kind of response would I get if I hit that limit?

BTW: Is there a limit for the amount of historic data I can fetch in one API call?

Dear Kurt

If the core gets more API queries for historic data, the new one will be put in a queue and processed later.

An API call can span the entire history of a sensor, but it can take some time to complete this request.

About the feature request: We collect all feedback from our users to determine the direction in which we develop PRTG further. Because we think of PRTG as standard software, not every request can be implemented. The PRTG API fills the role to allow further customisation by the user.

If we see high demand for a feature, it will be placed higher on our internal wish-list: https://www.paessler.com/blog/2012/07/03/other/how-we-rate-your-feature-requests-company-culture-2

Dear Arne,

while the 'bang_for_buck' method is a viable approach, it has one drawback: Customers don't know if a feature they have suggested will ever be implemented and if not, why not. That's frustrating and annoying from a customers perspective. Same for my feature request above. You did not answer my question if you would be interested to implement it ;-))

Thus, I'd like to suggest a second method for feature requests, as I have seen that with other vendors and it looks like they are pretty successful with that tool.

You could use a system like Uservoice (https://www.uservoice.com/) to get direct feedback from the customers. I know that system especially from Astaro (now Sophos). Example: http://feature.astaro.com/forums/17359-utm-formerly-asg-feature-requests/filters/top

With such a system you could get a direct feedback from the customers. Those who are using the system can vote for a feature if they think it would make the product better. You as a vendor can still decline a feature and explain why it won't be implemented (Annoyance Factor, Boah effect, Developer Days, etc.). The whole process of feature requests would be much more transparent for your customers and that's what people like a lot these days.

Just a thought...

Regards Kurt

Dear Kurt

In software development, a feature can take much longer to implement than expected. We rather don't make promises. We are still interested in feedback. The best way is to contact us by [email protected]

From time to time, we send emails to our users, asking for feedback. Another source is the feedback of our partners.

As we try to keep the user interface of PRTG as clean as possible, we only implement a feature of which we are sure is useful for a lot of users. We have currently no plans to implement a notification trigger which fires when an X amount of increase/decrease happened over Y time.

Hello Kurt

You could trigger a notification on "Unusual", but as we speak of suggestions ... i miss custom values for "Unusual".

The default is <20% of average or >500% of average per hour and per 24h.
Settings found under Setup -> System Administration -> Monitoring

---------------------------------------------
Jens Tore Fremmegaard, ServerParkering AS
Paessler Certified Monitoring Professional