Alert - Populating Alert Custom Properties with Variables

Question

Hey everyone,

I have been working on some dashboards and reports and the alerts themselves tend to get a little unruly on the SWQL side of things.  Long story short we have an email custom property on the various objects in the environment (Volumes, Nodes, Applications, etc...).  We then base our email action item to populate with said custom property (The to line will be some kind of variant of ${N=SwisEntity;M=CustomProperties.EmailAddress}).  This has allowed us to simplify down to a core set of alerts that go to the correct team or teams, without having to hardset alert actions with variations of the exact same alert.  Before we implemented this approach, almost every application template would have its own alert.  As well as having multiple variations of the same alert (I.E. high cpu, node down, etc...) targetted to different teams pending the node owner.

The alert action itself works great, but my alert queries tend to include a case statement where I'm setting a Alert column that is populated based off of the EntityType and then flagging the EmailAddress custom property from that entity.  This also requires me to make alot of links from the Alert Object to the custom properties tables of the various objects.  Ideally what I would like to do is add an Email custom property to the alert, and have that populate with the value from the triggering object.  So far in my tests, the Alert Custom Property is just populating with the exact text I put in the field instead of the content related to the variable.  IE the Group By for Email under active alerts shows "${N=SwisEntity;M=CustomProperties.EmailAddress}" instead of "address@domain.com."

I'm assuming this has to do with the custom properties being linked and populated with the alert itself, instead of being generated at the time of the alert.  Hopefully I'm just doing something wrong.

Anyone have experience with implementing this?

SteveK · Answer

Sorry for the wall o text, I know I'm getting into some weird concept areas.

So what I was hoping to do was populate the custom property in the alert with the custom property from the node/application/volume/etc....., similar to what I'm doing with my alert actions.

For example (I'll go object -> Custom Property on object -> Value specified to CP object)

Node1 -> Node_Mail -> GroupA@domain.com; GroupB@domain.com

Node2 -> Node_Mail -> GroupC@domain.com

App1 on Node1 -> App_Mail -> GroupA@domain.com

App2 on Node1 -> App_Mail -> GroupB@domain.com

Vol1 on Node1 -> Vol_Mail -> GroupA@domain.com; GroupB@domain.com

App1 on Node2 -> App_Mail -> GroupC@domain.com

Alert1 is node down email Node_Mail

Alert2 is app down email App_Mail

Alert3 is email Vol_Mail when volume is above threshold

So the alerts as described above are working.  If Alert1 is tripped for Node1 it emails GroupA and GroupB,if it fires for Node2 it emails GroupC.  If Alert2 trips for App1 it emails GroupA and for App2 it emails GroupB.  This part is working as designed.

The problem, or I guess more so annyoance, is the complexity of the queries I'm writing for modern dashboard widgets.  I'm basically linking the AlertActive to AlertObjects, then doing multiple left outers from AlertObjects  to either the custom properties table of the object or to the object then another join to the custom properties.  Then building a Case column for mail based on the object type.  This then allows me to present the active alerts for the specific team/distribution list on their page.  As well as provide an email address and/or responsible group on a more global dashboard for managers.  Additionally I have some alerts that only show in the SW console itself, so I'm able to still using the same email property from the object, so looking up the To field in a query wouldn't really work.

I was trying to think of ways to simplify the queries and process, and the first thought was to keep my alert structure as is, but include Alert_Mail (or some variation) as an alert custom property, and populate that with the custom property from the triggering object.

So if Alert1 would fire on Node1, Alert_Mail would populate with GroupA@domain.com; GroupB@domain.com.  Then if App1 on Node2 would fire, then the same Alert_Mail would populate with GroupC@domain.com.  This would then allow me to reduce the amount of joins/case statement and simply build a link between the active alerts, the custom properties, and do a look up against that with the email for that team.

KMSigma.SWI · Answer

OK - can we connect Active Alert --> Alert Object --> Alert Configuration --> Alert Configuration Custom Properties? Yes, absolutely.

However, that feels like it might be more work than it's worth considering the upkeep might be more than you'd want going forward.  You'd be forced to edit the alert to make these changes anyway.

Like @bobmarley, I've used an Email_1_To, Email_2_CC, and Email_3_BCC in a past role bound to the objects themselves (Nodes, Applications, Interfaces, etc.).  [I used the numbers so that the custom properties appeared in that order on pages - I was a stickler for dumb stuff like that.]

I'm trying to understand why using an alert custom property for the email would be any different that just editing the alert definition.  I may be overthinking it, but if you could #ELI5 why you are doing it this way, that might help.

bobmarley · Answer

I have been using a group that I created called _Email_Nodes in my alerts and it works fine. This is being used for Node Down events.

I suspect the issue you are running into is with the variable use for the Custom Properties.

Custom Properties can be set up for any of these different entities. The one I listed above is for the Nodes entity.

An Application based alert may need to use an Application based custom property, just my guess

Which ends up being this variable for the Application Custom Property I created called _Email_Application

${N=SwisEntity;M=Integrations.Application.CustomProperties._Email_Application}

So I believe you may need to use the Application Custom Properties in your case.