Information Technology Reference
In-Depth Information
Figure 13.3 shows the Triggers tab after changing the Warning and Critical values.
Figure 13.3
On the Triggers tab,
defi ne the condi-
tions that cause the
alarm to activate.
Caution: Counter Values Will Vary!
h e Is Above condition is selected most often for identifying a VM, host, or datastore that exceeds
a certain threshold. h e administrator decides what that threshold should be and what is consid-
ered abnormal behavior (or at least interesting enough behavior to be monitored). For the most
part, monitoring across ESXi hosts and datastores will be consistent. For example, administrators
will defi ne a threshold that is worthy of notifi cation—such as CPU, memory, or network utiliza-
tion—and confi gure an alarm across all hosts for monitoring the corresponding counter. Similarly,
administrators may defi ne a threshold for datastores, such as the amount of free space available,
and confi gure an alarm across all datastores to monitor that metric.
However, when looking at VM monitoring, it might be more di cult to come up w ith a single base-
line that works for all VMs. Specifi cally, think about enterprise applications that must perform
well for extended periods of time. For these types of scenarios, administrators will want custom
alarms for earlier notifi cations of performance problems. h is way, instead of reacting to a problem,
administrators can proactively try to prevent problems from occurring.
For VMs with similar functions like domain controllers and DNS servers, it might be possible to
establish baselines and thresholds covering all such infrastructure servers. In the end, the beauty
of vCenter Ser ver's alarms is in the fl exibility to be as customized and as granular as each indiv idual
organization needs.
