Network Management

NPM Polling - LastBoot, LastSystemUpTimePollUtc and SystemUptime values explained

NPM shows the wrong Lastboot time or did not show a Node as rebooting. Last Boot is not updating with the actual reboot of the server. Linux node last boot not updating.

First published date

5/23/2019 4:12 PM

Last published date

10/2/2023 1:27 AM

Overview

This article explains how LastBoot, LastSystemUpTimePollUtc and SystemUptime values are calculated. This applies to nodes polled via

  • SNMP
  • WMI
  • Agent (Linux, Unix, Windows)

Product section

Orion Platform

Cause

NPMs calculation of last boot time can sometimes be a false positive if the SNMP counter rolls over or is close to rolling over.

Resolution

Orion polls devices using the following 
 • SNMP : sysUpTime OID (1.3.6.1.2.1.1.3)  
 • WMI  SELECT SystemUpTime FROM Win32_PerfFormattedData_PerfOS_System
 • Linux Agent : parsed from who -b cat /proc/uptime

*If the device is a Windows Orion agent, the Last Boot is taken from local WMI query result.
 

  • sysUpTime is measured and stored in the Orion DB as hundredths of seconds.
  • LastSystemUpTimePollUtc is the last time Orion polled the device for sysUpTime
  • LastBoot is calculated by Orion from the LastSystemUpTimePollUtc.InSeconds() - SysUpTime 
NOTE: Linux System Uptime OID: 1.3.6.1.2.1.25.1.1 --> HR System Uptime.
 

This information is stored in the NodesStatistics table from NPM 11.5 onwards. In earlier versions, it is stored in the Nodes table.

The sysUpTime OID is generally a 32 bit counter (max value of a 32 bit counter is 2^32 = 4294967296) or equivalent to 497 days (the OID is in 100ths of a second, and since it's 32 bit the max value is about 4.3 billion divide by 100 then 60 then 60 then 24 to get days, it's around 497 days). 

What can often happen is this counter rolls over or the SNMP service on a device is restarted on a device resetting the counter. Then Orion will poll the new value and detect a change, potentially causing Orion to consider the device to have rebooted or have a different uptime to what the device's CLI reports.

As Orion depends on what the remote devices responds to over SNMP it is difficult for Orion to catch such scenarios.

Orion will always compare previous and currently measured SysUpTime. If it detects possible reboot, by the fact that 'curentSysUpTime' is lower than 'previousSysUpTime', we say it's just counter rollover not reboot, if 'previousSysUpTime' was higher than 'rolloverThreshold' because "we were so close to rollover, that it must have been rollover."