A brief video that shows how to use static alerts in coordination with dynamic alerts in the SevOne NMS.
In this video, we're going to cover how to create a compound alert in SevOne. To get to this particular section, in terms of editing a policy, please refer to the Creating a Static Alert video to figure out how to navigate to this particular section. I've already set up which device group this applies to, which operating system, etc. What we're going to do is actually apply a compound alert to interfaces, and a great about the SevOne baseline is that it acts in many ways like an anomaly detector, and this is most powerful when combined with static thresholds to give you a bit of context.
For example, if you normally alert on a group of interfaces when utilization is above 90%, you could take that exact same threshold condition and just lower the bar a little bit, and say, you know what, I want to get an alert when utilization is 80%, but only if for the past 15 minutes the utilization on the interface has been 3 standard deviations above what is normal for this time of the day and this day of the week. Only when those 2 conditions are violated, send me an alert, and that's what we're going to actually go through in this video. This can apply to interfaces, this could apply to CPU, or just about anything that we are measuring and baselining in SevOne.
First steps first, let's get the right indicators near. Let's start with the in octets, and we're going to start with our static threshold to give us context, so 80% for 15 minutes. Hit save. I'm then going to create a baseline alert of 3 standard deviations for 15 minutes. Only when these two together are violated, will it set off the alarm. Now, it probably makes sense to do the same for out octets, so I will do that right now. Finally, just condition this on the baseline. The baseline can be used in a lot of different ways. This is just one of the more common or even more useful ways because it allows you to adapt your existing alerting strategy with a way to detect anomalies.
We're going to want to also set up a clear condition, as is the best practice. We don't really care so much about the baseline when we're clearing it out. We just really care about being outside of that danger zone, as we've defined as 80% utilization, so as long as I am under 80% for 10 minutes on average, I'm happy. I noticed I forgot to change this to percent, easy fix. Before I save this, let's just review.
In the trigger condition section, we're looking at if average HC in octets is greater than 80% over 15 minutes, it's going to trigger an alarm only if at the same time for the past 15 minutes, we have been 3 standard deviations away from what is normal for this time of the day and this day of the week, and it will be the same story for out octets as well. If we look at the clear condition, we just care that we're outside of the danger zone, and we've set up our first compound alert. I think it should be pretty easy to see how this would apply to just about any static threshold strategy you're currently following in your infrastructure.
In addition to these videos, remember that the Data Appliance NMS User Manual is available through the NMS UI as shown below. Clicking on the question mark at the top right of any page will automatically bring you to the section of the manual that corresponds to the page you are currently on.