Trigger Adjustment

When devices within a deployment are being monitored, it is often necessary to tailor the thresholds at which alerts are raised for certain aspects of the infrastructure. What is deemed acceptable for one deployment in terms of disk or CPU resource utilisation may not be suitable for another deployment; in fact, these figures could be different for individual devices within a single site.

With this in mind, Lithium offers the ability to customise almost all aspects of the thresholds associated with raising alerts for different entities. Some scenarios may include:

• Your deployment defines that no alert should be raised unless any Storage Device (ie. disk) should be marked 'At Risk' until at least 90% full.

Select any disk for a device, and click on Trigger Sets.

 

In the case of a Storage Resource - such as a Disk - the used_pc (Used Percentage) trigger is shown. Select it.

 

 

This page lists the Trigger Sets applied to the metric, as well as the rules used to apply the triggers. In this case, we wish to modify an existing rule, so we click Edit next to the warning trigger.

 

 

Click 'Add New Rule' to modify the thresholds. Here we have the ability to modify the thresholds for the particular trigger, so we change the 80 (80%) value to 90 (90%) for the X value. Notice that we also define the scope of the change, and apply it to all objects, within all devices, within all sites.

 

Now you can see that the values for the warning trigger have been altered. Any device that was previously in a state of At Risk (and is currently under 90% utilisation) will change to Normal at the next polling period.

 

• You have an access area switch being monitored by Lithium, but do not wish to be advised every time a user turns off or unplugs their workstation.

As you can see in this example, many of the ports on this switch are marked as Failed, but there is nothing wrong with the way that the switch is operating. As is the case with this switch, it may be appropriate just to monitor the Operational State of a few interfaces, ie. the Trunk and VLAN (and often Port-Channel) interfaces. Select any interface and choose Trigger Sets. Select the op_state (Operational State) metric, and click 'Add Rule'.

 

Here, we are choosing to Not Apply the Action to (ie. don't raise an alert for) this trigger, the Operational State. We apply it to only this device in this site, but select all objects (interfaces) on this device. Click Submit to make the change.

 

Of course, we want to continue monitoring the status of critical ports, as mentioned above. Navigate through to the trigger set configuration for the specific port to resume monitoring on, and configure thus:

 

Now, as we can see, the action to apply the trigger is selected before the action to not apply the trigger (set on all objects on this device) so the object will still be monitored and raise alerts.