drewl

Can you provide a bit more information on the log manager? Is it this? 

I doubt that a mere update to net-snmp will change the limitation. The OID for hrSystemUptime is defined as below The value for timeticks is defined as a 32-bit integer (see link to RFC2578 my post above). From /usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt: hrSystemUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only…

I have also upvoted this, as well as putting in a feature request via support. Its quite clear to me that at least with regards to linux+Net-SNMP, Orion is using the incorrect measure for measuring system uptime. Without going into too much detail, I can force a false negative "system reboot" to occur and resetting the…

A unified alerting engine would be great -- as long as migration from the old-to-new works! I have no desire to transfer, by hand, the many snmptrap and alarm rules we currently have in place.

Appreciated!

To my knowledge, there is no solution for this. The limitation is programmatic, the integer is limited to 2^32 timeticks.

I know this has a status of "What We're Working On", but I've just had such a rough time editing rules today I feel i need to throw my 0.02$ in... I've been working with our trap sink server today, trying to track down a broken trap rule. It's not been a fun road just because the Alerts/Filter Rule Manager is just so…

No syslog rules, we have dedicated syslogging hosts for that. 375 *enabled* rules. More than 400 total. The type of gear we have in service is _very_ trap heavy, for realtime events that our NOC has to respond to quickly.

If you are seeing erroneous reboots after 497 days, the 32-*bit counter for timeticks has rolled over back to zero. If you google for "timeticks 497 days" you will find tons of references to the 32-bit counter. The TimeTicks object is limited to a 32-bit non-negative integer as per RFC2578. 7.1.8. TimeTicks The TimeTicks…