What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Why does the SNMP System Uptime sensor report wrong values?

Votes:

0

My SNMP System Uptime sensor shows incorrect uptimes. For example, the Windows system info reports that the device has been running for 153 days while PRTG is only displaying an uptime of 4 days.

Does the uptime sensor query the correct OID? How can I fix this wrong system uptime issue?

prtg snmp snmp-custom-sensor snmp-system-uptime system-uptime uptime windows-system-uptime wmi

Created on Aug 21, 2014 2:28:27 PM by  Gerald Schoch [Paessler Support]

Last change on Jul 10, 2019 5:51:06 AM by  Maike Guba [Paessler Support] (2,404) 2 1



9 Replies

Accepted Answer

Votes:

1

This article applies as of PRTG 22

Incorrect system uptime via SNMP

The SNMP System Uptime sensor monitors the time that a device runs. For this purpose, PRTG queries the data from the device via the Simple Network Management Protocol (SNMP) and uses specific object identifiers (OIDs) to get the corresponding values. For a general introduction, see How do SNMP, MIBs, and OIDs work?

There are two possible OIDs to query uptime data from a device via SNMP:

  • HOST-RESOURCES-MIB::hrSystemUptime (1.3.6.1.2.1.25.1.1.0)
  • DISMAN-EVENT-MIB::sysUpTimeInstance (1.3.6.1.2.1.1.3.0)

The sensor queries hrSystemUptime if available and uses sysUpTimeInstance as fallback, so the SNMP System Uptime sensor usually reports the correct uptime value. However, in specific cases, PRTG reports an uptime that is lower than the real uptime of the monitored device.

There are two possible reasons for this:

1. Wrong uptime values because of 32-bit counters

Both OIDs that the sensor can query for system uptime are 32-bit counters. This means that the maximum value that these counters can have is 2^32 (2 to the power of 32), which is the integer 4294967296. Because the returned uptime value is given in hundreds of seconds (1/100), the maximum possible uptime that the sensor can display is 497 days (which is 4294967296 hundreds of seconds). If the uptime exceeds this value, that is, the monitored device runs longer than 497 days, the counter resets to 0 and, from this time on, PRTG shows uptime values that are lower than they actually are.

This calculation applies to all network hardware devices, for example, switches or routers. Unfortunately, the behavior on Windows systems is different.

2. Wrong uptime values on Windows systems

If you use the SNMP System Uptime sensor on Windows systems, you might encounter the issue that the uptime value resets to zero not only every 497 days but more often.

Windows returns the uptime value of the default hrSystemUptime counter in thousands of seconds (1/1000). So, considering the calculation for 32-bit counters above, the maximum uptime that the SNMP System Uptime sensor can show on Windows is 49.7 days. It resets to 0 if the uptime exceeds this value.

The fallback counter sysUpTimeInstance that would return the values in hundreds of seconds is not used on Windows systems because the default counter is usually available.

Example

Consider the following case that illustrates this issue:

  • The real uptime of a device is 153 days, 14 hours.
  • The SNMP System Uptime sensor in PRTG shows the value 4 days, 11 hours.
  • The maximum uptime value that PRTG can show is 49.7, so the value has exceeded the maximum three times in this case: 49.7 * 3 = 149.1 days
  • The value that PRTG shows added to the “exceeding times product” is the real uptime: 149.1 days + (4 days, 11 hours) = (153 days, 14 hours)

Workaround

You have two workaround options to get the correct system uptime value on Windows systems:

  • Use the Windows System Uptime sensor on Windows systems. This sensor type can even show uptime values that exceed 497 days.
  • Create an SNMP Custom sensor if you want to avoid using WMI and to avoid the default hrSystemUptime counter of the SNMP System Uptime sensor (that can show a maximum of only 49.7 days on Windows):
    • Query the OID 1.3.6.1.2.1.1.3.0 (sysUpTimeInstance). This is only the fallback of the standard SNMP System Uptime sensor but can show values up to 497 days on Windows as well.
    • For display purposes, calculate the number of uptime days by dividing the retrieved value (that comes in hundreds of seconds) by 8640000. Enter this number in the Division field of the sensor settings.
    • Note: Of course, you can also display the value not only in days, but also in any other time unit. Adjust the calculation to get the desired division for the sensor value: The calculation to map hundreds of seconds into days is retrieved_value / (100 (seconds) * 60 (minutes) * 60 (hours) * 24 (days))
    • Note: This counter resets to zero every time the SNMP service on the machine is restarted. This means that the uptime value in the sensor can be different from the real uptime of the monitored device even if there was no restart of the system.
    • Note: You also get a maximum of only 497 days with this sensor type.

Created on Aug 21, 2014 2:41:23 PM by  Gerald Schoch [Paessler Support]

Last change on Jan 4, 2023 12:00:16 PM by  Brandy Greger [Paessler Support]



Votes:

1

Adding to Gerald's answer above, in which he says:

"Note: This counter resets to zero every time the SNMP service on the machine is restarted for whatever reason. This means that the uptime value in the sensor can be different from the real uptime of the monitored device even if there was no restart of the system."

This is per the requirements of the sysUpTime (as found in e.g. RFC 1213), which are that it reflects the uptime of the SNMP Agent, not that of the managed entity itself.

In contrast, hrSystemUptime is supposed to reflect the actual system uptime.

Created on Nov 14, 2017 11:44:09 AM

Last change on Nov 15, 2017 1:03:28 PM by  Luciano Lingnau [Paessler]



Votes:

0

Thank you for sharing this information, tomalak!

Created on Nov 15, 2017 1:49:55 PM by  Gerald Schoch [Paessler Support]



Votes:

0

Hi there, You just offer workaround for Windows Systems. What about the network devices like switches and routers? I have the same problem with my network devices. That the uptime resets after 497 days. Is there any solution or workaround that remove this limit for network devices? Also it will be very helpful if that solution not dependent to SNMP and be reset just if the device really be restarted, not when the SNMP service on the machine is restarted. Thanks a lot.

Created on May 11, 2019 6:55:32 AM



Votes:

0

Hi Hossein,

Unfortunately, from a technical point of view, it is not possible to set the uptime to a value higher than 497 days, because the "Uptime"sensors we use are 32-bit counters.
Maybe you could ask the vendor of your devices, if they have "MIBs" which uses 64 bit counters.

Created on May 13, 2019 1:17:00 PM by  Marijan Horsky [Paessler Support]



Votes:

0

"The sensor queries hrSystemUptime if available and uses sysUpTimeInstance as fallback, so the SNMP System Uptime sensor usually reports the correct uptime value. "

@Paessler - Can you please change the sensor to try this one first?

snmpEngineTime - 1.3.6.1.6.3.10.2.1.3.0

This is in seconds and it will not roll over for 135 years...

Since it seems that both sysUpTimeInstance and snmpEngineTime could return the uptime of the snmp engine (that on some systems coud be reset when the system keeps running) while hrSystemUptime is supposed to return the actual system uptime value, I think that the safest solution should be that the PRTG snmp uptime sensor always check for all of the three OIDs and store only the greater value (in seconds) among the three.

Created on Apr 29, 2021 4:18:11 PM

Last change on Apr 30, 2021 2:32:40 PM by  Felix Wiesneth [Paessler Support]



Votes:

0

Hello Robydago,

I'm afraid currently it's not planned to change the OIDs. I noticed there's already a official feature-request for this: https://kb.paessler.com/en/topic/88631 .

If you wish this to be implemented in the future, please vote for it as this will help us to prioritise the wish internally so that the feature eventually makes its way into the roadmap then.

Created on May 4, 2021 6:51:26 AM by  Timo Dambach [Paessler Support]

Last change on May 6, 2021 10:56:57 AM by  Timo Dambach [Paessler Support]



Votes:

0

Timo, when I try to open the link to the kb page, I get a 404 page not found error.

Created on May 5, 2021 9:36:49 PM



Votes:

0

I'm sorry, my bad. Thanks for letting me know - The link is fixed now.

Created on May 6, 2021 10:58:23 AM by  Timo Dambach [Paessler Support]




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.