I have added new snmp library to PRTG provided by the device vendor. but there is a problem in readings for a specific sensor which contains some kind of lookup table, for example if the returned sample is 24 then PRTG must display '32APSK34" and if it is 7 then PRTG display "16APSK23" and so on ....

Everything is OK in "live graph" section and all reading match with the actual value, BUT The reading from "24 hours graph" is strange and doesn't match with the actual value. the below example will clarify my point:

in live graph I have these values: "32APSK34", "16APSK23", "64APSK56" ..... in 24 hours I have these values "429,496,830", "477,218,700" ... or all values become "0" which doesn't make sense.

please advise about the reason and possible solution to this problem which is very critical for our system.

Article Comments

Dear hshtel

The live graph shows an x number of past values. The other graphs show averages. Since you are using lookups, it does not make sense to average those values, because one cannot average "32APSK34" and "16APSK23" for example.

Instead, the lookup defines a DesiredValue property. Average graphs show the coverage of that DesiredValue. That property is defined in the lookup file used.


Dec, 2016 - Permalink

Thanks dear for your response, but is there a way to reconfigure this sensor so it can store the actual value in the other graph (1 day, 2 days), for example take one sample each minute in the 24hours graph instead of average this period.

Thanks in advance.


Dec, 2016 - Permalink

Dear hshtel

PRTG does save the original data, you can get it via the "historic data" tab if you set "No average (display raw data)".

However, summary graphs always use averages because there are not enough pixels available to show individual data points. It is not possible to configure a graph to take just 1 individual value within the 24-hour period. That point could be a statistical outlier. PRTG rather displays averages, with the special treatment for lookup channels which show the "DesiredValue" coverage instead of an average original value.


Dec, 2016 - Permalink