Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > Understanding Reset Condition Logic - Video

Understanding Reset Condition Logic - Video

 Updated June 6th, 2016


The reset condition determines what constitutes a resolution to an alert that has triggered. This video demonstrates how to create reset condition logic. 






             Orion Platform v2016 and above.

Server & Application Monitor  v6.2.4 and above

Network Performance Monitor v12 and above

Virtualization Manager

Network Traffic Analyzer         

Storage Resource Monitor  

Network Configuration Manager 

Web Performance Monitor

IP Address Manager

User Device Tracker                                                        

VoIP & Network Quality Manager

Video Transcript

I’m in the process of building a new alert, which I have named “Critical States.” But I don’t have any trigger condition logic yet, so I’ll add that here on the Trigger Condition tab. The first thing I need to set is type of object I’m alerting on. This determines which tables and fields you’ll have available for building your condition logic.
In the “I want to alert on” dropdown, at the top of the list you’ll see common alert object types, with a few dozen additional object types listed below. At the very bottom of the list you have the option of building a custom SQL query.
Remember, the alert engine only looks at the database.  So all the alerts are SQL queries, but the alert editor almost completely eliminates the need for you having to write those queries yourself. But still, you do have that option.
The alert object type defaults to alerting on a node, which is what I want in this case.
The next section defines the alert scope, but I’m going to skip that for the moment and jump down to the Actual trigger condition section. And here is where I’ll add my alert logic.
When I click on the plus at the bottom to add a new condition, you can see that there are three different condition types to choose from; single value comparisons, double value comparisons, and And/Or blocks.
Whenever you start a new alert you’ll have an And/Or block already added at the top of your condition list. And below that you’ll add your additional conditions.

Double value comparisons are used when you want to compare one field to another field in the database. But I don’t need that right now, so let me get rid of this condition and start with my single value comparison condition.
The first field in the condition indicates which database table the alert engine will query. Based on the object type field up above where I said I want to alert on a node, the node table is selected by default.
But if you look at the dropdown list, you’ll see other tables that relate to the object type you’ve selected, which opens up more of the database to you for building more advanced alerts.
Next I’ll choose the specific field to query. In the dropdown you’ll see a list of recommended fields at the top, followed by Custom Properties and Recommended Events. And then if you scroll all the way down you’ll see Browse All Fields, which again lets you dive deeper into the database.
I’ve named my alert “Critical states.” A node being down would be the most critical state, so I’ll start with that.
So I’ll Choose “status” for the field to query, and then I need to choose the expected value for the status field.
One of the nice features of the alert builder is that once you choose a field to alert on, it will query the database for you and show you all the values for that field in the database. So you don’t necessarily have to know or type in the return value, you can just select it from the list.
And I’m going to choose the status of Down.
Before I do though, notice that there are several other status values listed in the database. When you’re building your alerts, you’ll need to make sure that you’re accounting for those other possible variables in your alert logic. For example, rather than setting my condition to alert me when the node is down, it might be tempting to alert anytime the node is set to any status other than “Up.” The problem is that would most likely result in a lot of false positives because you’d be alerting on statuses that don’t necessarily make a lot of sense to include in a single alert. So when you’re building your alert logic, you need to be very specific in what you want the alert to do. If you want to alert on multiple statuses, you should probably include a condition for each status you want to alert on.
Alright, so I have my first condition set. I’m alerting on any nodes in the database with a status equal to down. But I’ve named my alert “Critical States,” and right now I only have a single state, so I’m going to add another condition.
I’ll add another single value comparison, and this time I want to alert if my CPU utilization is over 90%.
The trigger condition tab is what determines whether an alert event has occurred. That’s the real logic of the alert.
The reset condition tab of course determines what constitutes a resolution to that alert event.
I’ve already set up my trigger conditions, so let’s look at the reset conditions.
On the reset condition tab, I have four options.
You'll notice that the No Reset Condition option has been pre-selected. This one is pretty straightforward.  If I’m alerting on a node going down then every time the node goes down an alert will be triggered.

Now while this is a very simple reset condition, you do have to make sure that it actually matches the alert you have built. You should be as careful about your reset condition logic as you are about your trigger condition logic.
Suppose I do have an alert where my explicit trigger condition logic is alert when node status is equal to down. If my reset condition is set to reset this alert when trigger condition is met, then that alert will trigger each time the condition is met. Now while the majority of the time you could probably get away with that,
Similarly you might be alerting on things like resource utilization that have a tendency to change very quickly. If I’m alerting on CPU utilization above 90%, I’m probably not going to say “trigger this alert each time the condition is met” because the CPU utilization may dance back and forth on either side of that 90% mark, which could cause the alert to consistently trigger again in rapid succession. You don’t want multiple alerts on what is really a single alert event, so if that’s the type of alert I’m building I’d probably look for a better reset option.
For both cases I just mentioned, quite possibly a better option would be to create a special reset condition for this alert.
With this option selected, I can create a new condition, and add reset condition logic just exactly like I added my trigger condition logic.
So for a node down alert, I would reset when the node status is equal to UP.
To make it easier to set up the reset condition logic, you can choose to copy your logic from the trigger condition tab.
Now for my CPU utilization, rather than resetting as soon as it drops below 90%, I might set a new threshold and say don’t reset the alert until my utilization drops back down below maybe 75%.
No reset condition and create a special reset condition are the two most commonly used reset conditions. But you’ve got a few more choices too.
You can reset the alert automatically after a set period of time. This would be useful to alert you to the fact that an alert state still exists. For instance, by alerting on high CPU utilization or something similar and resetting the alert after a set period of time, let’s say 15 minutes, you’d get a new alert every 15 minutes as long as that CPU utilization stays high. So this reset condition can be used as an update to say the alert condition still exists and needs to be resolved.

Last modified