Parameters/Results Pane: State conditions Tab

State conditions Tab

The State conditions tab allows you to configure rules for a monitor to switch to/from a Down State and a Warning State. A state conditions framework overview can be found here.

By default, a monitor inherits its state conditions from its parent (host or application). Hence, all changes you make on the parent’s State conditions Tab will apply to this monitor automatically. Also, a monitor can use a custom state conditions section of any kind allowed for the given monitor type. The sample monitor below inherits the Response Timeout section for the Down state from its parent host and uses the custom Speed Limit sections for both Warning and Down states:

You can add or remove any available state condition sections, inherit a state condition from the parent tree node, or turn section inheritance off and, hence, define a custom state condition. A new Down State Condition is added to the sample Traffic Speed monitor below, but not saved yet. The monitor will switch to a Down state if the traffic speed is greater than 95% of the bandwidth for two consecutive polls (Because of spike filtering. You can read more about spike filtering below).

After the changes are complete, click Save button at the right-hand top corner of the Parameters/Results Pane. You can also press Ctrl+S to save your changes and Esc to cancel saving.

You can’t modify an inherited condition directly. Either you need to uncheck the Inherit from checkbox to make the condition monitor-specific and edit it, or open the parent State condition tab clicking the link to the right of the inheritance checkbox.

Note that all the changes in a parent’s state conditions will apply to all its children that inherit these conditions. If you add a section to the parent while some child nodes use custom state condition sections of the same kind, a confirmation dialog will be shown where you can choose whether to override the child’s section or to keep it customized.

You can add/edit/remove any state condition section on any Main view node (except for monitors) because such sections are used for inheritance and it is not yet known what types of monitors will inherit them. On the monitor tab you can only add/edit/remove state conditions sections defined for a given monitor type. The host tab below contains only one already defined state condition section for the Down state (host-specific, note that the Inherit from checkbox is unchecked), and one inherited Warning state condition. The host configuration allows you to add any possible state condition section.

If you add a new section to any tree node’s State conditions tab (except for the All Hosts root tree node), the section is initially inherited from a parent node if such a section is defined for the parent. You can either save the inherited section, or turn the inheritance off and modify the custom section. If the parent does not have a section of the required type, then a new empty section is added.

An example of an inherited new section is given below:

It can be modified after the ‘Inherit from parent‘ checkbox is unchecked:

An example of an empty new section follows:

The Enforce return to inheritance for children button appears for any tree nodes other than monitors. It allows you to replace custom state condition sections for the children of a current node (e.g. for all monitors on a given host) with the current parent section. The change will be propagated either to the direct children of the current node or to all the children, i.e, to all the subtrees of the current node.

You can modify the list of children to be affected by the change. Click OK after setting the children list.

Besides, this dialog can appear if a child already has the section that you have just added for the parent. You will be asked if the child’s custom section should be replaced with the newly added inherited one.

If you modify a parent section, the changes will affect all the children inheriting this section immediately. For example, here is a modified parent host section:

and a corresponding inherited child monitor section that displays the same values:

In order to prevent false alarms you can use Spike filter. If the filter is on, a monitor does not switch to a problem state after the first “bad” poll that satisfies the problem condition. The monitor will change its state only after the certain number of consecutive “bad” polls satisfy the condition. Note that in some cases the filter might mask an actual problem such as a resource frequently getting out of service for a short while. The sample below shows the Down Spike filter tab: the Common spike filter is off (this is the default behavior), and the custom spike polling interval is set to 3min:

Sections that support spike filter use the Common spike filter settings for both Down and Warning state conditions. You can configure those settings on the Spike filter tab for both Down and Warning state conditions. A custom spike filter can override the common one for any state condition section. if the custom spike filter is required for a given section, it should be configured within this section, like in the sample below:

By default the Spike filter is disabled. You can read more about spike filtering here.

The only exception in the spike filter usage rules is the SNMP Trap monitor Event Timeout state condition section. In this section the spike filter is used to allow several traps (the number can be set) to be overdue for no more than a custom time interval (can be set as well). The monitor will change its state to Down only if the next trap is overdue or missing. The sample Event Timeout state condition below allows 8 traps in a row be overdue for no more than 30s each. The monitor will switch to Down state immediately after the 9th trap is overdue or missing: