This is not an advertisement by any means, just offering to help anyone who struggles with this as well. As an MSP, we have struggled with how to handle alert tuning in bulk with it comes to things like Interfaces (instances). Some of the interfaces you want to alarm as critical, some you want as error and others you don't care about at all. LM provided a partial fix for that with their Groovy based "Status" alarm based on the interface description, but it didn't take it far enough. We started creating manual interface groups called "Critical" and performing Alert Tuning on that "paren

I was using a complex datapoint (formula) as well, essentially checking if adminstate = 1, if true then using that as a multiplier against operstate and carrying that value through. If false, I was instead using 0 as the multiplier and alarming on anything greater than 1. A bit hacked, but effective.

This is very nice, and it also solves the issue of not alarming when the interface is admin down. Can I make a suggestion of not calling the Operational Status "StatusRaw" and just using OperState (similar to AdminState)? When will this be deployed to core?

When updating datasources from the repository, there should be an easy way to maintain your existing AppliesTo and alert threshold settings.

I would like to have the option within an alert rule to "continue" processing to the next rule. For example, we would like to handle integrations differently than email alerts. I we could create one rule at the top with the highest priority to take an action with our integration, then allow me to customize everything else in separate rules. The only other way to handle this is to add our integration to every escalation chain we create, which is tedious and will lead to manual errors.