Is there a way to create a report that will give you just the peak outgoing bandwidth per day on an interface for say a month?
Unfortunately this is not possible. PRTG only shows the maximum value in a specific time span in the corresponding graph.
Birk Guttmann, Tech Support Team
In theory you might be able to do a API call to accomplish this.
Let's say you use .XML or .CSV as output of the historic data you want to see.. you then can run through the lines reported and grab the highest value, reporting this back to where you want to see it.
I am not certain this would work in a report - but it certainly can be accomplished in a script that can provide you the data somewhere.
- The API call would need some authentication if used in a script - that's well documented.
- The ID needs to be of the sensor you want to access.
- The values sDate = StartDate and eDate = EndDate need to be set by the script before calling the API.
You should expect a .CSV content in this case, it also allows .XML - what you could process then in the code directly and run through the lines to find the highest value in the desired column.
Links that will talk about this:
Having said this - it could be an interesting feature in general to see the Min/Max values for a certain time period by default in PRTG either with API calls or even on reports. This function already exists for the LiveData API - it shouldn't be to much of a hazzle to generate it via a historic data API call that would only report those. But as long this does not exist, you can work around it while processing the historic data and determine the highest and lowest value on your own in a script.
The difference with live data and historic data is that the maximum channel value is a global value, easy to update (when new data is coming in.) Getting the extreme values for a specific time frame on the other hand requires to read / process that chunk of data stored on harddisk.
One can schedule a report per day and in this sense, gets the maximum per day. To keep the report settings tab manageable, we only added options for which we see wide usage. For more complex data analysis, we offer data export so the data can be processed with other applications.
We intentionally only implement basic API operations. (There are a few exceptions where the API provides some kind of syntax sugar in order to ease its use.) The processing of the data provided by the API should be done with external applications, as this is the most flexible way compared to a couple of pre-defined options. (We are also cautious to not overload the PRTG core service.)