Hello, I'm Dean Pompilio, and welcome to less than five for module 10 in the Virtual Ization Configuration
Installation Management course. This lesson will be talking about alarms and how useful they are for your managing your environment. We'll look at what's involved with creating a condition based trigger for your alarm or an event based trigger.
We'll see how easy it is to view your alarms and acknowledge them
and wrap things up by doing lab number 18.
So an alarm is a way to get notified when an event or condition exists, and you have a lot of flexibility in how you create
the triggers that will allow the alarm to happen.
There's a lot of default alarms that get created when you install the center for Hosts of'em plenty of via default alarms to choose from there.
And then we can to make custom alarms for all these different areas in your host. Your cluster data centers, distributed switches,
data storage or networks,
and it's kind of easy to get carried away, actually with all the possibilities. But a
ah mature virtual environment should have a reasonable set of alarms configured
so that the administrator can get notified automatically when certain problems crop up or when certain problems
are starting to get worse.
We have the ability to
go from a normal range of operation to a warning level and then from the warning level to the alert level. And then you can configure alarms to go from alert back toe warning from warning back to normal so you can see a problem as it gets worse. And as it gets better and how you decide to set up the alarms would be up to you,
for example, some of the alarms you might.
She has previously mentioned default alarms
errors with your host. Maybe the CPU usage on the host is too high.
VM has been powered on or avian has been powered off. Maybe there's a problem with a license
or you're running out of space in one of your data stores.
These are all things you want to know about,
as the problem is going from normal to a warning level so you can set thresholds to decide when you want to know about it. To give you enough time to fix the issue before becomes critical,
fair, simple to create alarm all you do is selected item in the inventory, right click and say at alarm.
Once an alarm has been triggered, you can also right Click it when you're looking at the alarms, tab, alarms and events, and you can announce the alarm,
meaning that you're showing that you have at least looked at it.
But that doesn't clear the alarm. You have toe right click again and say clear if you want to. Clearly love. Sometimes you want to acknowledge an alarm,
but keep it in the list of triggered alarms because you want to see what happened and went.
So that case acknowledging just
basically removes the
the visual display up that the alarm has been triggered because you'll get a little red, diamond or yellow triangle on your inventory. Object when alarm has been triggered.
You can also copy the text of the alarm to your clipboard,
which might be useful in case you're trying to troubleshoot an error message, and you want to be able to pace that information to a search engine or or other
So our alarm settings
are involving either specific conditions or state
of some. Some object in your inventory or specific events that are occurring for that object.
When you look at the ad alarm dialogue box, you'll notice that it also has an able enable and disabled check box.
This is very useful as well, because you can create your alarms.
Leave them all disabled until you've got them all created, and then turn them on and see what you know if they're working the way you wish.
If an alarm turns out to be generating a lot of alerts, but it's not really doing what you want, you can always go in and disable it
without having to delete it and then re create it later.
So this gives you the ability to deal with your alarms in the fashion and a workflow that works best for you.
So when we're setting up a condition trigger, we have to think about
the warning that we're actually trying to.
some of these examples here u V m a memory usage, host, usage of CPU or memory,
and then we have to think about the length of that condition,
and once the once the length of the condition has been met, then we can generate a warning or an alert.
Same thing with the alert way. Figure out what we want to alert on.
It could be the same as the warning condition. Usually that's the case.
And then you set the condition length for the warning here.
we can say that if if we CPU usage is above 75%
you have the above A CZ below is equal to
so you can you can set some different parameters here. In this case, we want to know the CPU usage is above 75% for five minutes.
That's a reasonable alarm to set for a warning. That means you're VM is getting busy,
but it hasn't reached a critical stage yet.
So in this case, I might want to know about that so I could set up
the alarm. Thio, notify me in various different ways and we'll cover that shortly.
However, I can also sudden alert
Now if CP usage is above 90% for five minutes, I definitely want to set an alert. That means that my virtual machine is running out of resources and I may need to take some kind of action
in order to prevent the problem for becoming worse.
So the triggers that we define for for these two conditions, whether it's a warning or alert, very configurable
if I'm setting up conditions. However, with events now I'm using arguments, operators and values.
I can say that, for instance, I could make an alarm that says, When the guests the West is shut down on this particular object sending alert.
In this case, we're just looking for the event. We don't care how long the condition lasts. If the event happens, we want to know about it.
So that changes the kinds of situations where you want to get an event based trigger used versus a condition based trigger
condition. Triggers are more about managing your environment,
you know, on a day to day basis, hour to hour,
whereas of Empress triggers are looking for some some event that happens. That may be a rare thing.
Like like maybe one of your hosts get shut down.
That shouldn't be happening on a regular basis. So maybe we set up a event for that,
or maybe a host or one of your V EMS powers down, and we want to know when that happens
in the case of power down. Setting a length of the condition wouldn't make any sense. It's just a event
once, Once you trigger
based on a condition or event, you have to think about how you want to
change the reporting parameters.
So what we can do is
a judge. Adjust the range of frequency of the reporting to avoid getting repeat alerts and to also deal with small fluctuations. For instance, if you specify the range,
you can specify a percentage above or below the limit that you set.
going back to this example if I had a CPU usage above 75% for five minutes,
that this alert will trigger after five minutes after another five minutes. If it's still above 75% I'll get another alert. Maybe I don't want to get too many of those,
ah percentage above or below this in order to limit
I rather to deal with small fluctuations. If it's you know, 77%
you know, maybe I don't want to know about. So
if I said 75% for five minutes, I could say on Lee. Let me know if this goes up by 10%
So if I added seven and 1/2 percent, I'd get 82 a half percent.
So now on. Lee sent me another alert. If I go
10% above what my limit is currently set or 10% below
just depends on how you want to configure that.
Then we have the frequency adjustment.
This means that you can say, even though you're looking for a five minute window for the condition to exist, I can also
limit how many times I get notified within a certain time. Rage,
maybe only notify me once within a 10 minute ranger once within a 15 minute range.
That way, especially if you're getting alerts in the middle of the night, you're you're limiting the amount of disruption.
or just in the middle of the day, even you're limiting the amount of disruption that it causes. You get the first alert, you decide to look into it. You know, after a certain amount of time, another alert look, it will happen. If the condition still exists,
then the reporting options are done. So then you think about what actions you'd like to take.
When the alarm gets triggered, you can send an email. This is a great option. Since everybody's checking email, you might get automatic notification on your mobile device that in e mails come in
can also send an S and M p trap.
If so, if you're using S and M P to manager your devices on your network, this is also useful
or you can run a command. The command could be a script. It could be
anything you wish. You just have to specify it. Have a way to reach the absolute path to that command from your configuration dialogue box.
We also have to think about the different states.
So as I was mentioning earlier, when we go from a normal status to a warning status, we could trigger an alarm there.
When we go from warning to alert, we can also trigger an alarm
and reverse is also true. Going from alert back down the warning or from warning back down to normal. We can also configure alarms for these,
and this gives you the flexibility to say that
if I'm going from normal to warning, give me an alert. Give it some time on Lee. If it exceeds some parameters that I define as being this condition appears to be lasting longer than I would expect. Then send me the the next alarm when we go to the alert level
and then on the way back down, you could also do that.
For instance, this might be useful. Let's say you're
using this scenario 75% for five minutes for a warning or 90% for an alert.
It might be that your
of your VM gets busy for five minutes at 75% then it goes up to 90%. And somewhere in that 90%
are somewhere in that next five minutes it goes back down below 90%.
So I'll get an alert toe warning message telling me that that the condition is starting to get better on its own.
I can get another warning
or another alert, rather from the warning to the normal level telling me that I'm going from
the 75% back down to something below 75%.
So if you were stuck in a meeting or you are unable to take action, you could at least get notified when the problems is getting worse. And then when it's getting better. Maybe there was some temporary processing that caused the problem, and it's been completed, so now you're VM is back to normal.
Lastly, we have the notification configuration. Here you can select email
or SMTP or your command window,
and you just specify the server info. If you have an SMTP server configured in your environment, you put inside the address. You can pick the port number or you specify an email account that you'd like to use for sending messages to.
So after you looked at all this as a recap, we know what with the alarms are what kinds of default alarms air set up where you can make custom alarms.
Some examples of those
right clicking an alarm to add it to an inventory object, right clicking to acknowledge or clear.
And then we talked about the different conditions or events that would allow you to trigger an alarm
and the ability to enable I'm disabled.
Then you need to know the warning and condition length from going from normal T warning from warning to alert from alert back to warning and from warning back to normal so we can have a lot of flexibility for how we set this up.
And then we saw some of the ways you can get notified when your conditions are met,
and that helps you as an administrator, deal with your environment without having to constantly manually check these things.
Okay, so lab number 18 is your next task. In this lab,
you'll be setting up alarms that look for a condition, setting up alarms. Look for an event.
You'll trigger the alarm, using some of the tools that we use an earlier labs to generate CPU traffic.
And then you'll disable the alarms. And that concludes lesson number five. Thank you.