VMware ESXi and vSphere Cluster Management
vSphere Alarm Trigger Types: Condition and Event Triggers
Learn how vSphere condition/state and event triggers work, when to use each type, and how to select the right trigger for hosts, VMs, and datastores.
A vSphere alarm is a monitoring definition that evaluates configured criteria and can report an alert state or invoke configured actions. The alarm trigger is the part of the definition that determines when the alarm becomes active.
vSphere provides two main trigger categories: condition or state triggers and event triggers. The correct choice depends on whether you need to monitor an ongoing condition or detect a discrete occurrence that was recorded as an event.
What an Alarm Trigger Does
An alarm trigger defines the criteria that cause an alarm to activate. For example, a trigger might match a virtual machine snapshot that exceeds a size limit, a host whose memory utilization reaches 90 percent, or an event reporting a hardware health change.
Triggers are part of the alarm-creation workflow:
- Choose the inventory object or object type to monitor.
- Create or edit an alarm definition.
- Select a condition/state trigger or an event trigger.
- Configure the state, metric, threshold, or event matching criteria.
- Configure alarm actions separately, if required.
- Validate that the trigger represents the operational condition you want to detect.
The trigger and the action have different purposes. The trigger condition answers, “When should this alarm activate?” An alarm action answers, “What should happen after activation?” Possible responses include notification, escalation, or remediation. Selecting an action does not correct an incorrectly chosen trigger.
The Two vSphere Alarm Trigger Types
A condition/state trigger evaluates an object's current status or measured value. An event trigger reacts to a recorded occurrence involving a vCenter Server object.
Condition or State Triggers
A condition trigger, also called a state trigger, monitors the current condition, state, connection status, or measured performance value of an inventory object.
Objects Monitored by Condition Triggers
Condition/state triggers can be useful for several vSphere inventory objects:
- ESXi hosts: Monitor connection state, availability-related conditions, memory utilization, or other resource measurements.
- Virtual machines: Monitor power state, snapshot-related measurements, availability, or resource utilization.
- Datastores: Monitor connection state and other availability-related conditions.
State-Oriented Monitoring
State-oriented monitoring evaluates a condition such as whether a virtual machine is powered on, whether an ESXi host remains connected, or whether a datastore is disconnected.
For example, a datastore outage requirement is about the datastore's current connection state. The desired condition is “disconnected,” so a condition/state trigger is appropriate. The alarm can remain active while the disconnected state remains true and can return to an acceptable state after connectivity is restored, subject to the alarm configuration.
Metric-Oriented Monitoring and Thresholds
A performance metric is a measured value used to assess resource use or performance, such as host memory utilization. A threshold is a configured boundary at which a metric requires attention.
Conceptually, configuring a metric-based condition trigger involves three decisions:
- Choose the metric, such as memory utilization or snapshot size.
- Choose a comparison, such as greater than or equal to.
- Set the value that represents an unhealthy or attention-required condition.
For a high-memory-use alarm, the configuration might compare an ESXi host's memory utilization with 90 percent. For an oversized snapshot alarm, the configuration might compare a virtual machine snapshot's size with an administrator-defined limit.
A condition can remain true until the monitored state changes or the metric returns to an acceptable value. This makes condition/state triggers suitable for persistent conditions that administrators must continue to monitor, rather than merely record once.
Event Triggers
An event trigger monitors events recorded when operations or changes occur for vCenter Server inventory objects. An event represents an occurrence, not a continuously evaluated current state.
Examples include a host hardware health change, a licensing event, or another administrative or operational change reported by vCenter Server. The alarm is appropriate when administrators need notification that a particular event occurred.
Event Arguments, Operators, and Values
Event matching can use information supplied with the event:
- An event argument is an attribute of the event used to narrow the matching circumstances. It might identify a related object, status, name, or other event property.
- An operator is the comparison method applied to an argument, such as equals, contains, or another available comparison.
- A value is the comparison value supplied for that argument.
For a license expiration requirement, select the relevant license-related event and refine the match with the available argument, operator, and comparison value. The exact choices depend on the event criteria exposed by the vSphere Client.
For a host hardware health requirement, use an event trigger that matches the relevant hardware health event recorded for the ESXi host. This responds to the reported occurrence rather than continuously polling a utilization metric.
Choosing the Correct Trigger Type
Use a condition/state trigger when the requirement describes a current or continuing condition:
- Capacity or resource utilization reaches a limit.
- A virtual machine remains in an undesired power state.
- A datastore is disconnected.
- A host or virtual machine has an availability-related condition.
- A snapshot or other measurement exceeds a defined boundary.
Use an event trigger when the requirement describes something that happened:
- An administrative operation or configuration change occurred.
- A host hardware health change was recorded.
- A license expiration event occurred.
- A lifecycle or operational event requires notification.
Resource Threshold Versus Event Notification
Suppose an operations team wants an alert when an ESXi host reaches 90 percent memory utilization. The question concerns a value that can rise, remain high, and fall, so a condition/state trigger is the correct model.
Now suppose the team wants notification that a host hardware health change was reported. The question is whether a particular occurrence was recorded, so an event trigger is the correct model.
Choosing the wrong category can cause missed alerts or misleading alerts. An event trigger cannot replace ongoing evaluation of a resource threshold, and a condition trigger may not identify a specific administrative or lifecycle occurrence.
Relationship Between Trigger Criteria and the Alarm
A single alarm definition is based on the trigger criteria selected during configuration. The target object type affects which choices are meaningful. A datastore alarm should use datastore-relevant connection or availability criteria, while an ESXi host alarm can use host state, host connectivity, performance, or hardware-related criteria appropriate to the alarm type.
Trigger selection also determines how later operational responses should be designed. A persistent high-utilization condition may require escalation or capacity remediation. A hardware or licensing event may require an administrator to investigate a recorded change. These responses are configured after the trigger and should reflect whether the alarm represents an ongoing state or a discrete occurrence.
Conceptual vSphere Client Configuration Workflow
- Choose the inventory object or object type to monitor.
- Create or edit the alarm definition.
- Select either a condition/state trigger or an event trigger.
- For a condition trigger, choose the monitored state or metric and configure the expected state, comparison, and threshold.
- For an event trigger, select the event criteria and define applicable arguments, operators, and values.
- Configure the desired notification, escalation, or remediation action separately, if required.
- Validate that the trigger matches the intended operational condition.
Troubleshooting Trigger Selection
Threshold Alert Never Activates
Likely cause: The monitored metric, threshold, target object, or comparison does not match the intended resource condition.
- Confirm that a condition/state trigger was selected.
- Verify the target ESXi host or virtual machine.
- Review the selected performance metric and configured threshold.
- Check whether the observed value actually satisfies the comparison criteria.
Datastore Outage Is Not Reported
Likely cause: The alarm monitors an unrelated event or metric instead of the datastore connection state.
- Confirm that the alarm applies to the correct datastore.
- Use a condition/state trigger for a disconnected-state requirement.
- Verify that the selected connection state represents the desired failure condition.
Event-Based Alarm Produces No Notification
Likely cause: The event criteria are too restrictive or do not match the arguments associated with the recorded event.
- Confirm that the relevant event is generated for the target object.
- Review the configured event arguments, operators, and values.
- Ensure that the alarm scope includes the object where the event occurs.
Alerts Do Not Represent the Intended Problem
Likely cause: A state-based requirement was configured as an event trigger, or an occurrence-based requirement was configured as a condition trigger.
- Restate whether the requirement concerns a current ongoing condition or a discrete occurrence.
- Select the trigger category that matches that monitoring model.
- Test the criteria in a controlled, non-production scenario when possible.
Key Takeaways
- A vSphere alarm trigger defines when an alarm becomes active; actions define what happens afterward.
- Condition and state triggers evaluate current status, connectivity, availability, or measured values.
- Thresholds are useful for metrics such as memory utilization and snapshot size.
- Event triggers react to recorded operations, changes, and lifecycle occurrences.
- Event arguments, operators, and values refine which recorded events match.
- Use condition/state triggers for persistent conditions and event triggers for discrete occurrences.
- The target object type must be compatible with the selected trigger criteria.
For a concise reference, see Alarm Trigger Types.