I have the same problem on some sensors.

Is there a plan to implement "sensor max-min reset" option in PRTG?

I do not want to clone and loose historical data.

Hello, I'm very much afraid currently there are no plans to implement such a functionality. There are very few requests for this, so that we have to recommend the proposed work-around here. Sorry.

Hi all,

we are also interested in a 'Reset' function. Cloning is a workaround but you are losing all historic data :-(

Thanks, Arnd

Dear Arnd

A reset function is not possible. The min and max value is derived from the historic data. While the data is in place, the according min and max values exist as well.

You can use the Spike Filter to filter the data above or below a certain value. This is the only influence possible on extreme values in PRTG.

I would add a reqeust to reset those values too.

In addition I think it would be more usefull, if the minimum and maximum values are provides for a selectable range (min / max last hour, last week, last month ....)

If minimum / maximum handling really seems to be too complicated to implement, please consider a change to the gauges enabling the setup of a manual range. Currently the gauge is selfadjusting. With (custom) sensors dispülaying several values of the same range (i.e. multiple temperatures) the gauges cannot be compared fast, as due to different maximum / minimum values, the display range differs.

McM

P.S. I've added the gauge suggestion here as this display is the most annoying sideeffect of abnormal mximum / minimum values. Please let me know, whther it's useful to add the manual scaling request as a seperate topic too.

Dear Mcm

We noted your request. Please allow me to be honest: For the foreseeable future, we don't plan to implement manual gauge scaling. We continue to collect the user feedback and weigh it compared to the other features we plan.

I would also like to request this. It would be incredibly valuable. For example, I have a HTTP and HTTPS sensor on some websites. I had a response time of 26,000 ms which completely threw off the meter with all red (threshold of 150ms) and virtually no green / yellow. If this at least displayed based on the manual scaling values, it would be much better.

Dear rhenretta

The Spike Filter might be a solution. Using this filter, you also filter your 26,000 ms spike from evaluation when you look at graphs or create historic data reports, but it also affects the gauge maximum.

I would also be able to reset the minimum and maximum counters of a sensor. I tried the spike filter but this does not solve the problem.

Dear clemens

Resetting these values is not possible due to PRTG's design. The extreme values always consider the entire available historic data.

Did you have no change at all after using the spike filter, or did the gauge scaling change, but not as much as you would like?

Hi,

I also would be happy to be able resetting the minimum and maximum values. I see PRTG is calculating the value from historical data but could be add a function which set the start time of investigated period. Then I coud flexible set the start point of the interested period or set the time to 'now' for reset and show newly reached values.

Attila

Dear Attila

Resetting these values is not possible. They are needed for some internal computations like channel gauge scaling. To get data, you can use the "historic data" tab or extract it via the PRTG API and let a script look for minimum/maximum values in that range.

OK Folks, since the support group for this product lacks luster, I will give you a better solution than cloning your device and losing ALL of your historical data. This solution will only delete 1 day of data for each anomaly (spike), unless all of your anomalies were on the same day. In this case, you still only lose one day. Paessler has decided to use their own proprietary file structure (in binary) to store their data, so it's difficult to correct only the one record causing the problem. At least they create a new folder for each day and each device.

• First, you need to find the date the spike occurred.
  • click on the device - make a note of the Device ID# on the right
    • click on the sensor
      • click on the historical data
      • choose the date range you suspect the spike occurred - big range = long wait
      • For "Average Interval" - choose No Interval (Display Raw Data)
      • review the results in the "speed" column and find the anomaly/spike
        • make note of the date
• Next, you need to locate and rename the appropriate file
  • open windows explorer and paste the following into the address line
  • %programdata%\Paessler\PRTG Network Monitor\Monitoring Database
  • select the date the anomaly occured
  • rename the file Device XXXX matching the ID you noted before - name is irrelevant
• Rinse and Repeat for each device and date that the anomaly occurred
• Reboot computer (easy way)
  • OR stop and restart PTRGCoreService and PTRGProbeService

RANT:

• It's really a shame that Paessler doesn't take problems with their product seriously. I spent only a few minutes looking at this problem and it fits the trend of bad programming I have seen throughout this product. The problem arises from the way PRTG calculates speed. Speed is not a value given by the device. So, PRTG subtracts the previous BYTE counter value from the current BYTE counter value and divides by the interval, giving the BYTE/Second. Because the developer is making the very bad assumption that the previous BYTE counter data was valid, you will see a huge spike after a series of bad responses. For example, let's say your interface total was averaging 90,000 KByte every 60 seconds, and for what ever reason, PRTG got about 30 minutes of bad responses... when the good responses resume, the counter will jump up to 2,700,000 KByte. From PRTG's point of view, all this traffic occurred in the past 60 seconds... That's 360Mbs!!! while your interface was really only moving 12Mbs.... and this immediately throws off the scale of your gauges because it shows a maximum of 360Mbs, while your know the interface was only capable of 100Mbs... :(
• They should make a utility to seek out the offending row and delete it.
• or they should make the file format available so interested parties can seek out the row and delete it.
• or they should recognize the anomaly by noticing the bad data prior to the spike, and smooth dividing by the sum of all the intervals of bad data.

Dear dabeckham,

in order to compute the speed, PRTG does not divide by the scanning interval. Instead it uses the actual time difference of the scans (which is recorded with millisecond resolution.) In case of a counter overflow, PRTG can be configured to factor that in, which avoids spikes caused by traffic volume counter overflows.

Regarding historic data, PRTG is a tool for monitoring and records the results. In order to tamper with that data, you can extract it and process it when you create a report. The PRTG spike filter can be used to remove extreme values from outputs, but the actual historic data on disk is not changed.

Well, we are looking for an easy way to delete single data points, as well. Spike Filter is a complicated and faulty-workaround.

We often use clear counters as a easy way to find errors in cli. But this results in faulty spikes in prtg (as it should be in different products too?)

But even without clearing counters, just with creating an sensor, there is sometimes a initial spike. Using Spike Filter is complicated and includes a lot of work AND is faulty in a future-manner. I can not exclude, that a today faulty spike could be a real spike in future. So we do not want to use this feature for real.

So i do have two requests:

1. Request: A easy way to delete single data points from the database, to get a correct (but indeed incomplete) database without utopic spikes. - cloning sensor could not be more than a "dummy" workaround. New sensor does not have historic data, and old data includes unwanted spike. In Addition double-data should be avoided (database and common sense)... - dabeckham's way is not working as there is not such an folder with actual date

2. Request: After creating a sensor an collecting data, PRTG should skip the first 3 data points for using building its data table and graphs. So the faulty initial spikes could be avoided too.

-- 3. Request: SOLVED -- 3. Request (offtopic): I could not understand that PRTG seems to be not able to update Sensor titles, after changing Interface Descriptions. Changing the Interface Description (e.g. Cisco Router) is not considered by prtg. And on top, adding Interfaces manual or by automatic search leads to duplicate sensors. Why? Why does PRTG does not check if the the interface (oid and or ifindex) already exists (for the selected device). It is a lot of work to keep the data correct and not duplicated. We use Solarwinds Orion Suite, too. And here and with some other tested open source software, these two problems do not exist (of course other problems still exist, offscope). -- 3. Request: SOLVED --

Thanks a lot

Robert Grossmann

regio iT Aachen Germany

Dear Mr. Grossmann,

thank you for the input.

PRTG does offer an automatic port name update.

As for the spike filter handling, you brought up some very specific requests. When we decide on new feature or additional options, we look at the broad picture. Every line of code written for one thing is missing somewhere else.

This is not what you wanted to hear, but please do not expect those things being implemented. As we develop PRTG as standard software, we have the standard use case in mind. As a possible workaround, please consider to extract the raw data for those sensors via the PRTG API and process the data in another application.

Hello,

Req. 3 solved. Read the fuck* manual. I'm sorry. We will test the option.

Req. 1 and Req. 2 are still open. And as you can see in this thread other people do want to have this, too. And there are several more threads with similar requests.

So please make it possible to delete single datapomts from the database or make the database open so we can delete it directly from the database... I guess this is a standard use case. Nobody wants to see false spieks in his data...

Extracting not an option, as we use PRTG as the live Core Monitoring tool and as public presentation maps for customers.

Thanks a lot

Dear Mr. Grossmann,

PRTG uses its own, proprietary data base, tailored for PRTG's needs. We don't plan to offer retroactive data modification, because PRTG's philosophy is to faithfully record the monitoring results. In order to remove outliers from reports, graphs and gauges, we implemented the spike filter. If a user wants to process the data further, PRTG offers to export it via the PRTG API, or via data tables included in reports.

PRTG itself uses the recorded data, with or without a spike filter. Having a historic data editor does not fit our vision of a standard use case of PRTG. We develop PRTG further, with suggestions from the users. Taking user input into account, we want to provide a realistic outlook for the requests we get. Please do not expect an option to modify actual historic data.

the year 2019 was the sensor does not delete the history data (reset) button :)

thanks prtg team :)

Dear kgulle,

please clarify your posting.