Can't drill down and find the reason for a device in warning state

John-AVUSD

I uave a lot of UPSes to monitor and I have gotten email alerts that a group of them is in a warning state. When I view the alerts in SoalrWinds, it does tell me which UPS, but no matter where I click on the specific UPS, I can not find the root cause of the alert.  The only thing that looks to be close is " percent memory used " that I can see when I hover over the device. That would make sense with a swich, but I don't think a UPS does much and doesn't need much memory.  There's nothing I could do about it in any case. 

It would really be great if SW gave a direct link to the state that triggered the warning and not just the whole device dashboard of details and made you hunt for the cause. 

weston.hood

You've discovered the exact reason why you should avoid using group alerts. However, an alert variable that you may want to include in your email and help you out in the short-term is this:

${N=OrionGroup;M=GroupStatusRootCause} 

 (provides group member status for each node in group)

I would highly recommend using Custom Properties for your grouping needs wherever possible. One area where groups really shine though is when you have a service or failover application pool. For example, a web portal end users log into. You can place multiple entity types into a single group. So you can include the IIS/Apache monitor for the site, the disk drives of the server, the server itself, the SQL backend monitor supporting the site, and any disks/storage associated with that, and any network devices between the two servers. All related entities can be put in one single group and you can see if that web portal may be affected by one of the mentioned components. The bonus of groups is that multiple entity types can be put in a group. Even groups themselves. But that's basically where the bonuses end for conventional groups. Custom Properties are a superior grouping method for alerting, reporting, view limitations, and even account limitations. You can even dynamically assign Custom Properties using alert actions.

So for your example, what I would propose is using Custom Properties for grouping, and using a node-based alert as opposed to group alert. And you could use this email variable to provide you the child entities causing the UPS to go into its corresponding status:

Child Entity with link: ${N=SwisEntity;M=NodeStatusRootCauseWithLinks}

If you want to know what metrics can change node status, visit Settings > All Settings > Node Child Status Participation