Regarding Alerts/output in orion

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 <3
    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 but
    I 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    TimeTicks
    When 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 TimeTicks
    Also 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.

  • Great article! I realized these are my favorite kinds of GI articles. Enough news and reviews, more stuff like this! Let the writers get creative!

    mybkexperience.com

  • 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.