Default Alarm Timeouts/Recovery

[streeb]

Due to various reasons we have a rather long-lived alarm relating to a secondary power supply that appears to have auto-recovered (via $SYSTEM) without the power supply actually being replaced. In addition I do not see an info level alarm indicating a recovery event. To my eyes it looks like there is some kind of default threshold within iMC that has recovered this after a period of 30 days. 

If my assumtpion is correct my question is, is there a setting somewhere in iMC whereby we can either extend this value for all managed devices or a specific device. Normally these sort of conditions do not hang around this long but there are occasional excpetions so we need to be able to manage this. 

Regards and thanks 

Mike

[LindsayHill]

How was the original alarm triggered? Via syslog, SNMP trap, or via SNMP polling?

I'm wondering if the original event was from a trap or log, and the data export policies have exported the old records, and the alarm was recovered at that point. Just a guess.

[streeb]

Lindsay, 

Thank you for taking the time to reply. The original event resulted in a trap. You may need to point me in the direction of the data export policies and whether there are options there to tweak things either wholesale or more granularly. 

Regards

Mike

[LindsayHill]

Look up "Data Export" in the Admin guide. This has some details about what options exist. It may also tell you how it handles unrecovered alarms.