sysUpTime is mean: SNMPv2-MIB::sysUpTime.0 it's complete same as DISMAN-EVENT-MIB::sysUpTimeInstance
$ snmptranslate DISMAN-EVENT-MIB::sysUpTimeInstance -On .1.3.6.1.2.1.1.3.0 $ snmptranslate SNMPv2-MIB::sysUpTime.0 -On .1.3.6.1.2.1.1.3.0
Observium always uses maximum time of one of this (which avialable on device): 1. SNMPv2-MIB::sysUpTime.0 2. HOST-RESOURCES-MIB::hrSystemUptime.0 3. SNMP-FRAMEWORK-MIB::snmpEngineTime.0 4. unix-agent or os-specific Oid (from definitions).
In your case will used hrSystemUptime.0 = Timeticks: (13560578) 1 day, 13:40:05.78
Reboot trigger will happen if in next poll runtime this value less than previous more than 300 seconds.
Chris Macneill via observium wrote on 24/05/2019 10:17:
I'm observing a problem with some systems being reported as having rebooted at odd times, which are completely unrelated to reality. The GUI claims the system uptime is derived from the OID sysUpTime, however I can't find this OID in any MIB, maybe an internal label in Observium?
In actuality Observium seems to be using the 1st OID below, but as can be seen from the 2nd OID the two seem totally unrelated. In the case of this particular system, the 2nd OID value is when it was rebooted, the 1st one seems to have no correlation to the reboot time.
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (376806) 1:02:48.06 HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (13560578) 1 day, 13:40:05.78
Is there anyway to change the OID on a per device basis that is used to display and monitor System Uptime?
Observium CE 18.9.9420 (5th September 2018) OS Linux 4.9.0-8-amd64 [amd64] (Debian 9 (stretch)) Apache 2.4.25 (Debian) PHP 7.0.33-0+deb9u3 (OPcache: ENABLED) Python 2.7.13 MySQL 10.1.37-MariaDB-0+deb9u1 (extension: mysqli 5.0.12-dev) SNMP NET-SNMP 5.7.3 RRDtool 1.6.0 Fping 3.15 (IPv4 and IPv6)
Regards
Chris Macneill Web: www.cmit.nz
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium