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 "parent" only to find out that it doesn't work as interfaces move in and out of it. I was beyond disappointed, but it said it right at the top of the page: Changes made to Alerting or Thresholds will only affect existing instances currently in this Instance Group. Instances added later will not be subject to the changes. Anyway, long story short we finally decided to write our own application to do it and built it in Azure. We built it to handle multiple data sources so we could group other instances (like VMware vDisks) and do the same bulk changes. It was written to be a data source in your environment, so that you can apply it to whatever devices you want and just call out to the API with the device name. If you have any interest in using it, let me know. There are costs associated as Azure bills based on usage, but it is pretty small for us (< $200/mo). Trust me, I wish LM solved this without having to write the app!

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.