Modify Alert trigger Interval on the Instance level

On 7/27/2021 at 11:11 AM, Stuart Weenig said:

There is an official feature request already in the system for this. It's currently gathering support as in, the product management team needs to know that many customers want this feature before they can prioritize it. Everybody pile on.

This would DEFINITELY be appreciated (it's something we've also raised to our CSM too). It would ease the management & implementation of custom requests across our different clients for certain 'data sources' without having to create dedicated DS when those requests come).

There is an official feature request already in the system for this. It's currently gathering support as in, the product management team needs to know that many customers want this feature before they can prioritize it. Everybody pile on.

This functionality would be nice to have. We currently have many teams in our portal, and I've routinely had to clone DataSources to solve this issue. You can already alter the threshold at the group and instance level but it would be nice to modify the trigger interval for that threshold. For instance, we have several teams that want to be made aware immediately when the status of their interfaces goes down, but other teams would rather it be down for several polling cycles before being alerted. Having multiple DataSources solves this but turns into a decent amount of upkeep. 

19 hours ago, Clayman said:

Bump. I cannot believe this isn't available yet. Most of my experience is with SolarWinds in the past & it has always had this capability.

In my scenario, I've got some remote sites that frequently lose internet connectivity for several minutes. I do not want to trigger an alert each time this happens. I would like to be able to extend the Alert Interval for those specific sites so that they have to be down for e.g. 15 minutes or more before alerting.

As a longtime SolarWinds user, they have NOT always had this capability innately. But they have always had a workaround similar to what is available to LogicMonitor--proliferate the number of logical objects you would have to maintain that controls alert trigger delays. In SolarWinds, this would be Alert Definitions. Not ideal. Hypothetically you could have used a component-level configuration field (notes or description) and used that in a complex SQL/SWQL-based alert definition to achieve this. Also not ideal. 

In SolarWinds SAM, they have added (in the past couple of years) the ability to define custom alert trigger delays on a per component basis, natively. 

Bump. I cannot believe this isn't available yet. Most of my experience is with SolarWinds in the past & it has always had this capability.

In my scenario, I've got some remote sites that frequently lose internet connectivity for several minutes. I do not want to trigger an alert each time this happens. I would like to be able to extend the Alert Interval for those specific sites so that they have to be down for e.g. 15 minutes or more before alerting.

5 month bump... 

Adding this capability to the Alert Thresholding Wizard is another way to go about doing this, which I'm fine with as well. Same concept--allow this at all levels from device groups to datasource instance. 

One app I support doesn't give a rat's donkey if CPU is pegged at 100% for more than 30 minutes in the overnight hours, but another app owner want's to know if it's over 50% for 10 minutes. I don't know how to manage without angering one of these teams or juggling overlapping datasources. 

Almost 2 year bump....

Using a mechanism similar to what was created for Polling Interval would work beautifully here since we can now assign properties to instances now. I'm imaging that this property would look something like: <DatasourceName>.<DatapointName>.alerttriggerinterval

If it's assigned at the device-level, it applies to all instances. If applied at an instance-level, then it would only apply for that instance.

My team supports many dev teams. One wants to know almost right away if an AWS ELB has incremented an UnHealthHost. And naturally another dev team doesn't care unless it's something that lasts for over an hour.

I really don't want to (continually) manage multiple clones of a datasource LogicModule with the same set of metrics.