Information Technology Reference
In-Depth Information
These default alarms are usually generic in nature. Some of the predei ned alarms alert the
administrator if any of the following situations occur:
A host's storage status, CPU status, voltage, temperature, or power status changes.
◆
◆
A cluster experiences a vSphere High Availability (HA) error.
A datastore runs low on free disk space.
◆
A VM's CPU usage, memory usage, disk latency, or even fault tolerance status changes.
◆
In addition to the small sampling of predei ned alarms we've just described, there are many
more, and VMware has enabled users to create alarms on just about any object within vCenter
Server. This greatly increases the ability of vCenter Server to proactively alert administrators to
changes within the virtual environment before a problem develops.
Because the default alarms are likely too generic for your administrative needs, creating
your own alarms is often necessary. Before showing you how to create an alarm, though, we
need to discuss the concept of alarm scopes. Once we've discussed alarm scopes, we'll walk you
through creating a few alarms.
Understanding Alarm Scopes
When you create alarms, one thing to keep in mind is the
scope
of the alarm. In Figure 13.2,
you saw the default set of alarms available in vCenter Server. These alarms are dei ned at the
vCenter Server object and thus have the greatest scope—they apply to all objects managed by
that vCenter Server instance. It's also possible to create alarms at the datacenter level, the cluster
level, the host level, or even the VM level. This allows you, the vSphere administrator, to create
specii c alarms that are limited in scope and are intended to meet specii c monitoring needs.
When you dei ne an alarm on an object, that alarm applies to all objects beneath that object
in the vCenter Server hierarchy. The default set of alarms that VMware provides with vCenter
Server is dei ned at the vCenter Server object and therefore applies to all objects—datacenters,
hosts, clusters, datastores, networks, and VMs—managed by that instance of vCenter Server. If
you were to create an alarm on a resource pool, then the alarm would apply only to VMs found
in that resource pool. Similarly, if you were to create an alarm on a specii c VM, that alarm
would apply only to that specii c VM.
Alarms are also associated with specii c types of objects. For example, some alarms apply
only to VMs, while other alarms apply only to ESXi hosts. You'll want to use this i ltering mech-
anism to your advantage when creating alarms. If you needed to monitor a particular condition
on all ESXi hosts, for instance, you could dei ne a host alarm on the datacenter or vCenter Server
object and it would apply to all ESXi hosts but not to any VMs.
It's important that you keep these scoping effects in mind when dei ning alarms so that your
new alarms work as expected. You don't want to inadvertently exclude some portion of your
vSphere environment by creating an alarm at the wrong point in your hierarchy or by creating
the wrong type of alarm.
Now you're ready to look at actually creating alarms.
