New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


How do I reset the minimum and maximum values of a sensor?

Votes:

0

Your Vote:

Up

Down

One of my sensor channels shows a certain value which meets also quite the average range of the monitored value. However, sometime ago there was a onetime event where this value was overtopped by a factor of about 10. This falsifies the average and the corresponding gauge of the channel has a range that is quite too big to see common value changes.

Is there a way to reset the value of the sensor channel to zero?

channel clone maximum minimum prtg reset sensor value

Created on Jul 18, 2013 4:42:00 PM by  Gerald Schoch [Paessler Support]

Last change on Jul 18, 2013 4:43:47 PM by  Gerald Schoch [Paessler Support]



21 Replies

Accepted Answer

Votes:

0

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 13 or later

Resetting Minimum and Maximum Values of Sensors

Unfortunately, there is no possibility currently to reset the values of sensors. Though, as a workaround, you can clone a sensor. This will keep the sensor settings but resets minimum and maximum values of the sensor. However, historical monitoring data will only be available in the old (cloned) sensor.

Steps to Go: Workaround

  1. In PRTG’s device tree, right-click on the sensor you want to reset.
  2. Choose Clone… from the context menu.
  3. Provide the name of the sensor. Default is Clone of followed by the name of sensor.
  4. Choose the device where the sensor will be added. Default is the current device the sensor to be cloned is on; most likely, you do not want to change this.
  5. Click on Continue and start monitoring. No further configuration steps have to done.
  6. Optionally, delete the old sensor. Caution: You will lose the historical monitoring data of this sensor!

Please see PRTG Manual: Clone Object for more information.

Created on Jul 18, 2013 4:43:28 PM by  Gerald Schoch [Paessler Support]

Last change on Jul 19, 2013 9:54:08 AM by  Gerald Schoch [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Apr 15, 2014 9:35:08 PM by  Gilles Lebon (0)



Votes:

0

Your Vote:

Up

Down

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.

Created on Apr 21, 2014 7:26:46 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi all,

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

Thanks, Arnd

Created on May 21, 2015 4:46:02 PM by  Arnd Gohr (110) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on May 22, 2015 2:30:53 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Oct 21, 2015 11:52:14 AM by  mcm57 (0) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Oct 21, 2015 3:15:02 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jan 6, 2016 5:17:56 AM by  rhenretta (0)



Votes:

0

Your Vote:

Up

Down

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.

Created on Jan 7, 2016 11:44:09 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Apr 1, 2016 2:51:53 PM by  clemens (0) 1



Votes:

0

Your Vote:

Up

Down

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?

Created on Apr 1, 2016 4:48:55 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on May 23, 2017 10:25:04 AM by  Attila Kovacs (0) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on May 23, 2017 11:18:25 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Dec 30, 2017 4:45:25 AM by  dabeckham (0)



Votes:

0

Your Vote:

Up

Down

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.

Created on Jan 1, 2018 12:37:17 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 4, 2018 2:46:09 PM by  Netzwerk_regio_iT (0) 1

Last change on Jun 7, 2018 4:52:42 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 4, 2018 4:19:46 PM by  Arne Seifert [Paessler Support]

Last change on Jun 4, 2018 4:20:14 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 7, 2018 4:54:45 PM by  Netzwerk_regio_iT (0) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 7, 2018 7:25:19 PM by  Arne Seifert [Paessler Support]

Last change on Jun 7, 2018 7:28:29 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

thanks prtg team :)

Created on Jan 21, 2019 12:11:18 PM by  kgulle (0) 1



Votes:

0

Your Vote:

Up

Down

Dear kgulle,

please clarify your posting.

Created on Jan 21, 2019 1:04:51 PM by  Arne Seifert [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.