Hide this message
Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.
Updated March 11th, 2016
This video will demonstrate how to create a new alert, change the default alerting interval, set the alert severity, and assign custom properties and limitations. This video also describes how the alerting engine works and explains the difference between alerting intervals and polling intervals.
Orion Platform v2016 and above.
Server & Application Monitor v6.2.4 and above
Network Performance Monitor v12 and above
Network Traffic Analyzer
|Storage Resource Monitor|| |
Network Configuration Manager
Web Performance Monitor
IP Address Manager
User Device Tracker
VoIP & Network Quality Manager
I’m ready to begin building my first alert. So from Manage Alerts, I’ll click on Add New Alert to open the alert editor. Add New Alert.
On the Properties tab, I’m first going to name the alert. I’m going to bundle a couple different alert conditions into one alert, so I’m going to call this “Critical States.” I can also add an alert description and turn the alert on or off.
Below that you can set the alerting interval. The default alerting interval for all alerts is 60 seconds, but you can change that to whatever is appropriate. The shortest alerting interval you can set is 15 seconds.
Let’s talk about how the alert engine works for just a moment. The alert engine searches the database to identify alert events. It doesn’t poll network elements; that’s the polling engine’s job. Now that means a couple things. First, it means you cannot alert on anything that’s not already in the database. Second, when you’re dealing with alerts, you’ll always be dealing with at least two different polling functions running at different polling intervals. You have the object polling interval where the polling engine goes out and gathers the data from the monitored object. And then you have the alerting interval, where the alerting engine is going to check the database to see whether an alert event has occurred. Keep in mind that these are two separate functions, but as a general rule, the alerting interval you set should probably be fairly close to the polling interval for the condition you’re testing. For example, if I’m alerting on interface utilization and the interface is being polled at the default rate of every 60 seconds, then 60 seconds makes sense for the alerting interval as well. If the alerting interval is set to every 15 seconds, I’m running a lot of unnecessary database queries on data that won’t have changed yet. If I’m alerting every five minutes, then I might be missing alert events because the alert condition could have been met during one polling cycle but then disappeared again before the alerting interval elapsed. Now that’s not always going to be the case, but it’s a reasonable rule to get started with, and alerting intervals are something you’ll want to keep in mind so that you’re not missing alert events that you want to see, and also because alerting is more resource intensive than regular polling. If you have lots of alerts running at short intervals, you’re going to feel that in CPU utilization on your database.
Beneath the alerting interval, you can set the alert severity, with 5 severity levels to choose from. The severity levels just make it easier for you to identify alert events that are important to you. They have no bearing on the actions that will be taken when an alert event occurs. For instance there’s no implicit rule that says if it’s a critical alert send an email or write to a log file, but if it’s an informational alert, don’t. Again, the severity level just makes it easier for you to manage your alerts. Set Severity to Serious
You can also assign custom properties to your alerts. As with all custom properties, alert custom properties are mostly used for grouping and searching, making it easier to find the alerts that are of interest to you. Highlight Alert Custom Properties
Assigning a custom property won’t stop someone else from seeing the alert. However, assigning the alert to an alert limitation category will. Alert limitation categories set on the alert sync with alert limitation categories assigned in the users’ account permissions. If the account permissions restrict the user to a particular alert limitation category, they won’t be able to see any alerts outside that category. They won’t see either the alert itself in the alert editor, or the alert events that trigger the alert in the Alerts view. Alert limitation categories are great because they keep an application group owner in Texas from having to wade through alerts about network hardware in Bangladesh. But you do need to make sure that the limitation categories are in sync between the alert and the user account.