Hi All,
Currently I am facing a data output dispute , If I'm checking Last (reboot/uptime) of a switch by loging via SSH it's totally different from the Last uptime showing in orion. Can somebody share his/her idea, it will be helpful for me. Thanks
This is been a frustration point for us as well.I've tried a few different sources I use when trying to determine uptime, sometimes asset inventory being accurate, sometimes core Orion.Nodes.lastboot (Local)AssetInventory_ServerInformationView.lastboot (UTC)
I haven't found anything that is correct for all gear
I ended up doing a blended [OR] check using both...if either I never got 100% confidence level on which should be used for what gear or if I was missing something
This may be just me butI have found that some systems/devices use a 32bit counter and while others are 64bit.This is OID, I think is used by Orion for the system up time - 1.3.6.1.2.1.1.3.0 sysUpTime.0 TimeTicksWhen the 32 but rolls over this cause a problem.So take this with a grain of salt.Also depending the platform it may have it's own system uptime OID.BUT, there is no where that I have found, to make a per platform change for the system uptime OID.
Then there is the whole idea of last reboot vs system up time.Last reboot tends to be a TimeStamp where System Up time is TimeTicksAlso does the platform reset uptime with a reboot or is system up time only reset at power cycle?
Yes you can go round and with this.
Again, this may be just me.
Yeah the data essentially is not 100% reliable acrross platforms. There's the age-old counter rollover issue.. also if the SNMP service restarts that resets system uptime so as to appear the system rebooted.
Generally speaking SNMP is flawed as a protocol for this purpose and is exactly why reboot alerts I put "possibly" rebooted, and if using SNMP polling method with the generic OID you can't just "trust" the data whole heartedly..
If the vendor MIBs have a better OID specific for systemuptime thats usually more reliable and I THOUGHT that could be changed with device studio but would have to check.
This is where a customer blames SolarWinds for the SNMP data it receives from the different hardware manufacturers. I've had this too. It is hard to make them understand that different vendors handle reboot/uptime SNMP data differently. No easy solution except finding a compromise by accepting the data output for either reboot and uptime and then utilising that in your availability charts. It makes it tricky if a customer wants to use this for their SLA's and availability.
