Using the Orion Alerting Engine to Assign Custom Properties

Without too much preamble, automation solutions can make our lives easier in two major ways:

  1. Reduce the time needed to do tasks manually
  2. Reduce the number of errors injected by the humans doing the manual work

I’ve always been a fan of automating as much as possible. That’s one of the reasons I got into using scripting languages (PowerShell in my case) as way to help me save time. If a process takes 30 seconds to do a task, but building an automation for the task takes 15 minutes, then why bother? Simply put, if the task only takes five seconds, but I need to do it more than 30 times in the future, then it’s a net savings on my time.

But I hear what people are saying, “I don’t have time to learn a new language. I’ve got enough on my plate as it is.” 10-4 good buddy, I’m reading you loud and clear. Therefore, I want to begin our discussions with automating a single simple task in the Orion® Platform.

Today’s lesson is about using the Orion Alerting Engine to do some of your more tedious tasks – in this case, updating Node Custom Properties. We’ll start by defining the scenario used for this example.

Scenario

Your organization has hundreds if not thousands of nodes being monitored, but they’re spread all over this blue marble of ours. They might be in a data center across town, in a different state, sitting in a rack in another country, or they might be in a cloud infrastructure somewhere in the ether. Long story short, sometimes location is important to know, even if you aren’t in real estate.

Since we’re clever IT people, we’ve devised a naming scheme for our devices and all devices (network gear and servers) use the naming scheme. For things in our East Coast Data Center, the first four characters of the device name is always “EAST.” Simple enough to start, but if I wanted to have alerts, reports, dashboards, or permissions specific to these devices, it wouldn’t necessarily be point-and-click.

Enter Custom Properties

You can build Custom Properties for pretty much anything monitored via your Orion Platform.  Nodes, interfaces, volumes, applications, storage arrays, virtual hosts, and more. By my current count, there are 24 different element types that can have custom properties assigned on the Orion Platform.

Custom Properties can be used in any number of ways, but I like to think of them as one of the hidden superpowers of the Orion Platform. I’ve used them for nearly everything over my tenure with SolarWinds® products, but I think my favorite is for organizing elements without an easily discernable commonality. I’m only going to cover one scenario here, but we’ve talked about custom properties before, so I’ll provide a few links here if you want to get some more reading.

Additional Custom Property Resources

For our scenario, we’ll build a Node-based Custom Property called “Region.” If you already have one with this name, but you still want to play along, choose another name. The only caveats for Custom Properties are you can’t use a reserved name and you can’t have spaces or some punctuation in the names. This second only seems to occur when people want to use multiple words for a Custom Property name – and I either go with “TwoWords” or “Two_Words.” I’ve used both in the past and feel like the former is my preference as of today. (It might change tomorrow.)

Building the Custom Property

For my scenario, I’ll build a Custom Property for Nodes. I go to my Main Settings & Administration page and click on Manage Custom Properties under Node & Group Management.

If your page looks drastically different from this one, then you aren’t running the latest version of the Orion Platform products. You can still do the same work in the legacy version of these pages, but I find working with this layout much easier. (Hint: Upgrade Orion – you can thank me later.)

To build a new Custom Property, click Add. Then, making sure the Entity Type on the left is set to Nodes, I’ll fill out the information.

I elected to have some predefined values for this Custom Property, so I won’t have to worry about typos if other people change them. Once you hit save and see the green message at the top, you’re done and can go elsewhere. For our next step, we’ll build out the automation to automatically assign these values for us.

Automating Assignment

With the Custom Property defined, it’s time to go through our thought process for automating the assignment. For our scenario, I want any device whose Node Name (as listed in Orion) to have Region set to “East Coast Data Center.”

Additionally, I can exclude any nodes where the Region is already defined as my desired name.

This can be more helpful when I write it out in pseudocode. I find this handy since it’s something I can refer to later. (If you’re feeling adventurous, you can create a Custom Property for Alerts called Pseudocode and put this in for the alert.)

If the Node Name starts with EAST and the Region is blank is not “East Coast Data Center” then set Region to “East Coast Data Center”

With my logic in place, I’m not ready to go forth and build the alert. I navigate to manage alerts and click Add New Alert.

Alert Properties

The alert properties are the easiest part here. Give it a logical name and description. For our scenario, this only needs to be checked infrequently—let’s say every 24 hours and the severity of the alert isn’t important at all, so we’ll set that to Notice.

Out of habit, I like to keep all alerts disabled to start, just to be 100% safe, but if you feel like living dangerously, I can’t stop you.

Once happy, you can click Next to move onto Trigger Conditions.

Building the Trigger Conditions

Here’s where writing out the pseudocode helps a bunch. It’s time to build our conditions for triggering this alert.

If you’re interested in what’s happening “behind the scenes,” you can click on the condition group and select Show SWQL.

This can be useful if you ever get to a place where you need to build an advanced alert.

What is a Null Value in a Database? Some Words About Null.

Why are you using “is empty?” By definition, “is not equal to” something implies empty would qualify, right?

For you, I, and other humans, yes, that would be correct, but Null (which is distinct to an empty string) is something else entirely to databases. Handling comparisons with Null values could take up pages of documentation—I know, I’ve read several of those pages—but suffice it to say, it’s easier to use this whenever you work with strings or text when using negation operators (not equal to) to be 100% sure.

Reset Conditions

Since this is a simple trigger, but it’s running infrequently, I’m being especially paranoid since I don’t want to see this in my Active Alerts list for a long time.

I chose Reset after one minute to have the Orion Platform clear the trigger after one minute instead of waiting until the next time it does the check.

Time of Day

I want this to run at any time, so I’m keeping the defaults here.

Trigger Actions

Now it’s time to do the actual automation. For the actions, add a new action and from the list select Change Custom Property (probably the first thing on the list).

Give the action a name, select the Custom Property to update, and select the value to assign.

I don’t care about the time of day or anything else, so those are the only settings I need.

Reset Actions

Since I think of this alert as “one way” (meaning it doesn’t get reset by conditional logic), I elected to skip reset actions.

Alert Summary

Finally, review your alert and be sure to check out the box at the bottom telling you how many objects would trigger this alert.

This looks right and it’s time to save it.

The Automation Results Are In

After you’re happy with your alert, you can enable it and wait for it to fire. After a few seconds of waiting, I saw two new entries in the Active Alerts screen.

They were there for only a minute (as designed), then they were gone.

If we look at either of those Nodes, we now have the Custom Property defined.

Extending this Automation

Now that you know it works for one thing, how about another, and another. Granted, this is a simple scenario, but you can see the power of having the system do this work for you.

What’s nice about the alerts is you can click Duplicate & Edit and change the settings for each location. If you have dozens, or hundreds of things you want to set this way, you can export the alert and manually edit the XML and then re-import it—but this is only for the truly adventurous.

If you want to try my alert out, I’m including an Alert file you can just import into your own Orion systems—but be sure to define a Node Custom Property called “Region” before you import it, otherwise you’ll get an error.

Next Steps

Since this Custom Property is geographical in nature, I’d probably build a group with a dynamic query in the Orion Platform to check for the matching Region value. This way, as devices come in or out of monitoring, I know that group is an accurate representation.

Have you done anything clever with the out-of-the-box automations in the Orion Platform? If so, I want to hear about them. Leave a comment below and tell me about how you’re saving time by automating your environment.

Anonymous