This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

ssCPUIdle deprecated net-snmp 5.3 and ssCPUIdle bug 5.2

I'm currently running NPM 8.5.1 SP3.  I've run into the following net-snmp 5.2 bug on a Linux system where ssCPUIdle is 99 for about 1 min then goes to 0 whith 62 days of uptime causing orion to show and alert 100% CPU utilization and all tools, top, vmstat, dstat, sar, etc show 0 utilization.  We've looked into upgrading net-snmp to 5.3 and 5.4 but in those versions of net-snmp ssCPUIdle has been deprecated not allowing CPU resource to be listed. 

Has anyone run into a similar issue? 

Does anyone know if Solarwinds has a patch or workaround to force the "list resources" to look at the CPUraw values against net-snmp nodes?

  • Hi,

    Does anyone know if Solarwinds has a patch or workaround to force the "list resources" to look at the CPUraw values against net-snmp nodes?

    This is a feature request (for internal guys #9364). A work around would be to create a Universal Device Poller to poll the CPUraw oid on the Net-SNMP nodes.

    Upgrading to Orion 9.1 SP5 will not fix your issue but will allow you to use the Universal Device Poller utility which makes easier to poll non-standard OIDs.

    Universal Device Poller Tutorial

    HTH,

    Yann

  • Yann, thanks for the quick response but upgrading to a new major release with a service pack is not a viable option for me.  I'm currently monitoring several hundred customers in this production environment and there is a significant difference between 8 and 9 that I would need at least a month or more to QA before i could possibly deploy.  This does give me the idea to use the custom mib poller but i've heard it can be buggy and would impact my current customer alert schemes and reporting. 

    Is the an ETA for this feature and will it be supported under version 8.5.x?

  • Is the an ETA for this feature

    I will let someone from the development team reply to this as I do not know.

    ... and will it be supported under version 8.5.x?

    New features and fixes are only added to new releases and/or Service Packs, so it will not be 8.5.x .

  • I may have fixed the issue.  we compiled several versions on one system on different ports to test with and finally came to a version of 5.4 where now net-snmp puts cpu values back under the hrProcessorLoad in host-res.

    Compiled, NET-SNMP version:  5.4.2.1

    FROM :www.net-snmp.org/.../FAQ:Agent_34

    With the 5.4 release, there is now a cleaner framework for reporting on multi-CPU equipment, and it is hoped that an increasing number of systems will be able to report suitable processor information. Also with the 5.4 release, for the first time the agent will report the hrProcessorLoad value properly, which should provide some simple per-CPU statistics.

    I'm not sure if this is 100% correct but the way i believe Orion works is it first checks that value to see if it exists and if not it drops down to the UCD to find proc and memory values and then tags it as net-snmp.  This node was already added in orion with the version of net-snmp that contained the bug and i don't beleive the redisocvery was retrying the hrProcessorLoad oid again when i was relisting resources.  I removed it completly and readded it because i couldn't get rediscovery to work either and now it's pulling CPU info.  The bug with 62+ days uptime does not seem to affect the system.  Also note, net-snmp 5.4 no loger finds any UCD and responds back without out of tree error.

    snmpwalk -v2c -c blah localhost .1.3.6.1.4.1.2021
    UCD-SNMP-MIB::ucdavis = No more variables left in this MIB View (It is past the end of the MIB tree)