The following video (5:59) demonstrates how to build alerts for your Applications. This video specifically looks at the logic and variables that are available to use with Applications and Components.
All SAM versions
In this video, I’m going to show you how to build alerts for your Applications. We’ll specifically look at the logic and variables that are available to use with Applications and Components.
To begin, open Settings -> Manage Alerts in your Orion web console.
Click Add New Alert to kick off the Alert Wizard.
For the purpose of this alert, I’m going to assume I’ve got a few items already defined. I’m monitoring a SQL server application, and have created a custom property on my Nodes to help to define which department owns which servers. Let’s take a look at the different ways I can alert on this SQL application.
On your Properties page, it’s good practice to name your alert descriptively to make it easy to find again. As time goes on, you’ll find yourself creating a lot of alerts to handle different situations, and a good naming convention and use the ‘Severity of Alert’ setting can help to locate the alerts.
(highlight ‘Name’ and ‘Severity of Alert’ settings)
To Alert on Applications, you’ll want to set the ‘I Want to alert on’ setting to ‘Application’. Once this is selected, the alert Trigger condition options will change to reflect the type of object you have chosen to monitor.
The simplest Application alert you can set up is ‘Alert me when an Application goes down’. If any component of an application fails, it’s parent application will be set to down – this will be picked up by the alert logic, and any actions you defined will be triggered. However, this is overly-simplistic. If any component anywhere in your monitored environment fails, that trigger action would be taken.
It’s better practice to set up your alert for the specific applications and servers that you need your alerts from, to avoid alert spam – receiving too many alerts is just as bad as receiving none, as it makes it too difficult to root out the high priority items.
Use the trigger condition to define out exactly what you want this alert to match. Click Browse all Fields to choose more Application details that you could use – for example, the Application status, the application name, it’s description, or the last time it was up.
You can adjust the ‘Application’ drop down to ‘Node’ to also use Node based variables to filter your alert.
For this scenario, I’m going to alert when Applications with the ‘SQL server’ name, have an application Status of Down – and the Node based Custom Property of ‘Department’ is set to R&D. This lets me closely define that I only want this alert to go out when one of my R&D SQL server applications run into trouble.
I’m skipping over some of the settings here, as we have covered these in the “Trigger condition logic”, “Reset condition logic” and “Scheduling Alerts” videos.
Let’s take a look at the trigger action options open to Applications.
Clicking on Add Action lets me choose exactly what this alert should do when it triggers.
There’s a lot of potential actions you can take – from sending emails and pages through to executing scripts to take automated remedy actions. Take a look at the “Alert Actions” video for more details on these.
I’m choosing to send an email. You’ll need to make sure the recipients and SMTP server have been correctly defined here.
You’ll notice the Message itself has a lot of variables already defined for you. These are filled in at run time with variables about the particular server and application that triggered the alert.
If you need additional details in your email, click on ‘Insert Variable’. Use the drop-down menu to swap to ‘Application’ specific variables, and you’ll find a wealth of information that can be provided automatically within your email notification – from statistics and status of the node or application and how you’re polling it, to any custom properties defined on either Application or the Node. To add a variable, choose the one you want - ‘star’ it to find it easily again, and then click ‘Insert Variable’. You can add multiple variables at the same time.
All variables available for Applications on the Trigger actions will also be available for you to use on any Reset actions.
Now, let’s consider a problematic situation. (Show graphic to demonstrate scenario) In my SQL server application, I’ve defined a custom script that the R&D team want me to run against the SQL server, to monitor it’s statistics, however, it doesn’t always succeed – meaning it’s generating a lot of false positive ‘Status down’ alerts – and needless wake-up calls.
For this scenario, I’m going to alert on the Component object instead – when you set up an alert on an Application component, each component is considered its own separate object. You’ll receive an alert as each component goes down – however, it will mean you can choose to set up the alert to not occur for specific components. I’m going to set this up to alert me when any component in the SQL server application goes down – except for that problematic script one.
All of the variables for the trigger and reset actions for Applications will still be available to me.
Another good reason to alert on Components would be to build in automated responses for continuously failing components – for example, if a service keeps stopping unexpectedly, you could build a component alert for that service, with an action to restart that service – and an additional event to then email you if the service is still failing.
Overall, it’s generally best to alert on Applications, and not Components – to reduce alert noise and make sure the emails you’re receiving are the important ones.