There are a couple of ways you can approach this. From within Spectrum, you can do it with custom Event Configuration settings and chained Events. Basically, you'd take the original Event you want to deal with, and set it to not generate an alarm. Then, you'd add Event Rules to the event, and use the Event Rules to generate new Events that could potentially be alarms, depending on the name of the device.
Basically:
- "thing" happens (trap, poll, device unreachable, etc.)
- "thing" is mapped to Event 001
- Event 001 has Event Rules defined for it
- Event Condition 1: If name matches "foo"
- Generate Event 002
- Event 002 is set as a Minor Alarm
- Event Condition 2: if name matches "bar"
- Generate Event 003
- Event 003 is set as a Critical Alarm
We use this for a number of cases. However, in some cases the Events become awkward, or we need to do things that can't be done with EVents. And, sometimes we still want the alarms handled the same in Spectrum, we just don't want people paged the same, or tickets created the same. To get around that, we replace the stock SetScript, UpdateScript, and ClearScript with a custom Perl script that does a bunch of normalization and filtering on the Spectrum alarms. The script then passes the "important" alarms on to our ticketing system. This gives us more flexibility to filter out the "noise", while still being able to view it as informational in Spectrum.