Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Better Method of Calculating Uptime

So we just made the mistake of updating (adding) our SNMP community strings on our servers and restart the snmp agents to get the settings to take. What we failed to realize was that Orion reads the uptime of the SNMP agent as the uptime of the servers. BAD BAD BAD. Lots of false reboot messages to lots of people. Needless to say, we are now scrambling to provide a REAL uptime calculation.

So we are requesting that two things occur. First, server uptime be moved from OID 1.3.6.1.21.25.1.1 to 1.3.6.1.2.1.25.1.1, which is actual server uptime, not the agent. Second, some additional checking occurs when Orion sees the counter reset. On windows this could be check the event log for a Shutdown Event / Reason (this would allow Orion to flag the reboot as intentional vs. unintentional). There has to be some similar log on linux.

Please chime in if you would like to see this sooner rather than later.

Edit - To further support my cause, other posts on the topic are below:

Find more posts tagged with

Accepted answers

All comments

MarieB

Wow John--great post. Will make sure PM sees it.

KwameB

Adding my name to the the petition

adauria

Add my vote as well.

As a potential solution / work-around, adding the conditional test "time goes backwards" to the advanced trigger options might help.

This test would check the current value read from an OID against the previous value and if less than the previous value, the trigger fires.

just an idea.

FormerMember

Sooner.

Starting to monitor more Linux hosts and tired of seeing incorrect uptime and in the daily Event Summary as a "Node Rebooted".

jspanitz

Missed this recent request for the same thing:

And a similar request for APM:

If we keep raking in the votes, we are gonna be moving on up, to a deluxe apartment in the sky.

MrSampsonite

Just an FYI - I'm using the performance (perfmon) counter System Up Time under 'System'. It returns a value in seconds that is accurate no matter if snmp restarts, event log service restarts, etc.

My alert is based on this value being less than 5 minutes. The idea being that if the server reboots, within the first polling cycle, Orion should detect this value is less than 5 minutes so it must have rebooted.

Plus there's the added bonus of converting this seconds into various periods. I have a report that shows the value in days, minutes, seconds, and the last date it rebooted (today's date minus the seconds).

Thoughts?

julrich

Adding my vote.

1. Reporting SERVER Uptime based on SNMP Uptime is a LIE! I cannot accurately tell my company the uptime of ANY device we have.

2. Multiple times we have experienced issues with the SNMP service on a windows machines, or the snmpd process on Linux machines and have to restart the service/process. Every time this happens, I have to ReplyAll to the alert email that gets sent out saying "I'm sorry, Solarwids Orion is reporting a false alarm. This was not a reboot, rather this was me resolving an SNMP issue."

kcarson

throw me on there as well.. this is something that needs to be done. I can't for the life of me figure out why uptime would ever be based off of a service that can be recyled. just my 2c

FormerMember

I'm in for this change as well.

borgan

One more vote here.

byrona

I agree that using a counter that can easily be reset to determine Uptime is generally a bad idea and fully support considering a better solution.

However, the problem with the suggested solution is that the OID 1.3.6.1.2.1.25.1.1 only exists on most servers but not on other SNMP supported devices such as Network gear. If we are going to move to a new model for Uptime calculations I would like to see it support all devices, not just servers.

jspanitz

Byron - we completely agree. If it can be done in a way that works for everything, great. If it needs to be done two or more ways depending on the hardware, so be it. As long as it is true uptime!

byrona

Byron - we completely agree. If it can be done in a way that works for everything, great. If it needs to be done two or more ways depending on the hardware, so be it. As long as it is true uptime!

I totally agree!

MarieB

Hi All--

I've marked this for the PM to review.

Thx,

jshrestha

Absolutely agreed!!!!!!!!!!!

dfairles

Add me to the list.

This is making my users not trust SolarWinds.

Even switch from one poller to another can trigger this.

Atamido

I created a partial workaround for creating a report that can be displayed in Orion, here:

Atamido

I created a partial workaround for creating a report that can be displayed in Orion, here:

ctopaloglu

Count me as well.

ctopaloglu

Duplicate message please remove.

rjager

Add me to the list as well, the current info is not valid for our windows boxes.

I also have a doubt aboubt valid info that comes from our ESX servers.

teqnomad

Hi,

Can anyone confirm the recommended method for triggering an alert for hrSystemUptime?

I'm a newbie to Solarwinds. We have NPM v9.5.1.

I've sorted

1. configuring a custom universal poller (called hrSystemUptime which uses the hrSystemUptime MIB), assigned it to a network device (called testSLESVM), tested that it was able to communicate with the network device using the test button inside the assign wizard in the custom universal poller program,

2. I've then tried to configure an alert in the advanced alert manager program with these settings:

On the trigger page setting the following simple conditions:

PollerName equals hrSystemUptime
Nodename equals testSLESVM <-- name of the test
Status not equal to 0

On the action page send an email with a message including Pollername, Status and RawStatus, but these 'status' values dont seem to look like timeticks units.

For the time being, I put the polling time at 1 min and set 5 secs on the length of time for condition, so it would be reasonably sensitive during my testing.

It seems that the first time I reboot after setting the triggers, it works and then it fails to respond to further reboots, until I change the triggers and then resave with the Status not equal to 0, which pops up a message saying it is clearing the history, then it seems to work again just once. I've tried acknowledging the advanced alert in case this reset the Status but this doesn't work.

Am I using the right trigger conditions? Why is it only working once then needing history cleared.

Which field is the actual 'uptime' value.

I've looked at a lot of the similar issues in the forum, but the SQL queries suggested seem overly complex.

At this point, I'd be happy just getting the value of uptime into every email sent, and then using an outlook rule to only send emails with small uptimes to my work phone.

Any suggestions?

xtraspecialj

The best solution would be to allow us to create custom Status & Response Time pollers in Manage Pollers (aka: Device Studio). Currently we can only replace CPU, Memory, and Node Details system pollers, but if we could also create our own Status & Response Time pollers then we could create packages that look at better System Uptime OID's for devices that support it and then for the devices that don't they would just use the native poller values.

So while this wouldn't fix the problem for all of our devices, it would at least fix it for the devices that could support it and hopefully lighten our instances of false reboot alerts.