Best Way to Specify Alert Destinations

In our ultra-simple SolarWinds installation, for alert destinations, we are currently using the alert defaults:

1. ${DefaultEmailTo} -- email destinations for all email alerts

2. ${DefaultEmailCC} -- unused

3. ${DefaultEmailBCC} -- SMS destination, phone numbers and provider gateways for all SMS alerts

This simple system provides a single place to add and delete destinations. Problem is, it doesn't scale and we need to change it.

We have considered creating a single custom property 'alert destinations' and then populate this field with Active Directory distribution lists. The problem with this approach for us is that our organization's DLs are messy. There is overlap, and also there are nested DLs meaning DLs within DLs that don't work in SolarWinds. My view is that this is the cleanest approach, but it requires a substantial reform of Active Directory SLs which is difficult from an organizational sense.

We could also create six or eight custom properties, e.g. Email_Destinations_for_Server_Team, Email_Destinations_for_Management, etc. Within the alert, the email destination would look like this: ${N=SwisEntity;M=CustomProperties.Email}This would work, but keeping the custom properties current and correctly applied to the nodes and applications would be burdensome and subject to error.

What I would like (but I don't think can be done) would be to just set a variable, e.g. Set {ServerTeamDestinations} = 'addressone.com, address two.com ...}. Then I would just need to reset the variable when the teams change.

Suggestions? -- Thanks! Brent

Find more posts tagged with

alert configuration

Alert

alert_settings

network_performance_monitor

default alert

npm

alert destinations

Alerts

Accepted answers

All comments

acf6276

The problem is that each alert has customized responses so you would still run into that issue when trying to automate. For example- I have paging alerts and email alerts for Node down and interface down. In order to build the trigger action for both alerts I have to have create a unique Trigger for each instance. The reason being is that the Message coming across my pager or email would not make any sense since its tied to the that Action alert.

bobmarley

We use a custom property such as 'Alert Destinations'. If your org's AD Distribution groups are a mess, rather than clean them up you can simply create some new ones like 'AlertingServerTeam@yourorg.com 'AlertingNetworkTeam@yourorg.com', etc.

For a lot of our custom properties we use Alert Actions to populate them rather than trying to manually keep up with them. So for example for a network node the alert trigger may be something like Vendor = Cisco and Custom Property 'alert destinations' IS Empty then the Trigger Action would be to Change Custom Property to 'AlertingNetworkTeam@yourorg.com' These actions we just run once a day to keep the properties filled in as needed.

If an AD Distribution group changes you can use an alert action to make the changes to all the existing ones as well.

adam.beedell

I like a small number of custom properties for this primarily

Either $owner or $down_contact, $cap_contact, $app_contact work nicely

You can use case statements in the TO which I dont reccomend

Nested DLs can work fine in my experience, it's maybe the security settings you're falling afoul of.

This sort of stuff is very dependant on each org's structure and what they want to achieve.

If you're using a bunch of custom properties think hard about how they'd get updated, you want the rate of updates to be greater than the rate of change

brentbo

Thanks for the reply, Adam. Since you say nested DLs can work I'll test them again. The idea of using CASE statements in the TO field is intriguing. Out of curiosity, why to you recommend against it?

brentbo

Thanks for the reply Mr Marely. The idea of using a daily alert to populate custom properties is excellent, and one that I will surely use. Thanks again!

adam.beedell

The UI definitely doesn't 'want' you to do it, it's a bit fragile. If you want to use commas or multiple large macros it can be quite hard to convince the UI to let you press save without messing it up.

Also if you format a macro wrong, solarwinds will give back the macro rather than an error, in the "to" field that can lead to unsendable mail so could reduce coverage if messed up

It's a valid and valuable complex solution, but simple is usually best until you really need to do something complex

adam.beedell

If you're send address is fully authenticated I'm surprused. If it's not fully authenticated then there's a per-DL setting to enable unauthenticated mail, or to authenticate it

(/w user/pass/actual mailbox/etc)

bobmarley

Here is what I use as the variable for my Custom Property named _Email_Nodes

In your environment it would be ${N=SwisEntity;M=CustomProperties.Email}

Whatever email address is places into that custom property is where the email is sent to. That way you only need one custom property. Using the alert actions you can populate this field automatically.

acf6276

How would this work for cell/pager #'s ?
Where is the Custom Properties value built and defined?