Submit a ticketCall us

AnnouncementsFace your biggest database issues head-on

Our new eCourse helps you navigate SQL Server performance blocks by teaching you how to recognize and deal with the three DBA Disruptors: Performance Hog, Blame Shifter, and Query Blocker. Register today to learn how to defend your environment and fend off menacing disruptions.

Register for your free eCourse.

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

Understanding Trigger Condition Logic - Video

Updated March 11th, 2016 


This video demonstrates how to set up trigger conditions for new alerts using the alert builder. The video reviews how to use single value comparisons, double value comparisons and and/or blocks.



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

So I’m going to select CPU load and set the return value to 90%.
But this time, I need to change the condition qualifier from is equal to to is greater than.
And in fact I need to change the condition qualifier for my and/or block as well. If you look at the alert as it is, I’d only be alerting when the node is down AND has a CPU utilization above 90%. That’s not going to work,
so let me change this from an AND statement to an OR statement.
Now if either of these conditions are met, I’ll have an alert event. Make sure you pay attention to your condition qualifiers. But I’ve decided I don’t want to look at CPU utilization all by itself, I want to look at memory utilization as well. I want to alert when both CPU and memory utilization are above 90%.
So I’ll add another condition.
The first challenge here is making sure I have the right field selected. Notice there is a Memory used field, and a Percent Memory used field. Watch out for fields with similar names.
I want Percent Memory Used, and I’ll set my return value to greater than 90%.
But now I have a problem. I want to alert when both my CPU and Memory utilization are above 90%, and right now I’m alerting when either of them are over 90%. So I need to add a new condition.
I need to add an And/Or block and I need to move my CPU and memory conditions into the block.
You can move conditions around by drag and drop.
Now you can see that my conditions for CPU and Memory are nested within the And/Or block.
And I’m just going to delete this condition that was added by default because I don’t need it.
Notice that when I added the And/Or block that it was already set as an AND statement. So how will this alert be processed now?
Well, starting with the first condition, the alert engine is looking for any nodes with a status equal to down.
But how does it process this And/Or block? And/Or blocks are evaluated as a single condition. So the question is, does the And/Or block evaluate to true? Are there any nodes with a CPU utilization over 90% and memory utilization over 90%? If so, both conditions of the And/Or block would be met, which means the entire And/Or block would evaluate to true, so I would have an alert event.
The three conditions that I’ve added so far are all looking at current values in the database. But you can also alert on database events.
I’m going to add one more condition.
But this time, I’m going to scroll down a little further in the list below recommended fields to the recommended events section. And I’m going to choose “Last Boot has Changed.”
This will alert me if the node has been rebooted. But notice that alerting on events looks a little different than alerting on field values. I’m not asked for an expected return value. Based on the event type you’ve selected, the alert editor sets the logic of the condition for you.

Alright, so let’s run through my alert one more time. First of all, remember my initial AND/OR block qualifier is set to OR, so if any of the conditions are met, I’ll have an alert event.
So, condition 1, check to see if any nodes are down.
Condition 2 is another AND/OR block, so this is evaluated as a single condition. For this to evaluate to true, based on the qualifier for this condition group both conditions within the group have to be met, so this is asking if there are any nodes with both CPU utilization and Memory utilization above 90%.
And finally, Condition 3, have any nodes been rebooted? If any of these three conditions are met, I’d have an alert event.
So here are my three critical states I’m alerting on; a node is down, CPU and Memory utilization are both high, or a node has been rebooted. I’m OK with my alert logic now, but I’m not OK with the alert scope.
Remember the scoping section up above that I skipped earlier? Notice right now I’m alerting on every node in the database.
You will almost certainly want to scope your alerts based on who needs to see that alert. If I’m an application owner and I’m only responsible for a single server or a small group of servers, I don’t want to see alerts on every node in the organization.
So I’m going to change my scope from all objects to Only the following set of objects,
and I’m going to choose just one of my servers. So I’ll select the IP_Address field and choose my server IP. So now I’m ONLY alerting on a single IP address.
I could also select a range of nodes. Maybe I have a specific DNS naming convention for all my nodes. For instance, all my servers are called ct-lab something-or-other. So I can add another condition and look for DNS names starting with CT-lab.
But again, I need to pay attention now to my and/or block qualifier.
Aright, my alert logic is set. I know what nodes I’m alerting on, and I know what conditions are going to trigger an alert event. So now I’m ready to move on.


Last modified